What are the standard tools exposed by an MCP memory server for client integrations?

TL;DR

• There is no standard set of memory tools. MCP standardises how a client gets a server's tools and calls them, and each server picks its own tool names; in the 2026-07-28 schema the word "memory" appears once, in a comment that uses a memory tool as the example of a closed world.
• What is standard is the surface a client can read: tool definitions from tools/list with a name, an input schema, an optional description and optional annotations, optional server instructions, and a notification when the list changes.
• Behind different names, most memory servers cover the same jobs: save, search, read back or page through, correct or remove, report status, and some add prompts, resources or widgets.
• On the client side, in Claude Code with tool search, which is on by default, "Only tool names and server instructions load at session start". The full definition arrives when the model finds the tool through search.

Mnemoverse, which publishes this library, makes one of the memory servers in the table below.

Is there a standard set of tools for an MCP memory server?

No. The specification defines what a tool looks like, not which tools a memory server should have.

A tool definition is the record a server returns from tools/list for each tool: a name, an optional title, an optional description, an input schema, an optional output schema and optional annotations. In the specification's words, the description is "Human-readable description of functionality", the title is "Optional human-readable name of the tool for display purposes.", the output schema is "Optional JSON Schema defining expected output structure", and the annotations are "Optional properties describing tool behavior". "Tool names SHOULD be between 1 and 128 characters in length (inclusive)."

Names do not have to be unique across servers: "Tool name uniqueness is scoped to a single server." A client that combines several servers "SHOULD implement a disambiguation strategy such as prefixing tool names with a server identifier." Claude Code does exactly that; Anthropic says to "Run /mcp in your session and select the tool to see its full name, such as mcp__<server>__<tool>."

So the protocol does not know what you called your tools. How a call travels from tools/list to text in the model's window is covered on What is an MCP memory server; this page is about what a client does with that surface.

What does a client actually receive from a memory server?

Four things, and only the first is required.

1. Tool definitions, as above.
2. Tool annotations are optional hints attached to a tool definition, such as readOnlyHint or destructiveHint. The schema is explicit that all properties in ToolAnnotations are hints. They are covered below under who reads them.
3. Server instructions are optional text from the server about how to use it as a whole. In revision 2026-07-28 they are a field of the server/discover result: "instructions: Optional natural-language guidance for LLMs on how to use this server effectively". That revision says "There is no negotiation handshake.", and "Calling server/discover is optional for clients", so instructions reach a client that makes the call. Servers that still speak "protocol versions that establish a session with an initialize handshake (2025-11-25 and earlier)" return the same field in the initialize result.
4. A list-change notification. In the specification, "listChanged indicates whether the server will emit notifications when the list of available tools changes."

Servers can offer more than tools. Claude Code shows MCP prompts as commands, "Claude Code lists each MCP prompt as /servername:promptname (MCP).", and resources through @: "Type @ in your prompt to see available resources from all connected MCP servers." Some keys in a tool's _meta object are meant for a particular client, such as Anthropic's "anthropic/alwaysLoad" below. Supermemory also ships a prompt, "A ready-to-attach context message for the active space", and widgets: clients that support MCP Apps "can open these Supermemory widgets directly inside the conversation."

Which tools do memory servers expose in practice?

Some examples, by server rather than by job, so an empty cell is not read as a missing feature. The names come from each server's own tool table.

