GoodMemory
Server Quality Checklist
Latest release: v0.7.5
- Disambiguation4/5
Most tools have clearly distinct purposes: primary recall, progressive recall, and diagnostics are separated. However, goodmemory_search_index and goodmemory_get_context both serve recall and could be confused, though the descriptions clarify their different use cases.
Naming Consistency4/5All tools share the goodmemory_ prefix and use snake_case, with mostly verb_noun patterns (get_context, inspect_memory, trace_recall, get_records, read_artifacts). Two tools (timeline, stats) are noun-only, creating slight inconsistency, but the overall pattern is predictable.
Tool Count5/5At 8 tools, the count is well-scoped for a memory system. Each tool has a distinct role, and the count feels appropriate without being excessive or thin.
Completeness2/5The tool set focuses heavily on reading and diagnostics but lacks a core writing tool (goodmemory_remember is referenced in descriptions but not exposed). No update, delete, or list-all capability is present, which is a significant gap for a memory system.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 885 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'compact chronological context' but does not explain what the tool returns, whether it is read-only, how pagination or limits work, or any edge behaviors. This is insufficient for a tool with no structural annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the first sentence 'Advanced recall.' is redundant filler that adds no information beyond the name. The second sentence carries the meaningful usage guidance. Overall it is concise but not maximally focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It provides a high-level use case but omits behavioral details, return value expectations, and relation to sibling tools. The agent would likely need to guess or invoke incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters have descriptions), and the tool description adds no parameter-level meaning. Parameters like query, limit, recordsPerBucket, and retrievalProfile are not explained. The description does not compensate for the low schema coverage at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool provides 'compact chronological context' for 'progressive GoodMemory recall,' which aligns with the 'timeline' name. It distinguishes from siblings through its chronological focus and the 'before drilling into recordRefs' workflow cue. The opening 'Advanced recall' is vague but the second sentence clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: when you need compact chronological context before drilling into recordRefs. This gives a clear workflow context and implies it is a preparatory step. However, it does not explicitly mention alternatives or when not to use it, slightly limiting the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It only mentions 'compact memory context fragment' without disclosing any side effects, performance implications, authentication requirements, or limitations. The description lacks transparency about what the tool actually does beyond returning a fragment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second provides usage guidelines. No fluff, efficient, and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and low schema coverage, the description is too minimal. It does not explain the output format or behavior beyond 'compact fragment', leaving the agent guessing about critical aspects like output encoding, token limits, or how sessionId affects retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), yet the description only addresses the 'query' parameter (implied by 'specific question'). Other parameters like cwd, output, maxTokens, sessionId, and retrievalProfile are completely ignored. The description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a compact memory context fragment for a specific question about the workspace. The verb 'fetch' and resource 'memory context fragment' are specific and actionable, though it does not explicitly differentiate from sibling tools like goodmemory_get_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios: 'when hook-injected context is missing or insufficient' and 'when you need memory for a different question than the current prompt'. This gives clear guidance on appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It labels the tool as 'Diagnostic' but does not confirm read-only behavior, side effects, authorization needs, or constraints. This lack of detail is a significant gap for a tool that may be called diagnostically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, efficiently front-loading the label and usage. It contains no fluff, but the brevity leads to gaps in other areas like parameter and behavioral info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 3 parameters (one undocumented), and no annotations, the description is too minimal. It fails to explain the role of includeRuntime, the structure of return data, or any preconditions. A tool with this complexity should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no context about the parameters (cwd, sessionId, includeRuntime). Schema coverage is 67% (includeRuntime missing description), and the description does not compensate by explaining how these parameters affect the projection. The agent must rely solely on the schema's partial descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as diagnostic and specifies it retrieves the 'accepted host-adapter artifact projection' for the workspace. This distinguishes it from sibling tools that handle different data types (contexts, records, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when you need the accepted host-adapter artifact projection'), providing clear context. However, it lacks explicit guidance on when not to use it or mention of alternatives, though the specificity implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Advanced recall' without mentioning idempotency, error handling, or access requirements, which is insufficient for a read operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with 'Advanced recall' and provides specific usage context, earning its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters, the description fails to explain what 'detail' is returned, how records are selected, or how it differs from sibling tools like goodmemory_get_context, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so baseline is 3. The description adds no parameter details beyond the schema; it does not explain recordRefs format or usage, thus providing no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'Advanced recall' to get details of recordRefs after using search_index or timeline, distinguishing it as a follow-up step for detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use after search_index or timeline returns recordRefs, providing clear context. It names alternative tools for the preceding steps, though it lacks explicit exclusions for sibling tools like goodmemory_get_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?
No annotations provided, so description must disclose behavior. It says output is a compact recordRef index (not full details), implies read-only, but doesn't specify permissions, idempotency, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose. No wasted words, clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing explanation of optional parameters (limit, retrievalProfile, includeRuntime) and output format. Does not fully describe how to chain steps or handle edge cases. Adequate for simple usage but incomplete given 6 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only 2 of 6 parameters have descriptions). Description adds no parameter-specific meaning beyond mentioning 'query' implicitly. Low compensation for poor schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it fetches a compact recordRef index for a query, part of progressive recall. Distinct from siblings: goodmemory_get_context (rendered summary) and goodmemory_get_records (detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context: prefer over goodmemory_get_context when specific records are needed, and it's step 1 followed by goodmemory_get_records. Explicit alternative and workflow.
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?
Since no annotations exist, the description carries the full burden. It correctly indicates read-only diagnostics and mentions the 'retrieval' field, hinting at the return structure. No side effects are described, but for a stats tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a usage hint. Front-loaded with 'Diagnostic'. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters and no output schema, the description provides core purpose and usage context. It could elaborate on the output structure beyond the 'retrieval' field, but is sufficient for a simple stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 parameters described). The description does not add meaning beyond the schema for parameters; it focuses on the return field 'retrieval'. Baseline 3 is appropriate as schema covers most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Diagnostic. Record counts and runtime metadata...' with a specific verb and resource. It distinguishes from sibling tools by focusing on diagnostic stats rather than content retrieval or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use: 'Call it to check whether memory exists here before assuming an empty store.' Does not explicitly exclude alternatives, but the diagnostic nature implies it's for quick status checks.
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 provided, but description discloses diagnostic nature and explains internal details. Implies read-only, but doesn't explicitly state lack of side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Diagnostic,' then specifics. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose and usage are clear, but parameter details are missing, and no output schema means description should hint at return structure but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, and description adds no detail about parameters (query, cwd, strategy, sessionId, retrievalProfile) beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states diagnostic purpose, explains what it explains (routing, hits, scores, suppression reasons), and gives two specific use cases. Distinguishes from sibling diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when a memory should exist but didn't surface, or when a surfaced memory looks wrong. No ambiguity.
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 of behavioral disclosure. It explicitly states the tool is 'read-only', which is a key behavioral trait, and specifies it covers 'durable and runtime' state. However, it doesn't disclose potential costs, side effects (e.g., performance overhead of inspecting runtime state), or the exact shape of the snapshot, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key term 'Diagnostic', and every word adds value. It immediately communicates the tool's distinct role and when to use it, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, no annotations, and a clear-purpose description, it is reasonably complete. The description conveys the tool's essence and use case, but might benefit from mentioning what kind of 'snapshot' content is included (e.g., structure, size, or format) to fully compensate for the lack of an output schema. Overall, it is sufficiently contextual for an agent to handle it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, covering cwd and sessionId, but includeRuntime lacks a description. The tool description adds no parameter-level information, so it neither compensates for the missing includeRuntime semantics nor adds anything beyond the schema. A score of 3 reflects that the schema already documents most parameters, but the description could have clarified the undocumented boolean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'read-only snapshot of durable and runtime GoodMemory state' for the current workspace, which is a specific and informative purpose. It also distinguishes itself from siblings by labeling it a 'Diagnostic' tool beyond primary tools like goodmemory_get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need a read-only snapshot...' and contrasts it with 'primary goodmemory_get_context / goodmemory_remember tools', thus giving clear when-to-use context and naming alternatives. Although it doesn't explicitly list when-not-to-use, the 'beyond the primary' phrasing effectively excludes normal recall use cases.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/hjqcan/GoodMemory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server