memsprout
memsprout is a shared AI-context layer for teams — persistent memory your agents search and update over MCP.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- Store Memory: Save a memory — the single capture tool for everything you want to persist. Give it a concise, descriptive title whenever it holds durable knowledge — a decision, a procedure, a fact, a
- Search Memories: Semantic search across all memories you can read — your personal vault and every space you belong to. Each result is labeled personal or space-scoped. Pass space_id to narrow to a sin
- List Memories: List recent memories in reverse-chronological order (most recently updated first) across everything you can read — personal and all your spaces. Pass space_id to narrow to one space. Fi
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
memsprout is a shared AI-context layer for teams — persistent memory your agents search and update over MCP. Every client you connect (Claude Code, claude.ai, Codex, Cursor, Gemini CLI, …) reads and writes the same knowledge base, so decisions, procedures, and conclusions survive across sessions, models, and tools. Personal memories are private by default; shared Spaces with per-space Topics give teams an organized, versioned common brain. Supports semantic search, file attachments, and guided onboarding.
Zero configuration — OAuth sign-in on first connection. Create your account at memsprout.com first; the OAuth flow signs in existing accounts but doesn't create them. Install guides for each client: github.com/memsprout/agents.
Список инструментов сервера (22)
Технические названия из tools/list. Нужны только разработчикам.
| store_memory | Save a memory — the single capture tool for everything you want to persist. Give it a concise, descriptive title whenever it holds durable knowledge — a decision, a procedure, a fact, a conclusion worth finding by name later — and especially anything going into a shared space. A title makes a memory individually retrievable, auditable, and readable on its own; it's a light touch, not a formal authoring act. Leave the title off only for genuinely raw, ephemeral personal captures — stream-of-consciousness, a voice memo, a half-formed idea not meant to stand alone. When in doubt for durable or team-facing content, title it; you can always add or change one later via update_memory. Search first (search_memories) to avoid duplicates. Prefer discrete, self-contained memories over conglomerated dumps: one concept per memory, each retrievable and auditable on its own — don't roll multiple entities or facts into one blob. For space memories, picking a topic is part of the capture ritual: check list_topics and pass the best-fitting one rather than leaving it to auto-classification. Privacy rule for shared Spaces: only pass a shared space_id when the user has named that Space by name in this conversation turn — never resolve, infer, or default to a shared Space on your own. No named Space → omit space_id, which always lands the memory in the user's personal space. This keeps personal capture safe by default and reserves shared writes for clear, stated intent. When a memory does land in a shared Space, the response names the Space and its visibility so the destination is never silent. |
| search_memories | Semantic search across all memories you can read — your personal vault and every space you belong to. Each result is labeled personal or space-scoped. Pass space_id to narrow to a single space. For recency browsing instead of meaning-based lookup, use list_memories. |
| list_memories | List recent memories in reverse-chronological order (most recently updated first) across everything you can read — personal and all your spaces. Pass space_id to narrow to one space. Filter by titled (true for curated write-ups, false for raw captures, omit for both), tags, extracted facets (type, person, keyword), a time window (days), or a topic name. For meaning-based lookup use search_memories instead. |
| get_memory | Fetch a single memory by UUID — returns full content, title, tags, space, extracted metadata, version history summary, and attachments. Use this when you already have a memory_id (from a search/list result or a stored reference) and want the complete record without a search round-trip. |
| update_memory | Revise an existing memory in place — updates content, title, tags, type, and/or topic, recomputes the embedding, and archives the prior state as a new version. Omit any field to keep its current value. Use for corrections and refinements; to add a title to a raw capture (making it a curated write-up), pass just the new title. Pass an empty-string title to revert a titled memory to a raw capture. |
| move_memory | Move a memory to a different space. The memory's id, version history, created_at, and attached assets are all preserved. It lands in the destination's General topic automatically; pass topic to reassign it immediately after moving. Memory owners can move to any destination including their personal vault (omit target_space_id). Editors on the source space can move to another shared space but not to personal vault. Pre-move visibility notices are included in the response. |
| delete_memory | Soft-delete a memory. It drops out of search and list results immediately; the row, its version history, and its attached assets are retained in the database but not recoverable via MCP. Assets left with no other parent are soft-deleted by the nightly GC. Permission required: owner or space editor+. |
| search | Search the user's memsprout memories. Equivalent to search_memories; provided for hosts that require a generic search/fetch pair (e.g. deep research). |
| fetch | Fetch the full text of one memory by id. Equivalent to get_memory; provided for hosts that require a generic search/fetch pair (e.g. deep research). |
| get_signed_upload_url | Step 1 of 2 for uploading a new file: pre-issue a Storage upload URL. Compute the file's sha256 locally and pass it as content_hash. Then PUT the file bytes to the returned upload_url, and finally call attach_asset with the returned storage_path to register the asset and link it to its parent memory. To reuse a file that's already in Vello, skip this step and call attach_asset with just asset_id. NOTE: the upload_url resolves to *.supabase.co — if you are in a network-restricted environment (e.g. sandboxed code-execution, corporate proxy) that blocks those hosts, use get_upload_link instead and have the user upload via their browser. |
| get_asset | Fetch one asset's full metadata plus a fresh signed download URL. Writes a 'view' entry to the audit log. Reach for this when you already have an asset_id (typically from a memory's attached-asset list) and need to inspect the file or download its bytes. There is no asset search — assets are found via the memory they're attached to. |
| attach_asset | Attach a file to a memory. Three modes: (1) REUSE an existing asset by passing just asset_id + memory_id; (2) REGISTER a new file uploaded via get_signed_upload_url by passing storage_path + mime_type + asset_class; (3) UPLOAD a new file inline by passing file_base64 + mime_type + asset_class. ONLY use mode 3 from network-restricted clients that cannot PUT directly to storage (e.g. sandboxed code-execution). Every other client MUST use get_signed_upload_url instead — passing file_base64 from a normal client dumps the whole file into the model's context. Inline uploads are capped at 5 MB; for larger files on a network-restricted client, POST the raw bytes to /api/upload (multipart/form-data, 'file' field) to get a storage_path, then call attach_asset in mode 2 with that path. The link row is always created in the same call. A new asset inherits its parent memory's space. Pass exactly one of asset_id, storage_path, or file_base64. NOTE: if you are in a network-restricted environment that blocks *.supabase.co entirely, use get_upload_link to generate a browser URL and have the user upload directly. |
| get_upload_link | Generate a Vello web URL the user can open in their browser to upload a file and attach it to an existing memory. Use this instead of get_signed_upload_url when you are in a network-restricted environment (e.g. sandboxed code-execution, corporate proxy) that blocks direct PUT requests to *.supabase.co — the browser bypasses those restrictions entirely. Pass memory_id so the upload page auto-attaches the file on completion. The user must be signed into vello-web.pages.dev in the same browser session. |
| detach_asset | Remove a single (memory, asset) attachment link. The Storage bytes are never touched. If detaching leaves the asset with zero live parents, a nightly GC job soft-deletes the asset row (still recoverable from the DB). To delete a file outright, detach it from every memory it's attached to. |
| list_spaces | List the shared spaces the user belongs to — their IDs, names, descriptions, and the caller's role (owner / editor / viewer) in each. Use this to find a space_id before saving a memory into a space with store_memory (editor+ required), or before narrowing search_memories / list_memories / list_topics to one space. Memories saved without a space_id live in the user's personal space. |
| create_space | Create a new shared team Space in your organization and become its owner. Use this during onboarding or whenever you need a fresh collaboration container. The Space is immediately usable — pass the returned space_id to store_memory to capture into it. Re-creating a Space with the same name in the same org is safe: the existing Space is returned unchanged (idempotent). Requires an active or trialing subscription. If you belong to more than one org, pass org_id to specify which one. |
| list_topics | List the Topics in a space — the per-space organizational taxonomy. Each topic has a name, one-line description, member count, origin (auto=LLM-founded, human=user-created), and an is_general flag. Every space has exactly one General topic (is_general=true) that acts as the catch-all for miscellaneous memories. Use this to navigate a space before assigning or searching within it, or to find a topic name to pass to store_memory's topic param when assigning deliberately. Omit space_id to list topics in your personal space. |
| create_topic | [owner only] Create a new Topic in a shared Space to organize memories by subject. Topics give the Space a taxonomy — pass the topic name when saving memories to place them deliberately. Each Space is capped at 20 non-General topics. After creation, existing unassigned memories are swept against the new topic's embedding and reassigned automatically where a clear match exists. Requires owner role in the target Space. |
| update_topic | [owner only] Rename or redescribe an existing Topic. After updating, unassigned memories are re-swept against the new description so that previously uncategorized content can now be matched to the updated topic. The General topic cannot be edited. Requires owner role in the Space that owns the topic. |
| delete_topic | [owner only] Soft-delete a Topic from a Space. Memories in the deleted topic are moved to the General topic by default; pass reassign_to_topic_id to route them to a different existing topic instead. The General topic itself cannot be deleted. Requires owner role in the Space. |
| file_bug_report | Open a GitHub issue in the Vello repo on the user's behalf. Use this when the user describes a bug or problem with Vello itself — so they don't have to context-switch to GitHub. The issue is filed with the 'bug' label and returns the issue number and URL. |
| memsprout_onboarding | Run the guided memsprout onboarding seed. Call this the first time a user sets up memsprout, or whenever they ask to onboard, get started, import, or seed a workspace from their existing context (exported assistant context the user provides, connected tools, docs, or a context file like CLAUDE.md). Returns the full onboarding guide — follow it end to end: resolve the user's persona (team lead / team member / individual) via the intent gate, orient them with the hierarchy diagram, then gather context, propose and capture an organized set of Memories with provenance, demonstrate the value back, and wire the user's tools to keep using memsprout. The guide itself is read-only text; you do the writes via store_memory after previewing with the user. |