Server	Example tool names	Worth knowing	Source
MCP reference memory server	create_entities, add_observations; search_nodes, open_nodes, read_graph; delete_entities, delete_observations	Every tool carries annotations: the readers readOnlyHint: true, the tools that remove entities, observations and relations destructiveHint: true and idempotentHint: true. Guidance on using the memory sits in the README under "System Prompt": "The prompt for utilizing memory depends on the use case."	README, index.ts
Mem0 MCP (hosted)	add_memory ("Save text or conversation history for a user/agent"), search_memories ("Semantic search across existing memories with filters"), get_memory, update_memory, delete_memory, delete_all_memories ("Bulk delete all memories in scope")	get_event_status exists to "Check the status of an async memory operation by" event ID, so an operation can finish after the call returns	Mem0 MCP
Supermemory MCP	add_memory, search_memory, get_profile, forget_memory ("Forget outdated information")	The docs say which read tool answers which question: "Use the retrieval tools for different questions:", and "Use get_profile for who-the-user-is, preferences, and recent context."	Supermemory MCP
Graphiti MCP server (Zep)	add_memory, search_nodes, search_memory_facts, delete_episode, clear_graph	The name add_memory matches Mem0 and Supermemory, and what it writes to differs: "add_memory: Add an episode to the knowledge graph (supports text, JSON, and message formats)."	Graphiti mcp_server/README.md
Cognee MCP	remember, recall, forget, code_search, cognify_status	"Every registered tool is callable by name, but only some of them appear in the server's tools/list response by default"; the rest are found with search_tools and called by name	Cognee MCP tools
Letta hosted MCP	create_agent, send_agent_message, get_reply	A different shape: a client "can connect to https://api.letta.com/mcp to create stateful Letta agents, delegate work to them, and read their replies.", so the tools address agents with their own memory rather than records. "Full input schemas are available from tools/list."	Letta hosted MCP
Mnemoverse	memory_write ("Store a preference, decision, or lesson"), memory_read, memory_list_recent ("List the newest memories first, no query, to catch up after a break"), memory_feedback (tell it a recalled memory helped or misled, and it re-ranks what comes back next), memory_stats	The docs say which read tool answers which question: "memory_read and memory_list_recent answer different questions". A prompt produces rules for an agent's instructions: "The Mnemoverse MCP server carries a prompt, setup_memory, that produces the rules on demand."	MCP server, Make your agent use memory

Examples from each server's own tool table, read on 23 October 2026. Not a full list; tool sets change between releases, so follow the link for the current one.

What does the model see at session start, and what loads later?

That depends on the client, and it changes how you should write a server.

Claude Code. "Tool search keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start, so adding more MCP servers has minimal impact on your context window." There is no fixed count: "Claude Code doesn't impose a fixed per-server tool cap; the practical limit is your context window budget." A server author can ask for a tool to load up front: "To control how one of your server's tools loads, set "anthropic/alwaysLoad" in that tool's _meta object." A user can also load every tool of a server up front, and Anthropic advises doing that sparingly: "Use this for a small number of tools that Claude needs on every turn, since each upfront tool consumes context that would otherwise be available for your conversation." Tool search is on by default and is off under some configurations, which the Configure tool search section lists.

Claude API. The same mechanism works per request: "Tools with defer_loading: true load only when Claude discovers them through search." For the MCP connector, "you don't set defer_loading on individual tool definitions." "Instead, set it once on the mcp_toolset entry's default_config for the whole server, or per tool in its configs." What the search reads: "Both tool search variants (regex and bm25) search tool names, descriptions, argument names, and argument descriptions."

ChatGPT. OpenAI's guide tells developers to "refresh apps to pull new tools, descriptions, and server instructions from the MCP server."

The consequence for a memory server, as this page reads the documentation above: with deferred loading, two decisions are made from different text. Whether to reach into the server at all is decided from tool names and server instructions, and which tool to call is decided from descriptions the model reads only after the first decision. Anthropic describes what the instructions are for: "Server instructions help Claude understand when to search for your tools, similar to how skills work." How deferred loading interacts with the prompt cache is on What breaks prompt caching.

What are server instructions for, and how long can they be?

What for. The schema says the instructions "should focus on information that helps the model use the server effectively and should not duplicate information already in tool descriptions." Anthropic lists three things to put in them: "What category of tasks your tools handle", "When Claude should search for your tools" and "Key capabilities your server provides". OpenAI: "Use the MCP instructions field for server-wide guidance such as required tool sequences, shared rate limits, or relationships between tools. Keep the first 512 characters self-contained."

How long, in Claude Code. "Claude Code cuts a tool description or server instructions that run past these default limits, and Claude sees only the text before the cut". The limits, read on 23 October 2026:

