The Memory MCP server exposes 9 tools whose definitions cost approximately 2,360 tokens in every single conversation, whether or not any of them is ever called. Against the 19 static rules in the catalogue it scores 96 out of 100 — grade A — raising 10 scored findings in 2 of the six categories.
Surface is the strongest category at 100/100, and schemas the weakest at 80/100. It is catalogued here under Productivity and Docs, alongside other servers agents reach for in the same kind of work.
2,360 tokens is roughly 1% of a 200,000-token window, paid again on every request rather than once per session. That averages 262 tokens per tool definition, counted with the o200k_base encoding.
That lands exactly on the Productivity and Docs median of 2,360 tokens.
Findings are listed by severity; the rule pages explain the reasoning in full.
`schemas/param-desc-missing` accounts for 4 findings. Undescribed parameters get filled by guesswork. Every property the model must populate deserves a sentence saying what it means and what shape it takes. On this surface it fires on `create_entities`, `create_relations` and `add_observations`, among 1 others.
`schemas/complexity-budget` accounts for 3 findings. Deeply nested inputs, very wide property lists, and stacked oneOf/anyOf force the model to solve a constraint puzzle before every call. Flatter, narrower inputs get filled correctly more often. On this surface it fires on `create_entities`, `add_observations` and `delete_observations`.
`design/list-no-limit` accounts for one finding. A list/search tool with no limit or pagination parameter can dump an unbounded payload into the context window. The caller must be able to ask for less. On this surface it fires on `search_nodes`.
Memory's surface raises 2 further rules — `design/overlap-cluster` and `schemas/loose` — listed in full below.
Findings that measurably degrade tool selection.
A list/search tool with no limit or pagination parameter can dump an unbounded payload into the context window. The caller must be able to ask for less.
Tools whose descriptions substantially overlap force the model to pick between near-synonyms — the classic cause of wrong-tool calls. Clusters are usually one tool wearing several names; consolidate with include-flags or a mode parameter.
delete_entities, delete_relations
Deeply nested inputs, very wide property lists, and stacked oneOf/anyOf force the model to solve a constraint puzzle before every call. Flatter, narrower inputs get filled correctly more often.
Deeply nested inputs, very wide property lists, and stacked oneOf/anyOf force the model to solve a constraint puzzle before every call. Flatter, narrower inputs get filled correctly more often.
Deeply nested inputs, very wide property lists, and stacked oneOf/anyOf force the model to solve a constraint puzzle before every call. Flatter, narrower inputs get filled correctly more often.
Loose schemas (bare objects, untyped arrays, open additionalProperties) turn schema validation off exactly where the model is most likely to hallucinate argument shapes.
Undescribed parameters get filled by guesswork. Every property the model must populate deserves a sentence saying what it means and what shape it takes.
Undescribed parameters get filled by guesswork. Every property the model must populate deserves a sentence saying what it means and what shape it takes.
Undescribed parameters get filled by guesswork. Every property the model must populate deserves a sentence saying what it means and what shape it takes.
Undescribed parameters get filled by guesswork. Every property the model must populate deserves a sentence saying what it means and what shape it takes.
4 of the six categories come through clean: surface, naming, descriptions and annotations. In practice that means the surface stays inside a sensible tool and token budget, the tool names follow one convention end to end, every tool carries a description long enough to disambiguate it and read and write operations are machine-distinguishable before a client runs them.
`search_nodes` is the most expensive definition at 321 tokens — about 14% of the whole surface — against 164 for `delete_entities`. Every tool carries a description, ranging from 31 to 106 characters.
All 9 declare annotations, so a client can tell a read from a write before running one. Input schemas average 1 top-level parameters and nest 4 levels deep at their worst, with 1 tool taking no input at all.
All 9 tools as published, heaviest first. Token counts use the o200k_base encoding and are approximate.
| Tool | Tokens | Description | Params | Required | Depth | Annotations |
|---|---|---|---|---|---|---|
search_nodes | 321 | 56 chars | 1 | 1 | 1 | yes |
open_nodes | 320 | 57 chars | 1 | 1 | 2 | yes |
create_entities | 292 | 51 chars | 1 | 1 | 4 | yes |
create_relations | 292 | 106 chars | 1 | 1 | 3 | yes |
read_graph | 289 | 31 chars | 0 | 0 | 0 | yes |
add_observations | 247 | 64 chars | 1 | 1 | 4 | yes |
delete_relations | 223 | 50 chars | 1 | 1 | 3 | yes |
delete_observations | 210 | 65 chars | 1 | 1 | 4 | yes |
delete_entities | 164 | 80 chars | 1 | 1 | 2 | yes |
Memory ranks 2 of 3 scanned Productivity and Docs servers, exactly on the category median of 96.
The closest comparisons in this directory are Microsoft Learn, Notion and Brave Search, which sit nearest on score and face the same kind of surface-design pressure.
A fix plan turns these findings into an ordered set of changes with the token saving of each one.
This page is a static analysis of Memory's published tools/list surface on the date shown. It is not a security review, a performance benchmark, or a judgement of the product behind the surface. Read how the score is computed, or browse every audited server.