Memory MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes: brief loads the full context, recall searches broadly, gotchas/conventions retrieve specific types, and gotcha/convention/learn/prefer add different kinds of knowledge. The overlap between recall and the focused retrieval tools is intentional and described, but the singular/plural pairs (convention vs. conventions, gotcha vs. gotchas) could cause misselection if the agent does not read descriptions carefully.
Naming Consistency2/5
Tool names follow no consistent pattern. Some are verbs (brief, recall, learn, prefer, fix), some are plural nouns used for retrieval (gotchas, conventions), some are singular nouns used for adding (gotcha, convention), and one is a compound (memory_bootstrap). This mix of conventions makes the naming unpredictable.
Tool Count5/5
With 10 tools, the set is well-scoped for a memory/knowledge server. Each tool covers a necessary function: adding knowledge (four types), retrieving it (three approaches), fixing entries, and bootstrapping a project. The count feels appropriate and not bloated.
Completeness4/5
The tool surface covers the full lifecycle of memory: create (gotcha, convention, learn, prefer), read (brief, recall, gotchas, conventions), update/delete (fix), and initialization (memory_bootstrap). The only minor gap is that there is no dedicated list tool for 'learn' or 'prefer' entries, but recall and brief surface them adequately.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description supplies key behavioral facts: the tool is a one-time load at session start, returns a project-context snapshot including stale entries, and results remain valid for the whole conversation. It doesn't explicitly state read-only semantics or failure modes, but 'load context' implies non-destructive behavior and the cached-results disclosure adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry the essential call timing, return values, example, and validity window. Minor redundancy between 'Start of conversation' and 'Call once at session start' prevents a 5, but it remains tight and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool with no output schema, the description covers main return categories, call timing, and validity. However, it doesn't explain behavior when lobe is omitted (required list is empty) or the memory_bootstrap prerequisite beyond the schema property text, leaving a small but meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes 'lobe' as a memory lobe name and even provides prerequisite bootstrap guidance, so schema coverage is complete. The tool description contributes a concrete example ('lobe': 'my-project') but no additional meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a session-start context loader with a specific resource ('context for a project') and enumerates the returned content (preferences, gotchas overview, stale entries, counts). It distinguishes itself by covering everything saved via learn/gotcha/convention/prefer, but doesn't explicitly contrast with sibling tools like recall or gotchas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit timing guidance: 'Call once at session start' and 'no need to re-call,' which tells the agent when to use it. It doesn't name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It states 'Highest trust level,' 'Persists across sessions,' and 'surfaced in every brief(),' which are meaningful behavioral traits beyond just the write action. This is substantial transparency for a simple recording tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and starts with the primary use case, followed by clear examples and practical scoping tips. Every sentence carries useful information, though the prose is slightly run-on and could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the core behavior, persistence, and scoping are covered. However, the large set of sibling memory tools (learn, conventions, gotchas, recall) makes it unclear when to choose 'prefer' over these alternatives. The description would be more complete if it explicitly distinguished itself from those tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that 'rule' is required and gives examples, but the lobe scoping and rule description are already present in the input schema. The description adds little beyond illustrative JSON examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: when the user corrects you or states how they want things done, record it here. It names the resource (preferences/rules) and includes concrete examples. However, it does not explicitly differentiate from sibling memory tools like 'learn' or 'conventions', so it gets a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit trigger condition ('When the user corrects you or states how they want things done') and scoping instructions ('Omit lobe for global preferences; add lobe to scope to one project'). It does not mention exclusions or alternative tools, but the context is clear enough for basic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the side effects of scanning and seeding memory, and it clarifies the required 'root' param. However, it does not mention whether the operation is destructive, idempotent, what happens if the lobe already exists, or if it modifies files in the repo. This is partial transparency sufficient for basic use but not comprehensive for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary use case, includes a helpful JSON example, and contains no filler. Every sentence provides distinct value: when to use, what it does, and an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use, what it does, the required parameter condition, and the outcome. However, it lacks details about edge cases (e.g., running when lobe exists, budgetMB behavior, response format) and does not have an output schema. For a bootstrap tool with this complexity, it is nearly complete but has minor gaps in behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description does add value by restating the conditional requirement for 'root' and providing a concrete example, but it does not explain 'budgetMB' beyond the schema, and the example only covers two of the three params. The added semantic clarity is modest, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it scans repo structure, README, and build system to create a named lobe and seed initial memory. It uses specific verbs like 'scans' and 'create' and references a specific resource ('lobe'), distinguishing it from sibling tools like brief, recall, or learn which operate on an existing lobe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'When no lobe exists for a project — run this before any other tool.' It also states the benefit of using it ('After bootstrapping, all other tools become available for that lobe'), implicitly guiding the agent to use this before alternatives. This is strong, actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the tool 'retrieves' conventions and gives filter examples, which implies a read-only operation. However, it does not explicitly state that it is non-destructive, nor does it mention dependence on memory_bootstrap or behavior when no conventions match. Missing explicit side-effect or prerequisite details beyond what's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the key purpose, and includes a compact example. It avoids redundancy and every sentence contributes: usage context, retrieval mechanics, example, and alternative tool guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional params and no output schema, the description covers when, what, and how, plus an alternative. It doesn't detail return values, but schema covers parameter specifics. The main gap is lack of mention of the need for memory_bootstrap (though in schema), but overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by showing concrete examples of parameter combinations, clarifying that omitting 'area' returns all conventions for a lobe. This enhances the semantic understanding of how the parameters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stored conventions, with a specific context of use ('Before writing new code'). It distinguishes from recall() by noting this is for focused lookup, which is an explicit alternative. The verb 'Retrieves' and resource 'stored conventions' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use ('Before writing new code') and provides an alternative: 'recall() for broader cross-topic search.' This qualifies as explicit when/alternatives, exceeding the minimum requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses both update (replacement) and deletion behaviors with concrete examples, and clarifies the required 'id' parameter. It doesn't mention permanence of deletion or error handling, but covers the essential operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a clear example, no fluff, and front-loaded purpose. Every sentence earns its place, efficiently conveying purpose, usage, and mechanics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter mutation tool with no output schema, the description covers purpose, when to use, and how to update/delete. It lacks explicit mention of return values or edge cases like missing IDs, but is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing JSON examples and explaining the relationship between 'correction' (update) and omitting it (delete). This gives deeper semantic meaning than the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'correct or delete' a stored entry, using specific verbs and a clear resource. It distinguishes from sibling tools by focusing on modifying existing entries, referencing IDs from retrieval tools like brief/recall/gotchas/conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use: 'When a stored entry is wrong or outdated.' It also mentions that IDs appear in brief/recall/gotchas/conventions results, implying this is used after retrieving entries. It does not explicitly name alternatives, but the context of sibling learning tools makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It uses the verb 'retrieves' to imply a read-only operation, but does not explicitly state that it has no side effects, nor does it mention prerequisite conditions like needing a configured lobe (which appears only in the schema). It also does not describe what happens when no gotchas are found. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two sentences plus an example, front-loaded with the core purpose and immediately followed by usage guidance. Every sentence provides useful information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description adequately covers purpose, usage, and parameter behavior. It could have mentioned the return format or error behavior, but 'retrieves stored gotchas' is sufficient in this context. The relationship to brief and memory_bootstrap is indirectly supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by showing example JSON invocations and explaining that omitting 'area' returns all gotchas for the lobe. This clarifies parameter interaction beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Retrieves stored gotchas, optionally filtered' with a specific verb and resource, and includes concrete examples. It also distinguishes from the sibling 'brief' by noting that brief already includes a gotchas overview, clarifying when this tool is specifically needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Before making changes to an area, check for known pitfalls' and 'Use this when you need gotchas for a specific area not covered in the briefing.' It also implicitly contrasts with brief as an alternative, giving clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: 'Persists across sessions,' 'Returns related knowledge,' and 'One insight per call.' It does not mention error handling or authorization, but these are minor for a memory-store tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear flow: purpose, example, do/don't guidance, and constraints. It is longer than minimal but every sentence adds practical value, especially the examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description covers input format and content guidance thoroughly, but it only vaguely mentions 'Returns related knowledge' without describing the return structure. The durabilityDecision parameter is documented only in the schema, which is acceptable given 100% coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing a concrete JSON example and by guiding what the 'observation' should contain ('Store facts that help future sessions, not actions you took or bugs you fixed'). This goes beyond the schema's simple 'Write naturally'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'When you understand how something works — architecture, dependencies, module boundaries — store it here.' It identifies a specific verb (store) and resource (knowledge), and distinguishes itself from siblings with 'Catch-all for knowledge not covered by gotcha/convention.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly differentiates from gotcha/convention and provides strong usage guidance with wrong/right examples ('Wrong: “Fixed the null pointer in UserService.” Right: “UserService.getUser() returns null when session expires—callers must handle this.”'). It also states constraints like 'One insight per call' and persistence across sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses that data persists across sessions, surfaces in brief() and recall(), returns related knowledge, and should store timeless facts rather than ephemeral notes. This goes well beyond the schema and provides excellent behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary instruction. Some redundancy exists between 'Store facts... not notes' and the subsequent wrong/right example, but each sentence earns its place overall. The length is acceptable given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is quite complete: it covers purpose, usage, persistence, surfacing, and return value. However, it omits any mention of the 'review-required' flow that the schema's durabilityDecision hints at, and it does not elaborate on how the returned 'related knowledge' might be used, leaving a slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all three parameters. The description adds a JSON example and reiterates required params, but does not add significant new meaning beyond the schema. The 'durabilityDecision' parameter, in particular, is not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('record a pattern the codebase follows') and the resource ('convention' store), and distinguishes itself from the sibling tool 'prefer()' by explicitly noting that personal style rules should use prefer instead. It also differentiates conventions from session notes with a concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool ('When you notice a pattern the codebase follows') and when not to ('For personal style rules, use prefer() instead'). It further clarifies with wrong/right examples and emphases one insight per call, making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses persistence across sessions, priority in brief()/recall(), and that it returns related knowledge. It also enforces 'One insight per call.' This is solid behavioral disclosure, but it doesn't mention potential side effects like duplication or error conditions, which would push it higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with the core purpose, then gives an example, then clarifies the distinction between facts and notes, then states constraints and behavior. Every sentence adds value, and the structure supports quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write operation with a rich schema and no output schema, the description is complete. It covers purpose, when to use, how to phrase observations, persistence, return behavior, and required parameters. The only optional parameter (durabilityDecision) is fully explained in the schema, so no additional description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by providing a full example of lobe and observation, and by giving wrong/right examples for how to phrase the observation. It also explicitly flags the required params, making parameter usage clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool flags surprising or unexpected issues as 'gotchas' for future sessions. It provides a concrete example and distinguishes itself from siblings like learn, prefer, and conventions by emphasizing the specific use case. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'When something surprises you or doesn't work as expected.' It also gives right/wrong phrasing examples and advises 'Store facts that help future sessions, not notes about this one,' which is a clear guideline. However, it doesn't explicitly name alternatives or exclusion cases, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: semantic + keyword matching, search scope limited to specific memory entry types, call frequency, skip conditions, and that 'Knowledge stays in your context.' This is significant context beyond what a schema could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes a useful example. It is compact but contains some redundancy (e.g., 'stored memory' vs. 'memory entries') and a restatement of the required parameter, but overall each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description is self-sufficient: it explains what the tool does, its scope, exclusions, when to call it, when to skip, and provides an example. The behavior is fully contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds only an example and repeats 'Required param: context'; it does not enrich parameter meaning beyond what the detailed schema descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'surface prior knowledge you haven't loaded yet' and 'Searches stored memory using semantic + keyword matching.' It distinguishes itself from siblings by clarifying scope: 'Searches YOUR memory entries (from learn/gotcha/convention/prefer)' and 'Does NOT search the codebase or the internet.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Before starting a task' and 'Call once per area.' It also provides clear when-not-to-use instructions: 'Skip if you already recalled this topic or received it from brief().' The exclusion of codebase/internet searches further refines when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![memory-mcp MCP server](https://glama.ai/mcp/servers/EtienneBBeaulac/memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EtienneBBeaulac/memory-mcp)

Score Badge

Copy to your README.md:

[![memory-mcp MCP server](https://glama.ai/mcp/servers/EtienneBBeaulac/memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EtienneBBeaulac/memory-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EtienneBBeaulac/memory-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server