• "Server instructions, and the description of a tool that loads upfront: 4,096 characters" (Claude Code 2.1.296 or later);
• "The description of a tool that Claude loads through tool search: 16,384 characters" (Claude Code 2.1.295 or later).

These numbers moved twice in the week of 8 October. The rule that will outlast the next change: "Keep descriptions and instructions concise, and put critical details near the start." And for search: "When tool search matches Claude's query against a tool's description, it reads only the part within the shorter limit, so put the words Claude would search for near the start too." One exception: "Descriptions and instructions from some of the MCP servers that Anthropic hosts at api.anthropic.com reach Claude in full".

Where they end up. The earlier revision of the specification leaves it to the client: "For example, this information MAY be added to the system prompt." One practitioner measured where Claude Code put them on stdio: "the instructions arrived as a <system-reminder> in the first user turn (never in the system prompt)". That is one measurement with its own bounds, "Everything ran on one machine, one account, one model (Opus 5.5) and one version (2.1.285), all headless.", and its own caveat: "Whether it follows instructions delivered in this position is a different question, and we did not test it." The same author's advice for a server that supports both revisions: "Put the instructions in both replies if the server speaks both eras."

How to see them. In Claude Code 2.1.283 or later, /context shows server instructions as their own row.

How does a model tell two memory tools apart?

What breaks as a server grows is not the server itself. One analysis of the schemas of 4,951 public servers, by the author of an SDK that reports how models use a server's tools, puts it this way: "It's whether a model can tell your tools apart." Its own conclusion: "Split when the collisions are real, not because you crossed a number." Its own caveat: "I never ran a model against any of these servers, so I can't tell you how often collisions actually cost anything."

A static check of 1,118 descriptions on 46 popular servers in the Smithery catalog, by Hiroki Nomura's linter, found "769 tools (69%) never say when to use them." Its fix for a paragraph pasted into every description: "Move shared notes to the server's instructions."

What helps, each in its author's terms:

• One sentence per tool on when to use it. Two tools whose description was only "Finds text across the repository" "scored 0/20 on usage and were flagged as a lookalike pair."; adding a sentence each "took both to 15/20, and the pair was no longer flagged." That is the linter's score, not a measure of what a model picked.
• A negative pointer: "In my agent runs, adding a single negative pointer usually cuts down more tool-choice thrashing than expanding the parameter schema."
• A successor for a retired tool: "A separate "replaces" field is worth it as well, so a deprecated tool points at its successor instead of competing with it."

Client vendors say the same. OpenAI: "write action-oriented tool names and descriptions that include “Use this when…” guidance, note disallowed/edge cases, and add parameter descriptions (and enums) to help the model choose the right tool among similar ones". Anthropic's directory review: "Each tool description should state precisely what the tool does and when to invoke it."

For a server that wants to be listed, the same review sets limits on what a description may do. In its words: "Describe what the tool does, and don't tell Claude how to behave.", and descriptions are rejected if they "Interfere with Claude calling other tools". The directory policy adds: "Instructional Software tool or capability descriptions must not create confusion or conflict with other Software in our Directories." This page does not read those rules for any particular wording.

Examples of docs that write the difference between read tools down: Supermemory, with which retrieval tool answers which question, and Mnemoverse, with search versus the recent feed.

Who reads tool annotations?

Clients do, and models read descriptions.

The hints, in the schema's words: readOnlyHint means "If true, the tool does not modify its environment."; destructiveHint means "If true, the tool may perform destructive updates to its environment. If false, the tool performs only additive updates.", and its default is true. The schema even uses memory as the example of a closed world: "For example, the world of a web search tool is open, whereas that of a memory tool is not."

They are hints: "Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers.", and "For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers."

What clients do with them:

• Claude's directory: "Every tool must include a title and the applicable hint: readOnlyHint: true for read-only tools, and destructiveHint: true for tools that modify or delete data. These determine auto-permissions in Claude."
• ChatGPT: "Read-only detection: We respect the readOnlyHint tool annotation", and "Tools without this hint are treated as write actions."

