mcp-memory-graph

Server Quality Checklist

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

Latest release: v2.10.2
Disambiguation3/5
Many tools have overlapping purposes, such as multiple search/query tools (memory_search, memory_query, memory_query_structured, vault_search) and multiple memory operations (core_memory_* vs memory_*). While descriptions help, the large number of similar-sounding tools can cause confusion for an agent.
Naming Consistency4/5
All tools use snake_case and share a consistent prefix pattern (memory_, core_memory_, vault_). However, the naming mixes action verbs (memory_store, memory_delete) with nouns (memory_canvas, memory_insights), breaking the verb_noun pattern in several cases.
Tool Count3/5
With 50 tools, the server is on the heavy side. The broad domain might justify some specialization, but many tools could be consolidated (e.g., three export tools, multiple analytical tools). The count feels slightly beyond optimal for agent usability.
Completeness5/5
The tool set is exceptionally thorough, covering CRUD operations, versioning, import/export, vault sync, knowledge graph queries, analytics, reflection, consolidation, and even GDPR compliance. No obvious dead ends or missing operations for the stated purpose of memory management.
Average 4/5 across 50 of 50 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 405 commits in the last 12 weeks
- Last stable release on July 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under PolyForm Noncommercial License 1.0.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the explicit limit parameter definition in the input schema: the description states 'Max 1000 records per export' while the schema defines default=1000 and maximum=10000. This inaccuracy could mislead an agent about the tool's capacity. Annotations correctly mark it as read-only, but the description adds conflicting information.
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 a single concise sentence covering purpose, filtering, and a constraint. It wastes no words, though the limit inaccuracy detracts slightly from its effectiveness.
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 description covers the output format (JSON) and basic filtering, but fails to mention pagination (offset/has_more) which is available in the schema, and does not describe the response structure or differentiate from similar export siblings. Given no output schema, more detail on return values would be beneficial.
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?
Since schema description coverage is 100%, the baseline is 3. The description adds little beyond restating the filter parameters (scope, namespace, department) and introduces a potentially misleading limit of 1000, which is already expressed more precisely in the schema.
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 states it exports memories as JSON for backup or migration, specifying the output format and high-level use case. However, it does not distinguish itself from sibling tools like memory_export_dataset or memory_export_vault, missing an opportunity to clarify unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering by scope, namespace, and department, giving context on when to use it. However, it fails to provide guidance on when not to use it or alternatives, and the mention of 'Max 1000 records per export' is an oversimplification given the schema allows up to 10000.
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 (only openWorldHint, not behavioral), the description carries full burden. It only says 'Store... for a memory,' which indicates a write operation but reveals no side effects (e.g., overwriting existing entities, permissions required, or any destructive behavior). For a mutation tool, this is insufficient transparency.
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 extremely concise: two sentences, front-loaded with the core action. Every word adds value, with no redundancy. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex nested input schema, many sibling tools, and no output schema, the description is too minimal. It lacks context on prerequisites (e.g., memory existence), return values, how the tool fits into the larger system of memory tools, and what happens if relationships are omitted. The sentence about knowledge graph queries hints at purpose but doesn't compensate for the missing completeness.
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 each parameter is well-described in the schema itself. The description adds no additional semantics beyond what the schema provides (e.g., no explanation of how memory_id must be valid, or behavior on duplicate entities). Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 states the action 'Store LLM-extracted entities and relationships for a memory.' It specifies what the tool does (store structured entity/relationship data) and its benefit (enables knowledge graph queries). However, it does not explicitly distinguish this from siblings like 'memory_extract_learnings' or 'memory_store', which also deal with extraction or storage, missing an opportunity for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance: 'The calling agent should analyze memory content and provide structured entity/relationship data.' This implies the tool is for storing extracted data after analysis. However, it does not state when to use this tool versus alternatives (e.g., memory_store for raw text, or memory_extract_learnings for patterns), nor does it mention prerequisites like the memory needing to exist or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation destructiveHint=true by claiming 'never a destructive overwrite'. This is a serious inconsistency. Additionally, while the description adds context about versioned edits and snapshots, the contradiction undermines transparency.
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 two sentences, front-loaded with the purpose, and contains no unnecessary words. It efficiently communicates the key action and behavioral nuance.
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 description covers the restore action, versioned nature, and return value, but the contradiction with annotations reduces completeness. Without output schema, it does not explain what the restored memory object contains, and it lacks any mention of prerequisite or side effects beyond the annotation conflict.
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%, and the description does not add any parameter-level meaning beyond what is already in the schema. The parameters are well-documented in the schema, so 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 verb 'roll back' and resource 'memory to a prior version', explicitly distinguishing from destructive actions and noting the versioned nature. It differentiates from sibling tools like 'memory_restore' by focusing on version restoration and non-destructive behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restoring a specific prior version, but it does not explicitly state when to use this tool versus alternatives like 'memory_restore'. No direct exclusions or when-not-to-use guidance is provided.
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?
Annotations already indicate destructiveHint=true. The description adds that it deletes by ID or filter, which is minimal beyond what annotations convey. No additional behavioral traits like irreversibility or authorization needs are disclosed.
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?
One sentence of 15 words, front-loaded with verb and object. Every word is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested filter object and the destructive nature, the description is too minimal. Missing details on what happens when both id and filter are provided, behavior on no matches, or return value. Output schema is absent.
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 documents parameters. The description merely lists filter criteria already present in the schema, adding no extra meaning.
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 states 'Delete memories' and specifies two modes: by ID or by filter criteria. However, it does not differentiate from sibling tool 'memory_forget', which may also delete memories, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint ('Provide at least one of id or filter') but lacks explicit guidance on when to use this tool versus alternatives like memory_forget, prerequisites, or when not to use it.
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?
Annotations already declare readOnlyHint=true, indicating safe read-only behavior. The description's 'Browse' aligns with this. However, the description does not add further behavioral context beyond what annotations provide, such as potential performance implications or the bi-temporal nature of the 'as_of' parameter. The openWorldHint=false is not explained. Since the description does not contradict annotations, a score of 3 is appropriate (baseline, no added 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?
The description is two sentences, front-loaded, and every word adds value. It efficiently conveys core functionality. However, it could be slightly expanded to mention the bi-temporal or pagination behavior without losing conciseness. Still, it is well-structured and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and the complexity of bi-temporal filtering, the description is incomplete. It does not explain the return format (e.g., list of memory objects with fields), nor the effect of 'as_of' on results. For a tool of this complexity, the description should provide more context to aid correct invocation.
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 has 100% coverage with descriptions for all 9 parameters. The description's mention of 'filtering and pagination' adds no detail beyond the schema. For example, 'as_of' is a complex parameter but the schema already explains it. Baseline 3 is correct since the schema does the work.
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: 'Browse memories with filtering and pagination.' It specifies supported sorting fields and implies list retrieval, which distinguishes it from sibling tools like memory_get (single retrieval) and memory_search (likely full-text search). The verb 'browse' and resource 'memories' are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing and filtering memories but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or when not to use it. Among 52 sibling tools, there are many memory listing/search tools, so explicit differentiation would be helpful. Without such guidance, the description is adequate but not exemplary.
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?
Discloses key side effects: automatic embedding regeneration on content change and preservation of previous versions in history. Annotations do not contradict; 'openWorldHint: false' is compatible. This provides useful beyond-schema context.
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?
Three sentences that front-load the core purpose and then add behavioral details with no extraneous words. Every sentence serves a purpose.
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?
Covers the main behavioral aspects but lacks comparative guidance against a large set of sibling tools. Does not describe return value or error states, though no output schema exists. Adequate for a basic update tool.
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% with detailed parameter descriptions. The description adds minimal extra per-parameter info (only the embedding regeneration tied to 'content'). Baseline 3 is appropriate.
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 states 'Update an existing memory' with a specific verb and resource. It adds behavioral details (embedding regeneration, versioning) that differentiate it from similar tools, but does not explicitly contrast with siblings like 'memory_replace' or 'memory_append'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'core_memory_replace' or 'core_memory_append'. The description omits prerequisites, context for choosing this tool, or when not to use it.
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?
The description adds behavioral context beyond the readOnlyHint annotation by detailing that timestamps and author information are included. However, it does not disclose potential limitations like pagination behavior or what happens if the memory has no history.
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?
A single sentence that is front-loaded with the core purpose, containing no extraneous words. Every word is necessary.
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 read-only tool with two parameters and no output schema, the description covers the main purpose but does not describe the return format or how to interpret the history data. It is adequate but lacks some completeness.
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% for both parameters (id and limit). The description does not add additional meaning beyond what the schema already provides, so the baseline of 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 verb ('View'), the resource ('version history of a memory'), and what is shown ('all past edits with timestamps and who made each change'). This distinguishes it from sibling tools like memory_version_diff and memory_version_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as memory_version_diff or memory_version_restore. It does not specify prerequisites or when not to use it.
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?
Annotations already declare readOnlyHint=true, so the description's addition of traversal depth and entity browsing provides useful context. However, it does not describe failure behavior (e.g., entity not found) or pagination beyond the limit parameter. With annotations carrying the read-only signal, the description adds modest behavioral detail.
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 concise: two sentences, front-loaded with the primary purpose. No redundant phrases. Slightly more structure could help, but it is efficient.
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 description covers the essential functionality but lacks details about the response format (e.g., how relationships and memories are structured). With no output schema, additional context about return fields would improve completeness. Adequate for basic understanding.
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 description adds marginal value beyond schema descriptions. It clarifies the role of entity and entity_type (start traversal vs. browse by type) and restates depth range. 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 queries the knowledge graph to find entities, relationships, and linked memories. It specifies starting with an entity name or browsing by type, and supports multi-hop traversal. This sets it apart from sibling tools that focus on CRUD or other specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for graph traversal queries but does not explicitly state when to use this tool versus alternatives like memory_search or memory_get. No when-not-to-use or exclusion criteria are provided.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that the output is a rolled-up status with reasons, but does not disclose additional behavioral traits like authentication needs, rate limits, or side effects. Context is adequate but not rich.
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 a single, well-structured sentence that front-loads the core purpose and lists key components clearly. No wasted words or redundant information.
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 tool has no output schema, the description effectively conveys the return value (counts, buckets, conflicts, webhook health, status with reasons). It covers the essential aspects for a simple tool with two optional parameters. Minor gap: does not explain the 'reasons' in detail, but still sufficient.
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 has 100% description coverage for both parameters (scope and namespace), so the description adds minimal new meaning: it hints at optional scoping but does not elaborate beyond schema. Baseline score of 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 it is a health report for memory, listing specific metrics (live/retired/stale counts, aging buckets, unresolved conflicts, webhook delivery health) and notes it rolls up to a status. This distinguishes it from sibling tools like memory_stats, which is more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With many sibling tools, such as memory_stats or memory_insights, the description does not provide context for when this tool is preferred or when not to use it.
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?
Annotations indicate readOnlyHint=true, which is respected. The description adds behavioral context beyond annotations by mentioning hybrid vector+keyword search, optional filters, and temporal decay. No contradictions.
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 (2 sentences, ~30 words), front-loaded with the core functionality, and avoids unnecessary details. Every sentence adds value.
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 complexity (23 parameters, nested objects) and rich schema coverage, the description provides a good high-level summary. It covers key features but could briefly mention reranking or auto_decay. However, schema handles most details, so completeness is adequate.
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?
Input schema provides 100% description coverage for all 23 parameters. The description adds a high-level overview but does not significantly enhance understanding beyond what the schema already offers. Baseline 3 is appropriate.
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 states that the tool searches memories using hybrid vector+keyword search and lists optional filters. It distinguishes the action and resource well, but does not explicitly differentiate from sibling tools like memory_query or memory_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison to other search or retrieval tools.
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?
Annotations provide only openWorldHint=false, so the description carries the burden. It adds 'automatic vector embedding' but omits details on side effects, write policies (on_conflict), or permissions.
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?
A single, front-loaded sentence that efficiently conveys purpose and usage without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 19 parameters and no output schema, the description is minimal. It omits crucial behavioral context like conflict resolution, expiration, volatility, and return value, leaving the agent to infer from the schema alone.
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% with detailed descriptions for each parameter. The tool description does not add extra meaning beyond summarizing 'content, metadata, and automatic vector embedding'. 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 verb 'Store' and the resource 'a new memory', and distinguishes from sibling tools like memory_search and memory_delete by emphasizing saving for later retrieval. It also mentions automatic vector embedding, a key feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool ('to save information, decisions, patterns, or knowledge for later semantic retrieval') but does not explicitly exclude scenarios or mention alternatives like core_memory_append or memory_update for handling conflicts.
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?
Annotations are sparse (only title and openWorldHint=false), so the description carries the burden. It explains the tool is incremental, scans, extracts, and stores, but does not disclose potential overwrite behaviors or idempotency. No contradiction with annotations.
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 two sentences, front-loaded with purpose, and concise. It covers the main aspects without unnecessary detail.
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 description explains the process but does not mention the return value or output, which is notable given no output schema. For a sync operation with 6 parameters, more completeness about outcomes would be beneficial.
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 context about the sync process but does not provide additional meaning beyond the schema for individual parameters. No compensation needed.
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 syncs an Obsidian vault to memory, specifying the verb 'sync' and the resource 'Obsidian vault to memory'. It details actions like scanning markdown files, extracting frontmatter/tags/wiki-links, and storing as searchable memories, distinguishing it from sibling tools like vault_search and vault_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions incremental sync based on file modification times and a force parameter, but does not explicitly state when to use this tool versus alternatives like memory_import or other memory ingestion tools. No when-not or alternative guidance is provided.
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?
The description discloses that the tool modifies memory by merging, pruning, and updating scores, implying destructive potential. However, it lacks detail on side effects like irreversible deletion or impact on related data. The dry_run hint partially compensates.
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 extremely concise: two sentences that front-load the core purpose and end with a key usage tip. Every sentence is meaningful, with no redundancy or fluff.
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 description adequately explains what the tool does and hints at preview via dry_run, but it does not describe the output format (e.g., report structure, returned data). Given no output schema and 8 parameters, more detail on return values would improve completeness.
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?
All 8 parameters are fully described in the schema (100% coverage), so the description adds limited value beyond a usage hint for dry_run. The description does not explain parameter interactions or complex constraints, meeting the baseline for high schema coverage.
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 it runs a 'dream cycle' to merge near-duplicates, prune expired/low-quality entries, and update quality scores. The verb 'consolidate' matches the purpose, and it distinguishes from sibling tools like memory_condense or memory_forget that focus on single aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes using dry_run=true to preview changes, which provides usage direction, but does not explicitly state when to use this tool over alternatives like memory_condense or memory_forget, nor does it specify when not to use it.
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?
Annotations indicate destructiveHint=true, which aligns with the overwrite behavior mentioned. However, the description does not explain behavior when overwrite=false and an ID already exists (likely error), nor does it mention the batch size limit of 500 max items noted in the schema. It also omits return value or error handling.
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 two concise sentences that front-load the primary action ('Import memories from JSON') and add key context about overwrite. No extraneous words or repetition.
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 many optional fields in the data object, but the schema covers them. The description does not mention output, error scenarios, or the batch limit of 500 items. Given the complexity and number of siblings, more context would help, but the description is minimally adequate.
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% with all properties described. The description adds context about the overwrite parameter's purpose ('update existing memories by ID'), but otherwise does not significantly extend the meaning beyond what the schema already provides. 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 'Import memories from JSON' and specifies the action of embedding and storing. It distinguishes from siblings like memory_export, memory_append, and memory_update by indicating batch import with optional overwrite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using overwrite=true for updating existing memories, but it does not explicitly differentiate when to use this tool versus alternatives like memory_store (single store) or memory_append (append to existing). No when-not-to-use advice is given.
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?
The description discloses key behavioral traits: a saturating curve for level increases, no collapsing of other topics, and the role of the agent in providing classified topics. This goes beyond the minimal annotations, which only set openWorldHint=false. It lacks details on auth or rate limits but is sufficient.
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 two sentences, front-loaded with the core purpose, and no superfluous text. Every sentence contributes to understanding the tool's function and behavior.
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 explains the core mechanism and actions well, but it does not describe the output format of the profile (no output schema). With 5 parameters and no output schema, a brief mention of what 'get' returns would improve completeness. Still, it covers essential aspects.
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 schema already describes all parameters. The tool description adds some context for action semantics but does not provide meaning significantly beyond the schema. 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 is an adaptive per-user expertise profile with two actions: observe (record demonstrated knowledge) and get (return profile). It uses specific verbs and resource, and the focus on per-user expertise distinguishes it from sibling memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when to use this tool versus alternatives. It explains the actions but offers no guidance on when not to use or comparisons to other memory tools. The agent is left to infer usage context.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe read operation. The description adds context about the hybrid search mode, default namespace behavior, and the ability to search memories under a different namespace (e.g., after export). This adds value beyond annotations without contradicting them.
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 consists of two sentences with no filler. The first sentence front-loads the main purpose (search method and scoping), and the second adds key nuance about namespace defaulting. Every sentence earns its place, and the length is appropriate for the tool's complexity.
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?
Given the tool has 9 parameters, 2 required, and no output schema, the description covers the main search action and namespace behavior. However, it lacks explanation of how 'scope', 'tags', 'min_confidence', and search modes interact, or what the result format looks like. With a richer schema already documenting these, the description falls short of fully preparing an agent for all use cases.
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 provides additional meaning for the 'namespace' parameter, explaining its default behavior and use case. It also implicitly clarifies the 'search_mode' enum by mentioning hybrid vector+keyword. This adds meaningful context beyond the schema descriptions.
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 states the tool performs hybrid vector+keyword search on memories scoped to a namespace. It specifies the search method and scoping, but does not explicitly differentiate from the similar sibling 'memory_search' (which likely lacks namespace scoping). The verb 'search' and resource 'memories' are specific enough for an agent to understand the core functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the explicit namespace parameter vs the default (vault folder name), including an example scenario. However, it does not mention when not to use this tool in favor of alternatives like memory_search or memory_query, which would be helpful for an agent deciding between siblings.
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?
Annotations declare readOnlyHint=true, and the description adds value by detailing return fields (content, char_limit, used count) and constraints (bounded, always-in-context). No contradictions with annotations.
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?
Single sentence that is efficient and front-loaded with the verb and object. Every word contributes to understanding.
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?
Given no output schema, the description adequately covers return values (content, char_limit, used) and explains the tool's role (pinned core memory). Sufficient for a read operation.
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 does not add meaningful parameter-specific details beyond what the schema provides; it only contextualizes the overall tool purpose.
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 specifies a clear verb ('Read'), resource ('pinned core memory block'), and scope ('for a (scope, namespace)'). It distinguishes from siblings by focusing on the 'pinned' and 'always-in-context' core memory, contrasting with other memory tools like memory_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like memory_get or core_memory_append/replace. The description implies a read operation for core memory but does not specify when not to use it or suggest alternatives.
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?
Annotations only provide openWorldHint=false, so the description carries the burden. It discloses replacing the first occurrence, possible errors (not_found, core_memory_full), and hints at persistence ('pinned core-memory block'). However, it does not specify if the operation is atomic or if any side effects occur beyond the replacement.
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?
Two sentences: first explains the core operation, second adds error information and usage hint. Every word serves a purpose with no fluff. Front-loaded and efficient.
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?
Lacks output details for success (e.g., returns nothing or updated block?). No output schema exists. The description covers errors but leaves the agent guessing about success behavior. Adequate for a replace operation but not fully complete.
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?
Input schema has 100% description coverage, so every parameter's meaning is already documented. The tool description does not add further semantic value beyond what schema provides, meeting the baseline for high coverage.
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?
Description clearly states 'Replace the first occurrence of old_text with new_text in the pinned core-memory block', specifying verb and resource. It also mentions error conditions (not_found, core_memory_full) and a usage hint ('update or compact the block'), which distinguishes it from sibling tools like core_memory_append or core_memory_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to update or compact the block' provides some guidance on when to use, but it does not explicitly contrast with alternatives like core_memory_append or core_memory_get. No when-not-to-use scenarios are mentioned, leaving room for ambiguity in 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?
The description explains the write behavior: it creates .md files per memory, handles namespaced memories under subdirectories, and claims losslessness. It also notes the vault_path directory is created if missing. It lacks explicit mention of overwrite behavior if files already exist, but overall provides good behavioral context beyond the minimal annotations.
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 only three sentences, front-loaded with the core purpose in the first sentence. Every sentence adds value: purpose, structural detail, and filtering option. No redundancy or fluff.
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?
Given the parameter count and schema coverage, the description is adequate but lacks completeness in differentiating from similar export siblings (e.g., memory_export). It does not explain return behavior or error handling, and the absence of an output schema shifts burden to the description, which it partially meets.
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 has 100% coverage of parameter descriptions, so the description adds little extra meaning. The vault_path description reiterates the purpose, and scope/namespace are described for filtering. No additional semantic enrichment beyond the schema is provided.
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 verb 'write', resource 'memories to Obsidian vault', and specifies the output format (.md with YAML frontmatter). It distinguishes itself from vault_sync by calling itself 'the reverse', providing clear purpose and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's the reverse of vault_sync and optional filtering by scope/namespace, which hints at when to use it. However, it does not explicitly state when not to use it or compare it to other sibling export tools like memory_export or memory_export_dataset, leaving 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?
The description discloses key behaviors: heuristic analysis, deduplication against existing memories, and optional auto-store. Since annotations only provide openWorldHint, this adds significant behavioral context beyond what annotations offer.
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 a single sentence that efficiently conveys the core functionality and key features, with no wasted words.
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?
Given 8 parameters and no output schema, the description covers the main action but does not explain what is returned (e.g., whether extracted learnings are returned or only stored). It adequately describes the process but leaves some ambiguity about output.
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 descriptions cover 100% of parameters with clear definitions. The tool description provides overall context but does not add additional meaning beyond the schema details, meeting the baseline for high coverage.
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 extracts decisions, patterns, error fixes, and conventions from a session transcript using heuristic analysis. It also mentions deduplication and optional auto-store, distinguishing it from siblings like memory_extract_entities or memory_ingest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting learnings from transcripts but does not explicitly state when to use this tool over alternatives, nor does it provide exclusionary guidance. It is adequate but lacks context for 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?
Annotations provide minimal behavioral hints (only openWorldHint=false). Description adds important details: automatic chunking by content type, embedding, and provenance storage. No contradiction.
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?
Two efficient sentences: first defines core behavior, second adds usage context. No redundancy.
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?
Covers ingestion flow and usage context but omits what is returned (e.g., success confirmation, document IDs). Lacks expected output details.
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 covers all 14 parameters with descriptions (100% coverage). Description does not add parameter-specific meaning beyond what schema provides.
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?
Specifically describes ingesting a full document with automatic chunking, embedding, and provenance storage. Clearly differentiates from sibling memory tools that handle smaller operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use this for large documents' but does not explicitly exclude other scenarios or mention alternative tools for smaller documents. Lacks when-not-to-use guidance.
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?
The description discloses key behaviors: deduplication (repeat capture is a NOOP), template filling based on document_type, and a generic scaffold for unknown types. Annotations provide no destructiveHint or readOnlyHint, so the description carries the burden and meets it reasonably.
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?
Two sentences with no wasted words. The first sentence packs purpose, template behavior, and dedup, while the second handles edge cases. Front-loaded with the most important information.
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 tool with 10 parameters (1 required) and no output schema, the description covers core behavior well. It explains template usage and dedup. However, it doesn't mention return values or error conditions, which could be helpful.
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 explaining how fields map to sections and that omitted sections get a placeholder, which is beyond the parameter descriptions in the schema.
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 states the tool captures a structured lesson or incident by filling a section template. It distinguishes from generic memory tools by specifying template mapping and dedup behavior, but doesn't explicitly differentiate from siblings like memory_append or memory_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when capturing lessons or incidents with structured fields. The description notes that repeat captures are NOOP, which guides against redundant calls, but doesn't explicitly state when not to use or provide alternatives.
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 readOnlyHint or destructiveHint annotations, the description takes responsibility. It clearly states that preview is non-mutating and confirm clears the stale flag (mutation). However, it does not disclose potential side effects, permissions, or rate limits.
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 extremely concise (3 sentences), front-loaded with 'Change-propagation surface', and uses structured listings for each action. No superfluous words; every sentence earns its place.
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?
Given the tool's moderate complexity (3 actions, 5 parameters, no output schema), the description covers core purpose and action behaviors. However, it lacks details on return format, scope/namespace effects, and fails to specify how results from 'list' are structured.
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 schema already describes each parameter well (e.g., action enum values). The tool description adds narrative context but does not significantly enhance parameter understanding beyond what the schema provides.
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 defines the tool as a change-propagation surface with three distinct actions (list, preview, confirm), each with a specific verb and resource. It differentiates from siblings like memory_list by focusing on flagged memories needing revalidation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts (e.g., list to see stale memories, preview to check impact, confirm to clear), but lacks explicit guidance on when to use this tool vs alternatives like memory_list or memory_verify. No when-not-to-use advice.
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?
Beyond the minimal annotations (title, openWorldHint=false), the description adds key behavioral details: output is a deterministic grid with labeled arrow-tipped edges, vault_path confines writing, and filenames are sanitized. This provides good transparency for a read-only export operation.
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 tightly written (~80 words), front-loads the purpose, and every sentence adds unique value. No redundant or extraneous content.
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 tool with 5 optional parameters, no output schema, and moderate complexity, the description covers core behavior (what becomes nodes/edges, filtering, file writing). The return value when vault_path is omitted is explained as 'canvas object,' which is somewhat vague but acceptable. Performance or size limitations are not mentioned.
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 baseline is 3. The description adds context on output structure ('memory_links become labeled, arrow-tipped edges') but does not enhance parameter meaning beyond what 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 clearly states the tool exports the memory graph as a JSON Canvas 1.0 .canvas file, which opens as a spatial board in Obsidian. This specific verb and resource distinguishes it from sibling tools like memory_export, memory_export_dataset, and memory_export_vault.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering and two modes (return object or write file) but does not explicitly state when to use this tool versus alternative export tools. Usage context is implied but not contrasted with siblings.
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?
Annotations provide readOnlyHint=true and no destructive hint. Description adds that it is read-only, quality-filtered by importance/confidence, and emits JSONL without modifying state. This adds value beyond annotations, though could mention pagination or behavior on empty results.
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?
Two sentences with no wasted words. First sentence states core purpose and output shape, second clarifies safety and output file format. Highly concise and front-loaded.
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 read-only export tool with 6 parameters and no output schema, the description covers purpose, filters, output format, and safety. It doesn't detail output field structure or edge cases, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description reinforces the meaning of min_importance/min_confidence and format, but does not add new information beyond the schema. 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 states a specific verb ('export'), resource ('high-signal rows...as instruction→output training pairs'), and differentiates from siblings by focusing on training data generation for LoRA/distillation. It clearly identifies the tool's intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (generating training data) and contrasts with the generic 'memory_export' sibling, but lacks explicit when-not-to-use guidance or alternative recommendations. Usage context is clear but not exhaustive.
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?
Annotations already declare readOnlyHint=true, so safety is known. Description adds the behavioral detail about including child chunks, but does not disclose other traits like return structure or pagination.
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?
Two sentences, front-loaded with the core action, no wasted words. Efficient and clear.
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 simplicity of the tool (2 params, no output schema, full annotations), the description is mostly complete. However, it could mention what the return value is (the memory object) to be fully self-contained.
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% and both parameters have descriptions. The description adds minimal additional meaning beyond the schema field descriptions for 'id' and 'include_chunks'.
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?
Description uses specific verb 'Retrieve' and identifies the resource ('specific memory by its ID'). Clearly distinguishes from sibling tools like memory_search, memory_delete, etc. Optional include_chunks adds further clarity.
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?
Usage is implied: use when you need to fetch a memory by its exact ID. No explicit alternatives or exclusions provided, but the context of the tool name and siblings makes it reasonably clear.
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?
Annotations already mark the tool as read-only (readOnlyHint: true). The description adds substantial behavioral context: hybrid search seeding, hub-avoiding graph walk, token budget, truncation with actionable hint. No contradiction observed.
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?
A single, dense sentence that packs all key information: purpose, mechanism, and return format. No wasted words, front-loaded with the core verb. Every phrase earns its place.
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 tool's complexity (graph walk, token budget, truncation) and absence of output schema, the description covers the main aspects: seeds from hybrid search, hub avoidance, max_hops, token budget, and return of 'context string plus structured nodes' with truncation hint. Slightly vague on the exact structure of nodes, but overall sufficient.
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 each parameter thoroughly. The description only briefly mentions max_hops and token-budgeted, adding little extra meaning beyond the schema's existing 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 answers a question with a tight, relevant subgraph from memory, explicitly distinguishing it from flood-fetch alternatives. It mentions hybrid search, graph walking, and token budgeting, which differentiates it from siblings like memory_query_structured or simple memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for concise memory queries but does not explicitly state when to use this tool over alternatives like memory_query_structured or when not to use it. No exclusions or comparisons to siblings are provided.
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?
Annotations already provide readOnlyHint=true, but the description adds behavioral context: it operates over 'currently-valid top-level memories', returns structured questions with evidence, and supports optional filters. No contradictions with annotations.
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 dense and front-loaded with the core purpose. It earns each sentence by explaining what the tool returns and the types of questions. Could be slightly more structured, but it is efficient and clear.
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?
Given the tool has no output schema, the description fully explains the return format ({ questions: [{ question, type, evidence }], count }) and mentions the optional scope/namespace filters and limit. It is complete for safe, effective use.
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 parameter descriptions already exist. The description restates the optional filters and default limit, which adds marginal value beyond the schema. No additional syntax or format details are provided beyond what the schema covers.
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 surfaces open questions and gaps (ambiguous links, gaps, orphans) from the memory graph, using specific verbs like 'surfaces' and 'digest'. It distinguishes from sibling tools by its unique output format and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification and learning ('so you know what to verify or learn next') but does not explicitly contrast with other analytical tools like memory_insights or memory_search. No when-not-to-use or alternative guidance is provided.
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?
Annotations already mark this as read-only (readOnlyHint=true). The description adds behavioral detail by stating it 'uses vector similarity to discover connections', which goes beyond the annotations. No contradictions. For a read-only tool, this is sufficient context.
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 two sentences long, front-loading the core purpose, with no unnecessary words. Every sentence adds value.
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 the tool's purpose and method. With 3 parameters fully described in the schema, it is mostly self-contained. However, there is no output schema and the description does not hint at the return format (e.g., list of similar memories with scores), which would improve completeness for a search tool.
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% (all 3 parameters have descriptions). The description does not add significant extra meaning beyond what the schema already provides, so baseline 3 is appropriate. It does provide context that the id parameter is for a memory and that similarity is vector-based, but this is implicit from the tool's purpose.
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 verb 'find', specifies the resource as 'memories semantically related to a given memory ID', and explains the method 'vector similarity'. This distinguishes it from sibling tools like memory_search (which searches by text query) and memory_get (which retrieves a specific memory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use case (finding related memories by ID) but provides no explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites. Given many sibling tools, explicit context would improve this dimension.
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?
The description reveals that the tool clears valid_to/tx_expired and restores content, and returns flags. It does not mention any destructive side effects, reversibility, or authorization requirements. With no annotations beyond title, the description provides moderate behavioral context but lacks depth.
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 (three sentences), front-loaded with 'Bring a memory back', and structured to explain two operations clearly. No unnecessary words.
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 explains the tool's behavior and return flags, compensating for the lack of output schema. It addresses the two main use cases but could clarify whether the id must belong to a currently soft-forgotten or condensed memory.
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 description restates the schema's parameter description without adding new meaning. The schema already covers the parameter purpose adequately, so the description offers no additional semantic value.
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 restores a memory, specifying two distinct actions: un-tombstoning a soft-forgotten memory and/or restoring condensed content. It uses specific verbs and distinguishes from siblings like memory_forget and memory_condense.
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 explains when to use the tool (on soft-forgotten or condensed memories) and implies it is the inverse of memory_forget with hard:false and memory_condense. However, it does not explicitly exclude other states or provide alternative tool names for different scenarios.
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?
Annotations declare readOnlyHint=true, and the description confirms a read-only operation ('Check the sync status'). The description adds detail about the returned data (counts, times, memory count), providing useful context beyond what annotations convey. No contradictions.
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 a single sentence that efficiently conveys purpose and output without any wasted words. It is front-loaded with the action and resource, making it easy to parse.
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?
With one parameter, no output schema, and readOnlyHint provided, the description adequately covers the tool's behavior and return values. It could mention potential errors or prerequisites (e.g., vault must exist), but for a simple status check it is sufficiently complete.
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% with a single parameter 'vault_path' described as 'Absolute path to the Obsidian vault directory'. The description does not add further meaning beyond the schema, so baseline score of 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 uses specific verb 'Check' and resource 'sync status of an Obsidian vault', listing exact data returned (total files, synced/pending/changed counts, last sync time, memory count). This clearly distinguishes from siblings like vault_sync (which performs sync) and memory_stats (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking sync status, but provides no explicit guidance on when to use it versus alternatives (e.g., vault_sync for performing sync, or memory_stats for different stats). No when-not-to-use or context exclusions are mentioned.
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?
Annotations already declare readOnlyHint=true, and the description adds transparency about the return format (two possible shapes) and lists the timeline fields. No contradictions; the description enriches the behavioral understanding beyond annotations.
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 a single, well-structured sentence that front-loads the tool's purpose and efficiently lists key details and return types without any fluff.
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?
Given the tool's simplicity (one parameter, no output schema), the description fully covers the needed context: what it does, what it returns, and how it differs from similar tools. No gaps are apparent.
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 schema has 100% description coverage for the single parameter, and the tool description reiterates the parameter's purpose. While clear, the description adds minimal new meaning beyond the schema's param 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 tool returns a bi-temporal timeline and version history for a memory, using specific verbs like 'returns' and listing the fields. It distinguishes from siblings like memory_get and memory_versions by focusing on the combined timeline and history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description (detailed history retrieval), but there is no explicit guidance on when to use this tool over alternatives like memory_get or memory_versions, nor when not to use it.
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?
Annotations already declare readOnlyHint=true. The description adds specific behavioral details about the types of insights returned (conflicts, stale memories, contradicted facts, unsupported decisions) and notes scoping is optional. This provides useful context beyond annotations, though it does not cover performance or rate limits.
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 two sentences, front-loaded with key information, and contains no fluff. Every phrase adds value: it specifies the content, notes the complementary tool, and declares read-only and scoping.
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 description explains the content of insights and complementarity, but does not mention the return format or structure, which is important since there is no output schema. Given the tool's complexity (read-only, optional scoping, three parameters), the description is adequate but leaves room for improvement regarding output details.
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 has 100% coverage with descriptions for all parameters (scope, namespace, limit). The description only mentions 'optionally scoped,' which aligns with the scope parameter but adds no new detail about parameter usage or syntax. Baseline 3 is appropriate since the schema does the heavy lifting.
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 provides a digest of items needing attention: unresolved conflicts, stale memories, contradicted facts, and decisions without evidence. It differentiates from the sibling 'memory_questions' tool, which captures next actions, making the purpose distinct and specific.
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 complements memory_questions, indicating when to use this tool over that alternative. It also notes that it is read-only and optionally scoped, but does not list exclusions or provide a full decision tree for when to use versus other tools.
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?
Annotations already declare readOnlyHint=true; description adds that no content is returned, reinforcing non-destructive behavior. No contradictions.
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?
Two sentences, front-loaded with purpose and usage guidance. No extraneous information, highly concise.
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?
Description lacks details on return structure, pagination behavior, and how parameters like scope/namespace interact. Given 6 parameters and no output schema, more completeness is needed.
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 description adds little beyond schema. Baseline 3 is appropriate as it provides overall context but no parameter-level details.
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?
Description clearly states 'Get a lightweight index of all memories' with specifics (titles, types, tags, scores) and contrasts with expensive searches, distinguishing it from siblings.
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?
Explicitly recommends using this tool before expensive searches, providing clear context. However, it does not explicitly mention when not to use or list alternatives.
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?
Annotations indicate readOnlyHint=true, consistent with the read-only nature of surfacing mentions. The description adds behavioral details: uses embeddings + entity graph, excludes existing links, and proposes latent connections. It does not contradict annotations and provides useful algorithmic context, though it does not cover return format or pagination.
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 three sentences long and front-loads the main purpose in the first sentence. It is well-structured and information-dense, though slightly verbose in the second sentence. Overall, it is concise and easy to parse.
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 tool has no output schema, the description explains the output type (auto 'similar_to' suggestions) and excludes existing links. It also suggests next steps, making it complete for a discovery tool. No major gaps are apparent.
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 covers all three parameters with descriptions (100% coverage). The description does not add significant new parameter semantics; it mentions the algorithm but not parameter-specific details. With high schema coverage, the baseline is 3, and the description does not elevate it.
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 surfaces unlinked mentions for a memory, which are semantically related but not explicitly linked. It distinguishes itself from typical text matching by using embeddings and entity graph, and the resource (memory) and verb (surface) are specific. The description differentiates it from siblings like memory_related or memory_query.
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 clear guidance on when to use the tool: to discover latent connections that the agent never made. It also suggests a workflow after discovery, such as using memory_extract_entities or storing a link, implying the tool is for discovery, not confirmation. It does not explicitly list when not to use it, but the context makes it clear.
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?
Annotations already declare readOnlyHint=true (safe read). The description adds that the process is agent-driven with no LLM in the server (deterministic algorithm), and that it runs on demand via weighted label propagation. This provides useful behavioral context beyond the annotations.
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?
Three sentences with no redundant words. The first sentence explains what it does and how, the second describes the output, and the third gives usage context. Information is front-loaded and every part adds value.
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 complexity of community detection and lack of output schema, the description explains the algorithm, output contents, and usage context well. It could mention potential computational cost or size limits, but overall it is complete enough for an agent to decide when to use.
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% with both parameters (limit, min_size) clearly described. The description does not add any additional semantic information about parameter usage or defaults beyond what the schema provides, so 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 detects communities over the entity graph via weighted label propagation and returns top entities with linked memories. It distinguishes itself from chunk-level search by providing a corpus-level view, making its purpose specific and distinct from siblings.
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?
Explicitly contrasts with chunk-level search and advises using it to synthesize named themes for global questions like 'what are the main themes?'. However, it does not explicitly list when not to use or mention specific sibling alternatives beyond the implicit contrast.
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?
The description adds important behavioral detail: 'Preserves original content for later restoration.' This goes beyond the minimal annotations (only title and openWorldHint=false) by clarifying the non-destructive nature of the operation. It also mentions that it is for old memories and after consolidation reports, providing context.
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 two sentences with no wasted words. The first sentence clearly states the primary action, and the second adds important context. It is front-loaded and efficient.
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 tool with 2 well-documented parameters and no output schema, the description covers the core purpose, usage trigger, and a key behavioral aspect (preservation). It is sufficiently complete for an agent to understand when and how to use it, though it omits potential return values or error states.
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 has 100% coverage, with detailed descriptions for all parameters including the batch structure and target_level enum. The tool description does not add significant new meaning beyond summarizing what the schema already states, so a baseline score of 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 indicates the tool applies agent-generated summaries to condense old memories, with the specific verb 'condense' and resource 'old memories'. It also distinguishes itself by noting it preserves original content for later restoration, setting it apart from destructive operations like memory_delete.
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 explicit guidance: 'Use after consolidation reports flag condensation candidates.' This clearly indicates when to use the tool. However, it does not explicitly list alternatives or when not to use it, though the context implies it is for condensing rather than other operations.
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?
The description adds significant behavioral context beyond the minimal annotations (only openWorldHint). It discloses the selection criteria (high importance × recent), the linking mechanism ('derived_from'), and the provenance marking, which are critical for understanding the tool's operation. No contradictions with annotations.
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 a single, well-structured sentence that front-loads the key concept and efficiently covers both modes. It is concise with no fluff, though the dense structure could be slightly improved for readability.
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 7 parameters (0 required), full schema coverage, and no output schema, the description provides adequate context for the core functionality. It covers the selection algorithm, storage mechanics, and linking. It lacks details about error handling or edge cases, but for this complexity level, it is sufficiently complete.
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?
Although schema coverage is 100%, the description enhances understanding by explaining the role of each mode and how parameters like 'mode', 'insight', and 'source_ids' interact. It clarifies the 'gather' output (material + instruction) and 'store' behavior (persist with provenance). This adds value beyond the basic 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 defines the tool as a 'Generative-Agents-style reflection' with two distinct modes ('gather' and 'store'). It specifies the resource (memories) and action (reflection), effectively distinguishing it from sibling tools like memory_condense or memory_insights by emphasizing its agent-driven, no-LLM-in-server approach.
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 explains when to use each mode: 'gather' for retrieving reflection-worthy material and 'store' for persisting synthesized insights. While it doesn't explicitly state when not to use this tool or mention alternatives, the context is clear and the dual-mode design provides direct usage guidance.
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?
Annotations provide minimal (openWorldHint=false), but description adds key behavioral traits: first-call creation, appending, isolation by session_id, return fields, re-embedding, and versioning. No contradictions with annotations.
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?
Description is two sentences, front-loaded with core purpose, no wasted words. Each sentence adds value.
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?
No output schema, but description explains return values. It covers creation/append logic, isolation, versioning, and scope/namespace context. Complete for a tool with 5 parameters and no nested objects.
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 schema already documents parameters. Description reinforces keying behavior and title usage but adds no new semantics beyond what schema provides. 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 does 'per-session capture' with a specific keying mechanism and explains create vs append behavior, distinguishing it from general memory tools like memory_store. It uses specific verbs and resources.
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 gives clear context for when to use ('daily note for agents', session-specific notes) and implies when not to use (for non-session or overwriting needs). However, it doesn't explicitly name alternative sibling tools or state exclusion criteria.
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?
Annotations already declare readOnlyHint=true, and the description adds valuable details about what statistics are returned (breakdowns, storage, expired count). No contradiction with annotations. Description enhances understanding of the tool's behavior beyond mere read-only nature.
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?
Single, well-structured sentence that front-loads the purpose ('Get usage statistics') and efficiently enumerates key outputs. No wasted words.
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?
Although no output schema is provided, the description adequately lists the types of statistics returned. Parameters are well documented. For a read-only stats tool, the description is sufficiently complete for an agent to understand its function and outputs.
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?
Input schema covers all 3 parameters with descriptions (scope, namespace, department). Baseline 3 is appropriate. The description mentions breakdowns by scope/department/type, which adds some context about parameter usage, but does not significantly expand beyond the schema.
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?
Description clearly states the tool retrieves usage statistics, listing specific metrics (total memories, chunks, documents, breakdowns, storage size, expired count). Distinguishes from numerous sibling tools that perform other operations like appending, getting, or replacing memories.
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?
Implied usage for obtaining summary statistics, but no explicit guidance on when to use vs. alternatives like memory_get or memory_insights. Context is clear enough for an agent to differentiate, but lacks direct exclusions or when-not recommendations.
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?
The description discloses significant behavioral traits including SSRF validation, HMAC signing, enqueueing, retry, circuit-breaker, and dead-letter mechanisms. These go beyond the annotations (which only have openWorldHint) and provide critical safety and performance context.
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 a single dense paragraph that efficiently covers key behaviors and actions. While no fluff, it could be slightly improved with bullet points or more structured layout for better scannability.
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 tool with 7 parameters and 4 actions, the description covers functional behavior well. However, it lacks details on return values, error handling, and authentication requirements, leaving some gaps for complete understanding.
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 context about SSRF validation, HMAC secret signing, and event types, enhancing understanding beyond the parameter schema.
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 it manages an event bus for webhooks, listing actions (register, list, delete, dispatch) and the context of memory mutations. It distinguishes itself from sibling tools that focus on memory operations rather than webhook management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'gated on MCP_WEBHOOKS' implying a feature flag, but does not explicitly state when to use this tool versus alternatives like those for direct memory operations. There is no guidance on preconditions or when not to use.
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?
Annotations already declare readOnlyHint=true, and the description reinforces this and explains how tiers are derived (access recency + frequency). It adds value beyond annotations with no contradictions.
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?
Two sentences, front-loaded with the core action and output. No redundant words; each sentence adds essential information.
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 the main output (tier distribution, hot working set) and scope filters. With no output schema, it provides enough context for an agent to understand the result. Could mention that it's a snapshot or list, but sufficient.
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 schema documents both parameters fully. The description mentions 'optional scope/namespace filter' but adds no new semantic detail beyond what the enum and description in the schema 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 clearly states the tool shows 'MemGPT-style tier distribution (hot / recall / archival)' and 'list the hot working set'. It specifies the resource (memories) and action (show/list), distinguishing it from sibling tools like memory_get or memory_stats.
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 mentions it's read-only and has optional scope/namespace filters, giving context on when to use. However, it does not explicitly exclude other tools or provide when-not guidance, which could be helpful given the many sibling tools.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context: it only counts 'currently-valid top-level memories', handles unattributed memories by bucketing them, and describes the return structure in detail, which goes beyond the annotations.
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 two sentences, front-loading key functionality and structure. Every sentence adds essential information with no redundancy or fluff.
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?
Given the tool has only two optional parameters and no output schema, the description fully explains the return structure and filtering. It covers all necessary aspects for an agent to correctly use the tool.
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%, with each parameter described (scope: 'Memory scope for isolation', namespace: 'Namespace within scope'). The description mentions optional filters but adds no new meaning beyond the schema, so 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 returns an attribution rollup of top-level memories by agent, with specific fields (by_agent, by_author, total). It distinguishes itself by noting the difference between agent and author, and mentions unattributed memories, which sets it apart from sibling tools like memory_stats.
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 implies usage for multi-agent/team attribution and includes optional filters, but does not explicitly state when to avoid this tool or mention alternatives. It provides clear context but lacks explicit guidance on when not to use it.
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?
Discloses refusal behavior on exceeding char_limit and suggests alternative. Lacks explicit mention of mutation or state change, but 'append' implies it. Annotations are minimal (only openWorldHint=false), so description adds useful behavioral context.
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?
Two sentences, front-loaded purpose, no fluff. Every word contributes to understanding.
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?
Adequate for a simple append tool. Mentions error case but does not describe success return. No output schema, but for a tool with clear side effects, this is acceptable. Could mention success confirmation.
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%; description adds meaning beyond schema by explaining newline separation and the overflow condition. Enhances understanding of text parameter behavior.
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?
Clear verb 'Append' and resource 'pinned core-memory block', with specific detail 'newline-separated when non-empty'. Distinguishes from sibling core_memory_replace by mentioning the alternative for overflow.
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?
Explicitly states when to use: append text, and when not: if exceeding char_limit, use core_memory_replace instead. Also provides error condition 'core_memory_full'.
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?
Annotations already indicate destructiveHint=true, but the description adds substantial behavioral details: for hard:true it returns a portability copy before permanent deletion, irreversible and cascading; for hard:false it is recoverable and stamps valid_to. No contradiction with annotations.
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?
Description is moderately concise; each sentence contributes useful information. It is front-loaded with general purpose then explains modes. A slight reduction in length could improve conciseness, but overall it is well-structured.
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?
Given the tool has two modes (soft/hard), no output schema, and requires understanding of recovery and portability, the description covers all aspects: return object shape, behavior differences, and GDPR compliance. It is complete for an agent to use 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, but the description adds significant meaning beyond schema: it explains the effect of each mode in detail (e.g., soft-delete stamps valid_to, hard erases after export), which enhances agent understanding.
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?
Description clearly states it is a 'GDPR-grade forget' operation that is additive to memory_delete. It specifies verb 'forget' on resource 'memory', and distinguishes itself from memory_delete by noting it does NOT replace it.
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 explains when to use soft vs hard delete modes and mentions GDPR context. It implies this tool is for data subject access/erasure, while memory_delete is for regular deletion. However, it does not explicitly state when not to use it.
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?
Annotations already declare readOnlyHint=true, so the bar is lower. The description adds useful behavioral context: it operates on 'currently-valid, top-level memories', is 'exact, deterministic', and lists filtering criteria. It does not contradict annotations and provides additional transparency about the tool's scope and nature.
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 two sentences with no wasted words. The first sentence is comprehensive but well-structured, and the second provides usage guidance. It front-loads the purpose and uses clear, direct language.
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 tool's complexity (5 parameters, nested objects, no output schema), the description covers the main capabilities well. It explains filtering, sorting, pagination, and field projection. It does not describe the return format, but that is partially mitigated by the schema's lack of output schema. Overall, it is sufficiently complete for an agent to understand and use the tool.
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 low (20%), but the description compensates by listing the filter criteria (scope, namespace, department, document_type, language, tags with AND, min_importance, created_at range) and sort options (created_at, updated_at, importance_score, title). It also mentions pagination and projection. The description adds significant meaning beyond the schema's minimal 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 it's a structured query over memory properties, listing specific operations (filter, sort, paginate, project) and distinguishing from fuzzy memory_search. It uses specific verbs and resources, and the distinction from siblings is explicit.
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 guidance: 'Exact, deterministic retrieval that complements fuzzy memory_search' and gives a concrete example ('all decision memories in namespace=acme with importance>0.7, newest first'). It clearly tells when to use this tool versus the sibling 'memory_search'.
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?
Discloses that save upserts are versioned and diffable, and that resume returns latest. Also notes bypassing dedup write-gate, which is beyond annotation's openWorldHint=false.
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?
Two sentences: first states purpose and structure, second explains key behavioral traits. Front-loaded and no unnecessary words.
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?
Provides sufficient context for a 10-parameter tool with no output schema: mentions versioning, diff capability, and bypassing dedup. Could optionally describe return format, but not required.
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 has 100% description coverage for parameters; description adds meaning by explaining action enum values, session_key default, and the overall state structure.
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?
Clearly states 'Save or resume a resumable session-state' with specific fields (summary, next_steps, etc.). Differentiates from siblings by mentioning versioning and bypassing dedup write-gate.
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?
Explicitly describes when to save vs resume, and notes that it bypasses dedup for incremental saves. Does not provide explicit 'when not to use' or alternative tools, but context is clear.
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?
Annotations already declare readOnlyHint=true, so the description does not need to reiterate safety. It adds value by explaining the output format ('added/removed lines plus a summary count') and noting that 'to' defaults to the current version. No contradictions with annotations.
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 only two sentences, with every word contributing. The first sentence states the core purpose with a trust metaphor, and the second gives usage guidance and output summary. No wasted text.
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 tool has no output schema, so the description must convey return format. It mentions 'added/removed lines plus a summary count', which is adequate but could be more precise (e.g., format of the diff). Still, the description suffices for an agent to understand the tool's behavior.
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?
All three parameters are documented in the schema (100% coverage). The description adds meaning by stating that 'to defaults to the current version', which is not in the schema. This provides clarity beyond the schema alone.
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 shows a line-by-line diff between two revisions of a memory, using a specific verb ('Show') and resource ('diff'). It distinguishes itself from sibling tools like memory_history, memory_versions, and memory_version_restore by focusing on detailed comparison for auditing.
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 'Use it to audit exactly what an edit changed', providing clear usage context. However, it does not mention when not to use it or directly contrast with alternative tools (e.g., memory_versions for listing, memory_history for history).
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?
The description explicitly states the tool is read-only, matching the readOnlyHint annotation. It adds behavioral context beyond annotations by detailing the return format (markdown with section headers for known types) and behavior for unknown types (generic scaffold with known:false). No contradictions.
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 two sentences, front-loaded with purpose, and every sentence adds value. It avoids redundancy and is efficiently structured.
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?
Given the single parameter, full schema coverage, and presence of annotations, the description covers all necessary context: what it does, output format, behavior for known/unknown types, and read-only nature. No gaps remain.
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% and the schema description covers the parameter. The description adds value by listing example types (decision, incident, etc.) and explaining the generic behavior for unknowns, enhancing semantic understanding beyond the schema alone.
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 fetches an Obsidian-style note scaffold for a document_type to maintain structural consistency. It uses the specific verb 'fetch' and identifies the resource as a note scaffold, distinguishing it from sibling tools that store or retrieve actual memories.
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 clear guidance: fetch the scaffold, then store it via memory_store. It implies when to use (prior to storing structured notes) but does not explicitly mention when not to use or list alternatives, though the sibling tools include memory_store and others.
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?
Annotations already declare readOnlyHint=true, and the description reinforces that it is 'Read-only'. It also discloses important behavioral details: the verification uses the machine's trusted signing key (not the embedded key), and explains the four possible statuses (verified, unsigned, tampered, untrusted) with a definition of 'untrusted'. This provides transparency beyond annotations.
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 four sentences, front-loaded with the main action. Each sentence contributes unique information: the verification process, modes, return format, and read-only nature. No redundant or vague phrasing; it is efficient and well-structured.
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?
Despite no output schema, the description explains the return value (per-memory status + summary dict). All 5 parameters are covered in the schema, and the description adds context for batch mode and key trust. Given the tool's complexity, this is complete and leaves no ambiguity.
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 explaining that omitting 'id' triggers batch verification, and it clarifies the 'trusted_pubkeys' parameter as 'additional trusted signer public keys ... a memory signed by any of these ... verifies instead of reading untrusted'. This gives semantic meaning beyond the schema's brief 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 begins with 'Verify the signed provenance envelope of memories: recomputes each content_hash and ed25519-checks the signature against THIS machine's trusted signing key', which is a specific verb and resource. It clearly distinguishes from siblings by focusing on cryptographic verification, unlike other memory tools that perform different actions (e.g., query, update, delete).
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 states 'Verify one by id, or a batch by scope/namespace', providing clear usage modes. It explains the distinction between 'untrusted' and 'tampered' statuses, offering context for interpreting results. However, it does not explicitly state when not to use this tool or mention alternatives, but this is not critical given its unique purpose.
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?
The description states 'Read-only' which matches the readOnlyHint=true annotation. It discloses the types of results (unresolved and dangling_edges), the resolution method by title, and the effect of scope/namespace sweeping. No contradictions with annotations.
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 (two sentences), front-loaded with the core purpose, and every sentence adds essential detail. No wasted words.
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?
Despite no output schema, the description fully explains what the tool reports (two types of broken links) and how to use it with single or batch modes. It covers all necessary context for correct invocation.
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% with clear parameter descriptions. The description adds value by explaining usage context: 'Pass an id to check one memory, or scope/namespace to sweep a partition' and the title resolution rule, which is not in the schema.
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 it finds broken [[wikilinks]] and specifies two detailed types (unresolved, dangling_edges). It explicitly distinguishes itself from memory_unlinked_mentions as the 'inverse', making 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 provides explicit when-to-use: 'Find BROKEN [[wikilinks]]' and gives two usage patterns (by id or by scope/namespace). It also mentions the alternative 'memory_unlinked_mentions' for the inverse case, offering clear guidance on when not to use this tool.
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:

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

Score Badge

Copy to your README.md:

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

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/YonasValentin/mcp-memory-graph'

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