memora

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap (e.g., memory_hybrid_search vs memory_semantic_search, memory_list vs deprecated memory_list_compact) that could cause confusion for an agent. Additionally, memory_find_duplicates and memory_detect_supersessions serve related but distinct roles.
Naming Consistency4/5
Tools follow a consistent 'memory_<verb>_<noun>' pattern, with a few exceptions like 'memory_tag_hierarchy' (noun-verb order) and the deprecated 'memory_list_compact'. The naming is readable and predictable overall.
Tool Count3/5
With 41 tools, the server is comprehensive but borders on excessive for a typical MCP server. Each tool serves a specific function, but the high count may overwhelm agents compared to the ideal 10-15 tool range.
Completeness5/5
The tool surface is remarkably complete, covering CRUD operations, advanced features (absorb, merge, boost, link), specialized types (issues, todos, documents), search variants, import/export, analytics, and maintenance tools. No obvious dead ends or missing operations for the memory/knowledge domain.
Average 4/5 across 41 of 41 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 5 community issues answered or closed in the last 6 months
- 159 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are present, so the description carries full weight. It only discloses the compact parameter behavior (reduced response size) but omits critical behaviors like pagination, hierarchy depth, sorting, potential performance impact, or whether queries are required. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not optimally front-loaded; the core purpose is stated first, but the Args section is sparse and only covers one parameter. Could be more concise and structured to highlight key parameters and behavior.
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, nested objects in the schema, and a provided output schema (unseen), the description is grossly incomplete. It fails to explain the hierarchy structure, parameter combinations, filtering, or return format, leaving significant gaps for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no parameter descriptions. The description only explains the 'compact' parameter (1 out of 9). Other parameters like query, metadata_filters, date_from, date_to, tags_any, tags_all, tags_none, include_root receive no explanation, leaving the agent unable to use them correctly.
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 memories organized into a hierarchy from metadata, using the verb 'Return' and specifying the resource 'memories' and the structure 'hierarchy'. This distinguishes it from siblings like memory_list (flat list) and memory_related (related items).
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 is provided on when to use this tool versus alternatives such as memory_list, memory_hybrid_search, or memory_tag_hierarchy. The description lacks explicit context, when-not-to-use, or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'report invalid entries' but does not disclose whether the tool modifies data, requires special permissions, or how the report is returned. The name implies read-only, but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits crucial details. Conciseness is not sacrificed for clarity; rather, the description is under-specified.
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 that there is only one parameter and no required parameters, the description should at least explain the parameter and the output format. It lacks details about the validation process, allowlist context, and interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (include_memories) is not mentioned in the description. Schema coverage is 0%, and the description adds no information about its meaning, default, or effect on 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?
The description explicitly states the action ('validate'), the resource ('stored tags'), and the goal ('against the allowlist and report invalid entries'). It clearly distinguishes from sibling tools like memory_tags or memory_backfill_tags which have different purposes.
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 vs. alternatives. It mentions 'against the allowlist' but does not explain what the allowlist is or how to configure it. No mention of prerequisites or exclusions.
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, the description must disclose behavior fully. It only states 'create' (mutation) but omits details on atomicity, limits, side effects, or what the returned output contains, despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the expense of necessary detail. While it is appropriately short, it lacks structure and front-loads only the primary action.
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 batch nature, many sibling tools, and lack of annotations, the description is incomplete. It fails to specify entry structure, batch limits, or behavior expectations, which are critical for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'entries' is an array of objects with no structure described. With 0% schema coverage, the description adds no meaning beyond the schema, failing to clarify required fields or allowed properties.
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 creates multiple memories, distinguishing it from single-create tools like memory_create. The verb 'create' and resource 'memories' are explicit, and the batch aspect is highlighted.
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 use for batch creation but does not explicitly state when to use this tool over alternatives like memory_create, nor does it provide any exclusions or context-dependent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The term 'tombstone reason' suggests a soft delete, but the description simply says 'delete' without clarifying permanence, atomicity, or side effects. It does not mention whether the operation is reversible, if partial failures occur, or what the response contains.
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 very short, using a clear 'Args:' format. It is efficient with no wasted words, but the informal docstring style and the inaccuracy regarding the default value slightly detract from clarity.
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 high number of sibling tools and the presence of an output schema, the description is insufficient. It does not explain the return value, error handling, or whether the operation is atomic. For a batch delete, crucial details about partial success and idempotency are missing, making the description incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema: it labels 'ids' as 'Memory IDs' and 'reason' as an 'Optional tombstone reason'. However, it contradicts the schema by stating the default for 'reason' is 'deleted' when the schema has 'default: null'. With 0% schema description coverage, the description should provide more accurate and comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete multiple memories') and the key identifier ('by id'). This distinguishes it from the singular 'memory_delete' sibling and other batch operations. The verb and resource 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With over 30 sibling tools, including 'memory_delete' (singular) and various other batch operations, the description does not specify when this batch deletion is appropriate or preferable, nor does it mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the function but does not disclose behavioral traits such as read-only nature, side effects, or requirements. For a read operation, the description should at least imply safety.
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 of 7 words, front-loaded with the verb and resource. No unnecessary information is present.
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?
While the output schema exists, the description lacks explanation of parameter semantics and usage context. For a simple tool with one optional parameter, the description is minimally adequate but could still benefit from specifying what 'namespace hierarchy' means and when 'include_root' matters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not mention the only parameter 'include_root'. The parameter's purpose (e.g., whether to include root node in hierarchy) is left undocumented, leaving the agent to infer from the name 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 verb 'Return' and the resource 'stored tags', and specifies the output organization as 'a namespace hierarchy', which distinguishes it from sibling tools like 'memory_tags' (likely flat) and 'memory_hierarchy' (possibly different context).
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 is provided on when to use this tool versus alternatives like 'memory_tags' or 'memory_hierarchy'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It only states 'Return' implying a read operation, but lacks disclosure of side effects, auth needs, or any behavioral traits.
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, no wasted words; appropriate for a simple parameterless tool.
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?
With output schema present, the description need not explain return values, but it fails to clarify what 'allowlisted' means or its purpose within the tool suite; adequate but minimal.
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?
No parameters in schema; baseline score of 4 for zero parameters as per guidelines.
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 'Return the allowlisted tags' clearly states the verb (return) and resource (allowlisted tags), but does not differentiate from sibling tools like memory_tag_hierarchy or memory_validate_tags.
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; the description provides no context or exclusions.
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?
The description does not disclose whether 'mark as consumed' is destructive or reversible, nor does it mention idempotency or side effects. No annotations exist to supplement, so the agent lacks critical behavioral insight.
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 with a single action sentence and clear Args/Returns sections. Every word earns its place, with no 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 a simple single-parameter tool with an output schema, the description is adequate. However, it lacks context on the event lifecycle and relationship to siblings, making it slightly incomplete for full autonomous 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?
With 0% schema coverage, the description adds basic meaning by stating event_ids are IDs to mark as consumed. However, it does not specify constraints like uniqueness, range, or behavior for invalid IDs.
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 marks events as consumed, with a specific verb and resource. It differentiates from sibling 'memory_events_poll' by indicating a different operation on events.
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 is provided on when to use this tool vs alternatives like memory_events_poll. There are no prerequisites or conditions for clearing events, leaving the agent to infer appropriate usage.
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?
Mentions rate limiting (120s cooldown), which is helpful. Implies read-only operation via 'analyze' and 'returns' but does not explicitly state it does not modify data. Lacks details on potential costs or time for LLM analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with Args and Returns sections, but includes some redundancy and could be more concise. The rate limit info is placed at the end, somewhat separate from the main description.
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?
Covers parameters, return values, and rate limit. Has output schema available in context, so description's detail on returns is appropriate. Lacks prerequisites or error conditions but is generally sufficient for its scope.
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 0%, so description compensates well. Provides example values for 'period' and explains effect of 'include_llm_analysis'. Adds meaning beyond the bare 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?
Clearly states the tool analyzes memories and produces actionable insights, listing returns like activity summary, open items, etc. However, it does not differentiate from similar analysis tools like memory_stats or memory_clusters, so some ambiguity remains among siblings.
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. The description explains what it does but does not mention scenarios or conditions for use, nor when to avoid 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?
No annotations exist, so the description carries the full burden. It explains metadata merging and replace_metadata behavior but omits key aspects like how content and tags are updated (overwritten or merged). This partial disclosure earns a 3.
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, efficiently front-loaded with the core purpose. It avoids redundancy but could be more concise by eliminating minor framing. Overall well-structured.
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 5 parameters and no schema descriptions, the description leaves major gaps: update behavior for content and tags is unspecified. Output schema exists but return values are not mentioned. Incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It adds meaning for metadata and replace_metadata but provides no details about memory_id, content, or tags parameters. This insufficient compensation results in a low score.
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 'Update an existing memory.' which is a specific verb-resource pair. It further details metadata update behavior, distinguishing it from creation or deletion. Among many siblings, 'update' is distinct enough.
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 updating memories but provides no explicit guidance on when to use this tool versus alternatives like memory_absorb or memory_merge. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, authorization needs, idempotency, or error conditions. It only describes parameters, leaving behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose followed by an Args section. It is reasonably concise but could be slightly more efficient by removing redundant phrasing (e.g., 'Optional metadata dictionary').
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 lack of annotations and the complexity of 6 parameters, the description adequately covers parameter semantics. However, it omits information about return values (output schema exists but not referenced) and behavioral context (e.g., whether duplicates are checked, how suggestions work). It meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all six parameters, including their purpose, defaults, and valid options (e.g., response_mode enum, suggest_similar behavior). This adds significant meaning beyond the input schema, which only has titles and defaults.
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 'Create a new memory entry' with a specific verb and resource. It distinguishes from sibling tools like memory_create_batch, memory_create_issue, etc., which are more specialized.
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. The description only lists parameters without any context on prerequisites, limitations, or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It explains the bidirectional parameter and return type, but lacks details on prerequisites (e.g., link must exist), side effects (e.g., timestamps), error conditions, or required permissions. This leaves significant gaps for an AI agent.
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: a one-line purpose followed by parameter explanations using a simple label-description format. No unnecessary words. Slightly informal but fits MCP expectations.
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 tool with 3 parameters and an output schema, the description covers core behavior and parameters. However, it misses error handling, prerequisites (e.g., must the link exist?), and does not leverage the output schema to explain return values. Incomplete for full autonomous agent usage.
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 0%, so the description must add meaning. It adds: from_id is 'Source memory ID', to_id is 'Target memory ID', and bidirectional explains default and effect. This goes beyond the schema's type/title only.
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 'Remove a link between two memories,' which is a specific verb and resource. It distinguishes itself from siblings like memory_link (creates a link) and memory_delete (deletes a memory). The purpose is 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 use when wanting to remove a link between two memories, but provides no explicit guidance on when not to use it or mention of alternatives (e.g., memory_link for creation, memory_delete for removing memories with their links). Context signals include 39 sibling tools, but no differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It correctly declares the tool as 'Read-only', which is critical for an agent to know it is safe to invoke. However, it does not disclose what 'integrity' means (e.g., consistency checks, corruption detection), what 'bounded offending ids' implies (e.g., a limit on results), or any other behavioral traits such as cost or side effects, leaving room for ambiguity.
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, concise sentence that conveys the core purpose and a key behavioral trait ('Read-only') without any wasted words. It is front-loaded with the most critical information and easily digestible by an agent.
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 that the tool has no parameters and a very specific purpose, the description covers the basics. However, the presence of an output schema is noted in the context, and the description does not hint at what the output contains beyond 'bounded offending ids', leaving the agent to rely solely on the output schema for understanding return values. For a diagnostic tool among many similar siblings, more context on what kind of integrity issue is detected would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is 100% covered by the schema definition itself. Since there are no parameters to document, the description cannot add value beyond the schema; therefore, the baseline 4 is appropriate, but the clear description of the tool's action ('verify integrity') and output characteristic ('bounded offending ids') effectively communicates what the no-parameter invocation does, earning a 5.
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 verb ('verify') and resource ('embedding integrity'), and the phrase 'bounded offending ids' adds specificity about what the reader can expect from the output, distinguishing it as a diagnostic tool. It does not, however, elaborate on what aspect of integrity is checked, and with many sibling tools like memory_find_duplicates and memory_detect_supersessions also performing diagnostics, the distinction is only moderate.
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 any of the many sibling tools. The phrase 'Read-only embedding integrity doctor' implies a safe diagnostic context, but there are no explicit when-to-use, when-not-to-use, or alternative suggestions, leaving the agent to guess its role among over 40 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the return value and auto-assigned tag, but does not discuss side effects, permissions, or whether it's safe (obviously creates, but no explicit safety info). Partial transparency.
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 structured with Args and Returns sections. It is informative without being verbose, though it could be slightly more concise. Overall well-organized.
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 existence of an output schema (not shown but referenced), the description covers all 6 parameters with 1 required and explains the return. It lacks error cases but is sufficient for a creation 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 0%, so the description must add meaning. It provides clear explanations for each parameter (e.g., status defaults to 'open', severity options) and clarifies the return value, adding significant value 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?
The description clearly specifies the action ('Create a new issue/bug memory') and resource (issue/bug memory). The name and description distinguish it from siblings like memory_create (generic) and memory_create_todo (todo-specific).
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 like memory_create or memory_create_todo. The description does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries disclosure burden. It mentions auto-tagging and return behavior, but omits side effects (e.g., idempotency, permissions, limits). Adequate but has gaps.
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?
Structured as a clear docstring with section headers. The content is efficient but slightly verbose (e.g., 'Args:' lines are functional). Overall good 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?
Explains all parameters, return value, and auto-tagging. With an output schema present, it doesn't need to detail returns. Lacks only broader context (e.g., relationship to other tools), but nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description provides all parameter semantics: content, status, closed_reason, priority, category with defaults and examples. Adds high value beyond the bare 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?
Clearly states 'Create a new TODO/task memory,' specifying a distinct resource type (TODO) that differentiates it from sibling tools like memory_create (generic) and memory_create_issue.
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 like memory_create or memory_create_issue. The description lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does substantial work: it discloses that the tool reports statistics, identifies the bound database, and explains why that reporting matters. It does not explicitly state read-only behavior, but the verb 'Get' strongly implies it for a zero-parameter stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded in the first sentence, and the additional explanation of database-drift detection earns its place because it tells an agent why the tool matters. The wording is a bit verbose for such a simple tool, but the length is justified by the non-obvious context.
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 zero parameters, no annotations, and an existing output schema, the description covers the essential functional context including the unique database-identity reporting. It stops short of 5 because it does not acknowledge or differentiate the closely related sibling tools that also provide memory analytics or insights.
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?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter semantics for the description to add. The baseline of 4 applies.
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 names a specific verb ('Get') and resource ('stored memories'), and also identifies a distinctive secondary output (the bound database identity). It falls short of a 5 because it does not distinguish this tool from sibling memory_insights or memory_digest, which could plausibly offer overlapping statistics.
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 a key use case: detecting database drift by reporting which database the session is bound to. However, it never explicitly says when to use this tool versus memory_insights or other memory analytics siblings, and no exclusions or alternative routing 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?
No annotations provided, so the description carries full burden. It discloses the destructive nature (delete), the scope (document and all its fragments), and the version behavior (optional, otherwise all versions). However, it omits details like error handling, permission requirements, or irreversibility.
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, using a single sentence for the action and structured bullet points for args and returns. Every sentence adds value, no fluff.
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 low complexity and presence of an output schema, the description provides sufficient context: action, scope, version handling, and return value structure. However, it could mention error cases (e.g., missing document) to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'document_key: The document identifier' and 'version: Optional — delete only this version. If omitted, deletes all versions.' Adds meaning beyond the schema's basic type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a stored document and all its fragments') and specifies the resource ('document'). It distinguishes itself from siblings like memory_delete by explicitly targeting documents and mentioning fragments, which is unique.
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 memory_delete or memory_delete_batch. The description does not specify context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It explains parameters and return structure, but it omits side effects (e.g., does polling mark events as consumed?) and idempotency details. The description mentions 'unconsumed_only' implying consumption states, but does not clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using bullet points for arguments and return. It is front-loaded with the purpose and avoids unnecessary details. Every sentence adds value without redundancy.
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 3 optional parameters, no annotations, and an output schema, the description covers purpose and parameters well. However, it lacks context on how polling fits into the broader workflow (e.g., repeated polling, clearing events), which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains all three parameters, including format for since_timestamp (ISO), example for tags_filter (e.g., ["shared-cache"]), and default behavior for unconsumed_only (default: True). This adds significant value beyond the input schema, which has 0% description 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 'Poll for memory events (e.g., shared-cache notifications)'. It specifies the verb 'Poll' and the resource 'memory events' with a concrete example, distinguishing it from sibling tools like memory_list or memory_events_clear.
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 is provided on when to use this tool vs alternatives. For example, it does not explain that polling is for retrieving new events, nor does it mention related tools like memory_events_clear for clearing events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the edge_type options and bidirectional behavior, but lacks details on idempotency, validation, or failure conditions.
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?
Brief first-line summary followed by structured Args section. No redundant sentences; all sentences add 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 4 parameters, no annotations, and existence of output schema, the description is fairly complete. It explains the tool's purpose, parameters, and return value, but omits preconditions like memory existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides full meaning for all 4 parameters, including explanations for edge_type options and bidirectional's reverse link creation.
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 'create' and the resource 'explicit typed link between two memories'. It distinguishes from siblings like memory_unlink, which removes links.
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 (e.g., memory_merge). It does not indicate when not to use or provide context for using different edge types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers return structure but lacks details on permissions, errors, or performance.
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?
Very concise with clear args/returns structure; front-loaded with main purpose.
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?
Well-suited for a simple export tool with output schema; covers key aspects without being verbose.
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 0%, but description explains both parameters with defaults and purpose, compensating well.
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 memories as an interactive HTML knowledge graph, with specific output format and parameters.
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?
Provides basic arguments and returns, but lacks explicit guidance on when to use this tool versus alternatives like memory_export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rate limit cooldown, which is a critical behavioral trait. However, it does not mention resource usage, potential impacts on existing data, or whether the operation is long-running.
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 fluff. The first sentence states the purpose clearly, and the second adds an important behavioral constraint. Every word 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 has no parameters and has an output schema (not shown but indicated), the description is mostly complete. However, it lacks information about the output or return value, and could benefit from explaining typical use cases (e.g., after data updates). Despite this, it covers the essential behavioral aspect of rate limiting.
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?
The input schema has no parameters, and schema description coverage is 100%. With zero parameters, the baseline is 4. The description does not need to add parameter information, and it does not introduce any confusion.
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: 'Recompute embeddings for all memories.' It uses a specific verb and resource, and it distinguishes itself from sibling tools like memory_create or memory_rebuild_crossrefs by specifying a unique operation.
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 a rate limit (300s cooldown) which signals that this tool is not for frequent use, but it does not provide explicit guidance on when to use it versus alternatives. No exclusion criteria or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains the return format (clusters with IDs, sizes, tags) and algorithm behavior, but does not explicitly state that it is read-only or non-destructive. A clearer safety indication would improve this.
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 with a clear purpose statement and a bulleted list of parameters. Every sentence adds value; no redundancy.
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 that there is an output schema (described in text) and no nested objects, the description adequately covers inputs, algorithm choices, and output structure. It is self-contained for a clustering tool among many memory tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds detailed explanations for each parameter (min_cluster_size, min_score, algorithm) and the algorithm options, enabling correct agent invocation.
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 clusters of related memories, with a specific verb and resource. It distinguishes from sibling tools like memory_find_duplicates or memory_related by focusing on clustering.
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 is implied (when you want to find clusters), but there is no explicit guidance on when to use this tool vs alternatives, nor when not to use it. The algorithm options are explained but not in comparison to other 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?
Despite no annotations, the description fully discloses key behavioral traits: sections are not visible in graph visualization, excluded from duplicate detection, and do not compute embeddings or cross-references. It also notes the auto-assigned tag. This exceeds the burden for a tool with no 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 well-organized with a brief introductory sentence, bullet points for key properties, and an Args section. It is not overly verbose, but the Args section could be integrated more seamlessly. Still, it efficiently conveys necessary information.
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 presence of an output schema (even if not fully shown), the description mentions the return value (created section memory with auto-assigned tag). All three parameters are documented with context. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing brief but clear explanations for each parameter: content is 'Title/description of the section', section is 'Parent section name', subsection is 'Subsection path'. This adds meaning beyond the bare schema, though the explanations are concise.
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 creates a section/subsection header memory, and distinguishes itself from regular memories by listing three specific behavioral differences (not visible in graph, not in duplicate detection, no embeddings/cross-references). This specificity and differentiation from siblings like memory_create warrants a top score.
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?
While the description explains what the tool does, it does not provide explicit guidance on when to use this tool versus alternatives such as memory_create or memory_create_batch. There is no 'when-to-use' or 'when-not-to-use' advice, leaving the agent to infer context from the behavioral differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the default return behavior (full content), the effect of include_images and fields parameters on the response, and the lineage resolution modes for follow (latest, full_history, all), including the crucial note that omitting follow is not unfiltered but resolves to latest. This is thorough for a read operation, though it does not explicitly state that this is a non-destructive retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in a single sentence, followed by a structured parameter list. It is concise for its complexity—no wasted words. However, the parameter documentation could be slightly more condensed, and the overall length is justified by the richness of the follow parameter.
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 that an output schema exists (context signal shows 'Has output schema: true'), the description does not need to detail return values. It adequately covers all four parameters, including the nuanced follow behavior. It might mention that it returns a single memory object, but 'full content' implies that. For a single-item retrieval tool with lineage options, the description is complete enough for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate entirely. It explains all four parameters: memory_id (ID to retrieve), include_images (strip image data), fields (optional list to filter returned fields), and follow (lineage mode with three explicit options and a clarifying note). Each parameter adds meaning beyond the schema's type and default, making selection and invocation easy.
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 'Retrieve a single memory by id', specifying the verb 'Retrieve' and the precise resource with a unique identifier. This distinguishes it from siblings like memory_list (which lists multiple memories) and memory_get_document (for documents), making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. The usage context is implied (when you need a specific memory by ID), but there is no guidance on exclusions or comparisons to siblings like memory_list or memory_semantic_search. The 'follow' parameter hints at different use cases, but overall usage guidelines are lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: source will be deleted, target updated, and content merged according to strategy. It also mentions preserving content and metadata and lists the expected return value. 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 well-structured: a concise summary line followed by a detailed Args block and Returns. Every sentence adds value, with no repetition or filler. The parameter explanations are front-loaded.
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?
The description is complete for a merge tool. It covers both source and target behavior, merge strategies, and return value. Despite having an output schema, the description provides sufficient understanding of the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions), so the description compensates fully. It explains source_id, target_id, and merge_strategy with clear semantics and even enumerates the three strategies (append, prepend, replace).
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 merges source memory into target and deletes the source. It specifies the resource (memory), the action (merge), and the outcome (delete source), distinguishing it from similar tools like memory_absorb which may not delete the source.
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 guidance on when to use this tool versus alternatives like memory_absorb or memory_update. It explains the merge strategies but lacks explicit when-to-use or when-not-to-use 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?
With no annotations, the description carries full burden. It details the step-by-step process including LLM classification and consolidation, and mentions dry_run for preview. However, it does not specify the exact actions taken for each relationship type (e.g., what 'update' entails) or potential side effects like overwriting existing memories.
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 and well-structured: a brief summary, followed by a process explanation, then a bulleted argument list. Every sentence adds value, and key information is front-loaded.
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 complexity (7 parameters, 1 required, no annotations, output schema present), the description is complete. It covers the core functionality, argument semantics, and behavioral details. Return values are not needed due to output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is explained in the Args section, adding meaning beyond the input schema which has 0% description coverage. For example, source lists possible values, dry_run is described as a preview, and facts are noted to be mergeable. This provides clear guidance for an AI agent.
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 'Intelligently absorb facts into memory with dedup and consolidation' and explains the process of searching, classifying, and consolidating. It distinguishes from siblings like memory_create by emphasizing dedup and LLM-driven merging.
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 absorbing facts that may overlap with existing memories, but does not explicitly state when to use this tool versus alternatives like memory_create_batch or memory_update. No exclusions or alternative names 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?
Without annotations, the description must carry the full burden. It discloses that 'force' allows deleting document fragments/roots, warns this is not the recommended approach for documents, and that 'reason' creates a tombstone marker. This is strong transparency for the destructive nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three short bullet points in the Args section plus a one-line summary. Every sentence adds unique value: purpose, parameter semantics, and usage guidance. No wasted 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?
Given the tool has an output schema (not shown but present), the description need not cover return values. It explains all three parameters, flags destructive behavior, and distinguishes a sibling. However, it does not discuss permissions, cascading effects, or error states, which would be helpful given the tool's destructive nature.
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 0%, so the description fully compensates. It explains that 'force' enables deletion of document fragments/roots with an alternative tool suggestion, and 'reason' is an optional tombstone reason with a default. This adds significant meaning beyond the schema's bare property definitions.
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 a specific verb ('Delete') and resource ('memory by id'), clearly identifying the primary action. It also distinguishes itself from the sibling tool 'memory_delete_document' by advising against using 'force' for clean document removal, which clarifies scope.
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 tells when to use 'memory_delete_document' instead of this tool (for clean document removal), providing a clear exclusion. However, it does not discuss other alternatives like memory_unlink or batch operations, nor does it specify prerequisites for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It thoroughly describes the tool's behavior: deterministic, combines hybrid-search hits, supersession lineage, related memory ids, and TODO/issue matches. It also notes always returning raw source ids. However, it does not explicitly state read-only nature or auth requirements, but the description is adequate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary paragraph followed by a parameter list. It is front-loaded with the core purpose. Although slightly verbose, every sentence adds value, and the format aids 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 complexity (14 parameters, no annotations, but has output schema), the description covers all key aspects: what the digest includes, parameter behaviors, and the guarantee of returning raw source ids. The presence of an output schema means return value details are not required, but the description still provides useful context about the output composition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a detailed Args section explaining each parameter's purpose and default values (e.g., topic: 'Subject to digest', k: 'Maximum active search hits and TODO/issue matches'). Since schema description coverage is 0%, the description adds essential meaning beyond the schema's basic type and name, fully compensating for the gap.
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 deterministic digest of memories related to a topic. It specifies the verb ('return') and resource ('memories digest'), distinguishes from narrative generation, and differentiates from sibling tools like memory_hybrid_search or memory_get by focusing on aggregation.
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 context for when to use the tool ('agents that need current context') and includes guidance that raw source ids are returned for inspecting primitives if the digest is too broad or narrow. However, it lacks explicit alternatives or when-not-to-use scenarios, which would improve clarity 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains that the tool scans all memories, uploads to R2, and has a rate limit. The dry_run parameter and return dictionary are described. More detail on side effects or safety would improve it.
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: a single sentence for purpose, followed by structured Args and Returns sections. No extraneous information, and the rate limit note is included efficiently.
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 key aspects: purpose, parameter, return value, and rate limiting. An output schema exists, so return details are handled. Missing details like failure handling or progress are minor given the tool's scope.
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?
Only one parameter (dry_run) with 0% schema description coverage. The description adds meaning by explaining it reports what would be migrated without making changes, which is valuable 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?
The description clearly states the tool migrates base64 images to R2 storage, scanning memories and replacing data URIs. It distinguishes from sibling tools like memory_upload_image and other memory utilities.
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 the dry_run parameter for testing and a rate limit of 300s cooldown. It does not explicitly state when to use vs alternatives, but the purpose is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the upload action, returns an r2:// URL, and mentions organization by memory_id. It could be more explicit about side effects (e.g., overwrite behavior, permissions needed) but provides adequate transparency for a typical upload operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary followed by an Args/Returns block. It is not overly long, but could be slightly more concise by removing the Returns block if output schema is sufficient. Still, it is clear 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?
Given 4 parameters, no annotations, and an output schema present, the description is fairly complete. It explains all parameters and the return value. It could mention any constraints (e.g., file size limits, supported formats) but overall provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes a full docstring for each parameter (file_path, memory_id, image_index, caption), explaining their purpose and defaults. This adds significant meaning beyond the schema's bare type hints.
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 uploads an image file to R2 storage and returns an r2:// reference URL, specifying the action and resource. The verb 'upload' and resource 'image file to R2' are specific, and the purpose is distinguishable from sibling tools like memory_migrate_images or memory_store_document.
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 (for uploading images to R2) but does not explicitly state when not to use it or mention alternative tools. However, the context of sibling tools implies it is for image uploads specifically, and the docstring provides clear usage context.
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 key behavioral traits beyond annotations: deterministic normalization, no LLM calls, idempotence, rate limiting (120s cooldown), and the preview effect of dry_run. This fully compensates for missing 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 and well-structured: a main purpose statement, then bullet points for parameters, returns, and rate limit. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and an output schema, the description covers all necessary context: what it does, how it works, behavior under dry_run, return structure, and rate limits. No gaps are apparent.
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?
The only parameter, dry_run, is well-explained with its default value and effect (preview changes). With 0% schema description coverage, the description adds essential meaning beyond the schema, though the parameter is simple.
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 re-tags existing memories with project-prefixed tags using deterministic normalization, with an explicit example. It distinguishes itself from sibling tools by specifying this unique retroactive tagging 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 does not explicitly state when to use or avoid this tool compared to alternatives like memory_validate_tags or memory_tags. While it notes features like no LLM calls and idempotence, it lacks direct usage context or exclusions.
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: uses neutral LLM classification, creates edges, supports dry-run, and has a 120s rate limit. It does not mention idempotency, side effects beyond edge creation, or required permissions. Since no annotations are present, the description carries the full burden and does a good job overall.
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 well-structured: a concise purpose statement, functional explanation, bulleted args, return summary, and rate limit note. It is front-loaded with the most critical information and contains no redundant 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 description covers purpose, mechanism (LLM), parameters, return format, and rate limiting, and differentiates from a sibling. It lacks mentions of prerequisites (e.g., pre-existing embeddings) or performance implications, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by listing all five parameters with clear purposes, defaults, and explanations (e.g., dry_run for preview). This adds significant meaning beyond the raw 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 detects memories that supersede others, scans for pairs, and creates edges. It distinguishes itself from memory_absorb which catches supersessions at write time.
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 mentions that it complements memory_absorb, implying it is for retroactive detection. However, it does not provide explicit when-not-to-use scenarios or alternative tools under specific conditions.
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?
Without annotations, the description adds the rate limit ('60s cooldown'), which is a crucial behavioral trait. It also implies a non-destructive read operation, though it doesn't detail potential size impacts.
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 concise sentences, front-loaded with purpose and ending with rate limit. No redundant words or filler.
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 zero parameters, an existing output schema, and the tool's simple nature, the description fully covers purpose and constraints. The rate limit is a valuable addition for planning.
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?
With zero parameters, schema coverage is 100%. The description adds no parameter info but correctly states what the tool does (exports all memories). Baseline 4 applies.
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 'Export all memories to JSON format for backup or transfer', with a specific verb (Export), resource (all memories), format (JSON), and purpose (backup or transfer). This distinguishes it from siblings like memory_export_graph.
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 backup or transfer, but does not explicitly mention when not to use or compare with alternatives like memory_export_graph or memory_import. The context is clear but lacks exclusion 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?
With no annotations, the description takes full burden. It reveals rate limiting, and describes the side effects of each strategy (e.g., 'replace' clears all memories first). This is valuable beyond what structured fields provide, though it could mention whether the operation is atomic or rolls back on failure.
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?
Extremely concise, front-loaded with the core purpose, followed by essential details on rate limiting and arguments. Every sentence is necessary, no fluff.
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 (import strategies, rate limiting), the description covers key aspects: what it does, how arguments work, and behavioral constraints. It does not mention error handling or maximum data size, but the presence of an output schema partially compensates for missing return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the 'data' parameter as a list of memory dictionaries with expected keys (content, metadata, tags, created_at), and the 'strategy' parameter with its three options and meanings. This adds significant value over the bare 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 the action ('Import memories') and resource ('from JSON format'), distinguishing it from many sibling tools like memory_create, memory_merge, etc. The verb 'import' and specific format 'JSON' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides rate limiting guidance ('60s cooldown') and explains three strategies (replace, merge, append) with their behaviors. However, it does not explicitly compare to sibling tools or state when to use this tool over alternatives like memory_create_batch or memory_merge, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions rate limiting (300s cooldown) but lacks details on side effects, authorization needs, or performance impact. Adequate but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; front-loaded with the main action and followed by usage guidance.
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 parameters, an output schema exists, and the description explains purpose, usage context, and references a related tool for consistency model. Complete for a maintenance 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?
No parameters; schema coverage 100% trivially. Description adds value by mentioning rate limit, though baseline for 0 params is 4.
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+resource: 'Recompute cross-reference links for all memories.' Distinct from siblings like memory_related which deals with the consistency model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this periodically (or after bulk imports) to close the eventual-consistency gap' and references sibling tool memory_related for the consistency model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains parsing, fragment searchability, version superseding, and crossref skipping. It does not mention destructive actions or auth, but for a store operation, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with a leading summary and Args/Returns sections. It is informative without being verbose, earning its sentences.
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 complexity (markdown parsing, multiple fragment types, crossrefs) and the presence of an output schema (not shown here but implied), the description covers return format and key behaviors. It is complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: content as full markdown, document_key as stable identifier, version default 1, tags applied, metadata merged, skip_fragment_crossrefs default True. Every parameter is given meaningful context.
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 stores a structured document as 'root memory + searchable fragments', with a specific verb 'store' and resource 'document'. It distinguishes from siblings like memory_create by explaining the markdown parsing and fragment creation, which is unique.
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 implicitly indicates usage for storing markdown documents with automatic parsing, but does not explicitly contrast with alternatives like memory_create for simple memories. Still, the purpose is clear enough for an agent to know when 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?
With no annotations provided, the description carries the full burden. It discloses that the boost is permanent and cumulative, and states the return type (updated memory or error). This provides sufficient transparency, though it could mention potential side effects like affecting all importance-sorted queries.
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 and well-structured: a single-line summary, an explanatory sentence, then args and returns. Every sentence adds value, and the front-loaded purpose is immediately 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's simplicity (2 parameters, 1 required, output schema present), the description covers all necessary aspects: purpose, usage, parameter details, and return value. Nothing is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so excellently by explaining both parameters: memory_id (ID of memory) and boost_amount (amount to add, with default and common values). This adds meaning beyond the raw 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 the tool's purpose: to manually boost a memory's importance score, making it rank higher in searches. It specifies the verb 'boost' and the resource 'memory's importance score', and it is distinct from sibling tools like memory_update or memory_list.
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 (to manually increase importance for better ranking) but does not provide explicit guidance on when not to use it or alternatives. However, the context is clear enough for an agent to understand its appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It explains the return structure (root and fragments) and behavior of optional parameters (e.g., version defaults to latest). It does not disclose side effects or permissions, but for a read operation this is adequate.
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 well-structured docstring with Args and Returns sections. Every sentence provides necessary information without redundancy. It is concise and front-loaded with the core purpose.
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 output schema exists, the description complements it by detailing parameter semantics and the layout of returned data. No critical information is missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description thoroughly explains each parameter: document_key is the identifier, content_mode has 'preview' or 'full', preview_chars max characters, node_kinds filters fragment types, version is optional. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a stored document and its fragments by document key,' which is a specific verb and resource. The purpose is unambiguous and distinct from sibling tools like memory_store_document (store) and memory_get (which retrieves individual entries).
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 context on when to use the tool (retrieve a document by key) but does not explicitly mention when not to use it or list alternatives. However, the purpose and parameter details are sufficient for an agent to decide.
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 eventual consistency behavior and the effect of refresh parameter, which goes beyond minimal requirements given no annotations. Doesn't cover error handling or detailed side effects, but sufficient for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a paragraph, each sentence adds value. Front-loads purpose and efficiently explains consistency model and refresh option.
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?
Covers consistency, refresh path, and relationship to rebuild tool. Output schema exists, so return formatting is handled. Could mention validation of memory_id, but overall complete for a read 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?
With 0% schema coverage, description adds valuable meaning for 'refresh' as a strong-consistency path. 'memory_id' is minimally explained as 'given entry', but overall compensates well.
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 it returns cross-referenced memories for a given entry. Differentiates from siblings like memory_get (single memory) and memory_rebuild_crossrefs (full rebuild).
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 explains when to use refresh=True for strong consistency and when to use memory_rebuild_crossrefs for full rebuild. Provides context on eventual consistency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an outstanding job: explains the RRF algorithm, default content mode, preview behavior, the follow parameter's lineage logic, and the fields parameter's effect on output envelope. Minor deduction for not explicitly stating whether the operation is read-only (though clearly implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for behavior details, Args, and Returns. It front-loads the core purpose and algorithm. Some minor verbosity in the 'follow' description with inline references to other tools, but this is justified for clarity given the tool's complexity.
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 high complexity (15 params, nested objects, hybrid algorithm), the description is remarkably complete. It addresses search behavior, return formats, filtering options, and alternate tools. The output schema exists, so return value explanation is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate for all 15 parameters. It does: every parameter gets a clear explanation, including defaults, relationships (semantic_weight vs 1 - semantic_weight), aliases (limit vs top_k), and behavioral nuances (follow default is not unfiltered). Goes far 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 states the verb 'Perform a hybrid search' and specifies the resources involved (keyword FTS and semantic vector search). It distinguishes itself from sibling tools by explaining the hybrid nature and RRF merging, making it clear what unique value this tool provides.
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 excellent usage guidance, explaining when to use this tool (when better results are needed than either method alone) and when to use alternatives (memory_get for full content retrieval). It also clarifies parameter relationships, like the semantic_weight vs keyword weight balance.
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?
Without annotations, the description fully carries the burden. It transparently lists the exact return fields (id, content preview first 80 chars, tags, created_at) and implies a read-only operation by describing a list action. A slight deduction for not explicitly stating it's read-only, but the output details are comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a deprecation warning first, then the parameter list in a clear Args section. It could be slightly more concise by shortening some parameter explanations, but overall it's organized and easy to scan.
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 presence of an output schema (not shown but indicated), the description already covers the return fields. All parameters are explained, usage context is given (deprecated, prefer alternative), and no gaps remain for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates fully by providing clear, plain-English explanations for all 9 parameters, including defaults and format expectations for date filters and tag logic.
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 explicitly states it lists memories in compact format with specific fields (id, preview, tags only) and distinguishes itself from sibling tool memory_list which now defaults to compact previews with richer fields.
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 clearly advises against using this tool by labeling it deprecated and directing users to memory_list instead, which provides richer fields and configurable options. This explicit when-not-to-use guidance exceeds typical usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses behavioral traits: default content_mode='preview', preview_chars=300, the alias relationship between limit and top_k, the effect of fields on result envelope, and the nuanced follow parameter. It also clarifies that omitting follow is not unfiltered, which prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a high-level purpose line, then a bulleted Args section. It is thorough but slightly verbose (e.g., the follow parameter explanation could be more concise). The front-loading of purpose is effective.
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 complexity (9 parameters, nested objects, output schema exists), the description covers all necessary aspects: return format (envelope vs flat list), content modes, follow lineage, and metadata filters. The output schema already documents return structure, so the description's focus on parameter behavior and result variant is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the input schema provides only names and types. The description compensates fully by detailing all 9 parameters in the Args block, including the meaning of each, defaults, and the alias. This adds essential value 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?
The description starts with 'Perform a semantic search using vector embeddings,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like memory_list (non-semantic list) and memory_hybrid_search (hybrid approach), as it focuses purely on vector embeddings.
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 context for parameters like content_mode, follow, and fields. It mentions that 'omitting follow is NOT unfiltered' and references memory_list for follow mode documentation. However, it does not explicitly state when to use this tool over alternatives (e.g., memory_hybrid_search), leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: scanning cross-references, similarity threshold, optional LLM comparison, rate limiting (120s cooldown). It also describes the return structure in detail.
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 well-organized: a concise summary, process explanation, parameter list, return dictionary, and rate limit note. Every sentence adds value without redundancy.
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 complexity and lack of annotations, the description covers all necessary aspects: purpose, parameters, return values, rate limiting, and alignment with UI. It is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description explains all four parameters with defaults and added context, e.g., max_similarity is for backward compatibility, use_llm controls semantic comparison. This goes well 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?
The description explicitly states the tool's purpose: 'Find potential duplicate memory pairs with optional LLM-powered comparison.' It specifies the mechanism (scans cross-references, similarity threshold), and distinguishes it by mentioning alignment with graph UI duplicate detection.
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 usage context, such as default threshold and optional LLM use. It mentions alignment with UI but does not explicitly state when not to use this tool or suggest alternatives among siblings like memory_merge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description compensates thoroughly. It discloses default behavior (preview mode, sort by date, safe follow mode), explains context usage reduction, and provides detailed behavioral notes for parameters like limit=-1 and follow. No contradictions exist.
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 well-structured with a brief introductory paragraph, usage recommendations, a detailed args section, and clear formatting. Every sentence adds value without redundancy. It is appropriately sized for a complex tool with 14 parameters.
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 high parameter count (14), no annotations, and presence of an output schema, the description is fully complete. It covers all filtering, sorting, pagination, lineage modes, and field selection. The output schema exists, so return values are not required. This is a model description for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so comprehensively: each parameter's purpose, defaults (e.g., limit=20, preview_chars=120), special values (limit=-1), filtering logic (tags_any vs. tags_all), date formats (ISO or relative), and dependencies (content_mode affects preview_chars). This adds rich meaning beyond the bare 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 the tool lists memories with optional filtering by substring query or metadata. It explicitly distinguishes the default preview behavior from the full content mode and references sibling tools like memory_get for fetching full content by ID. This makes the purpose specific and distinct.
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 on when to use different modes (preview vs. full), references a sibling tool (memory_get) for targeted retrieval, and explains the follow parameter options in detail, including safe defaults and when to use each lineage mode. This gives clear context for selection.
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:

[![memora MCP server](https://glama.ai/mcp/servers/agentic-box/memora/badges/card.svg)](https://glama.ai/mcp/servers/agentic-box/memora)

Score Badge

Copy to your README.md:

[![memora MCP server](https://glama.ai/mcp/servers/agentic-box/memora/badges/score.svg)](https://glama.ai/mcp/servers/agentic-box/memora)

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/agentic-box/memora'

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