So set the hint and still say it in the description. A practitioner who sets both gives the reason: "because the model reads the description while the client decides what to do with the hints, and those two audiences are not the same." The MCP reference memory server in the table annotates every tool.

Does the tool list stay the same between releases?

Within one connection, a server can announce a change: "An MCP server can change the tools, prompts, or resources it offers while connected and send a list_changed notification." Claude Code: "In an interactive terminal session, Claude Code fetches the updated list from that server, so you don't need to reconnect it." Order matters too: "Servers SHOULD return tools in a deterministic order (i.e., the same ordering across requests when the underlying set of tools has not changed)." Why order matters for the prompt cache is on What breaks prompt caching.

Between releases, the registry does not help. The server.json schema of the official MCP Registry has no tool fields; for vendor data it has _meta, "Extension metadata using reverse DNS namespacing for vendor-specific data", including a key for "Publisher-provided metadata for downstream registries". Nomura, who also indexes servers: "A version's server.json has the name, version, description and remotes or packages, but no tools, and the registry adds status, publishedAt, updatedAt and isLatest. To get tool definitions you have to connect and call tools/list."

To compare across releases, compare the definitions, not dates. Another practitioner: "Hash each normalized tool definition and diff on that hash between observations". Nomura's registry does exactly that: "Each tools/list gets a SHA-256 of a canonical JSON, and each tool its own; a server gets a new version only when that hash changes".

How memory vendors write about changes: Supermemory keeps old inputs working, "The deprecated containerTag input and add_memory with action: "forget" remain supported for existing clients."; Cognee offers a switch back to the full list, "set COGNEE_MCP_TOOL_MODE=all to restore the previous behavior.", and says "For new integrations, prefer the v1.0 memory tools (remember, recall, forget)."

How do I check what my client actually sees?

• Call tools/list yourself and read the names and descriptions in one block, as the model gets them, without the README next to it.
• Use the MCP Inspector. Anthropic's directory review asks for it before submission: "Exercise every tool through the MCP Inspector and as a custom connector in Claude before you submit."
• In Claude Code, /mcp shows each tool's full name. Keep it short: "Claude Code leaves an MCP tool out of the tools it sends to Claude when its full name is over 128 characters." Claude's directory sets a shorter rule for names: "Tool names must be 64 characters or fewer."
• In Claude Code 2.1.283 or later, /context shows server instructions as their own row.

What this page does not claim

No performance figure for anyone and no tool count for any server: tool sets change between releases. The servers in the table are examples, not a list of all of them. Every quotation and every limit was read on the date given in Sources; client limits changed twice in the week of 8 October. Practitioner measurements are quoted with their own bounds and were not rerun here.

Common questions

What are the standard tools exposed by an MCP memory server for client integrations?

There is no standard set. MCP standardises how a client gets a server's tool definitions from tools/list and calls them, and each memory server names its own tools. What a client can read is the same on every server: tool definitions with a name, an input schema, an optional description and optional annotations, optional server instructions, and a notification when the tool list changes.

Which MCP memory server packages provide tools for reading, writing, and providing feedback on memories?

Every server in the table on this page saves and reads back memory under its own tool names; Letta's hosted server does it through agents that keep their own memory. Feedback on what came back is accepted in different ways: Mem0 documents a feedback API, Cognee records feedback on recall answers through sessions with cognee.session.add_feedback, and Mnemoverse has an MCP tool, memory_feedback: tell it a recalled memory helped or misled, and it re-ranks what comes back next. For any other server, check its own documentation.

What does Claude Code load from an MCP server at session start?

With tool search, which is on by default, Anthropic says only tool names and server instructions load at session start, and a tool's full definition arrives when Claude finds it through search. A server author can ask for a tool to load up front with "anthropic/alwaysLoad" in that tool's _meta object.

What are MCP server instructions, and how long can they be?

Server instructions are optional guidance from the server on how to use it; in MCP revision 2026-07-28 they are a field of the server/discover result. By default, Claude Code cuts server instructions and the descriptions of tools that load up front at 4,096 characters (Claude Code 2.1.296 or later) and descriptions loaded through tool search at 16,384 characters (2.1.295 or later), read on 23 October 2026. Anthropic's rule that outlasts the numbers: keep them concise and put critical details near the start.

How do I stop a model from confusing two memory tools?

Make the descriptions say what differs. One linter's author reports that two tools with the same one-line description were flagged as a lookalike pair, and that one added sentence each cleared the flag (a linter score, not a model's choice); OpenAI recommends "Use this when…" guidance and edge cases in each description.

Do tool annotations like readOnlyHint make a memory tool safe to call?

No. The MCP schema calls every annotation a hint, and says clients should never make tool use decisions based on annotations from untrusted servers. Clients use them for confirmations: Claude's directory requires readOnlyHint or destructiveHint because they determine auto-permissions, and ChatGPT treats a tool without readOnlyHint as a write action.

Can a client rely on a memory server's tool list staying the same between releases?

Not from the registry. The official MCP Registry's server.json has no tool fields, so to know a server's tools you connect and call tools/list. Within one connection, a server can announce changes with a list_changed notification. Between releases, compare a hash of each normalized tool definition rather than a date.

Sources

Every quotation on this page was read on 23 October 2026, between 13:42 and 13:51 UTC, with a direct request with browser headers (and the page's Markdown export where the host serves one) and a second time through r.jina.ai with its cache turned off; r.jina.ai drops Note, Warning and Steps blocks, so quotations from those blocks and from the registry's JSON schema rest on the direct request alone. Files on GitHub were read raw and through the GitHub API. On every host, a request for an address that does not exist was the control; where a host answered it with a normal page, only the page's own text counted. Quotations are contiguous text of the page named, with its punctuation. The page describes these documents as they stood on 23 October 2026.

Model Context Protocol, revision 2026-07-28

• Tools: tool definitions, names, annotations, listChanged, ordering
• Discover: server instructions
• Versioning and Compatibility: no handshake, earlier revisions
• Schema 2026-07-28 and schema 2025-11-25: annotations as hints, instructions
• Registry server.json schema

Anthropic

• Claude Code: MCP: tool search, limits, alwaysLoad, list_changed, prompts, resources, full names
• Claude Code changelog: 2.1.283, 2.1.295, 2.1.296
• Claude API: tool search tool: defer_loading, the MCP connector
• Connector review criteria and Anthropic Software Directory Policy

OpenAI

• Building a custom MCP server: instructions, descriptions, readOnlyHint, refreshing apps

Memory servers, for the table and the feedback answer only

• MCP reference memory server: README and index.ts
• Mem0: Mem0 MCP, feedback mechanism
• Supermemory MCP
• Cognee: MCP tools, MCP overview, feedback system
• Graphiti MCP server
• Letta hosted MCP
• Mnemoverse: MCP server, Make your agent use memory

Practitioners, dev.to, each quoted with the bounds of their own measurement

• Hiroki Nomura, We checked 46 popular MCP servers on Smithery (8 October 2026), and in its thread: the linter scores (3gne5), the registry and hashes (3gpjo); Reid Marlow on negative pointers (3gncm); ANP2 Network on hashing definitions (3gone)
• MCPulse, How many tools should an MCP server have? (14 September 2026), and Ava Bagherzadeh on the two audiences (3f7nf)
• Rudratosh Shastri, Your GitHub MCP server costs 55,000 tokens before your agent reads a single word. (28 September 2026), and Taras Hanych on a "replaces" field (3gdlg)
• rulestack, a measurement of where Claude Code delivers server instructions (7 October 2026)

Related

• What is an MCP memory server?: the protocol path from tools/list to text in the window
• What breaks prompt caching: the stable prefix contract: tool order, deferred loading and the cache
• Why does my code editor AI keep overriding custom repository guidelines every session?: why a rule in context is still only context
• Memory MCP servers compared and MCP memory servers for Claude Code and Cursor: choosing a server
• MCP server, Make your agent use memory and Where each tool works: the Mnemoverse pages

Edward Izgorodin · Mnemoverse · 2026-11-06