memora

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the search/classify/consolidate workflow, dry_run behavior, and project resolution, but it does not specify what 'appropriate action' occurs for duplicates, updates, or contradictions. Whether existing memories get modified or deleted is left ambiguous, though 'dedup and consolidation' implies merging.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a brief intro followed by an Args list. The project note is long but handles a nuanced behavior that would otherwise be unclear. No sentences are wasted, though the overall length is justified by the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and an output schema that covers return values, the description is mostly complete. It explains the core algorithm, parameter semantics, and edge cases like project guessing. The main gap is the unspecified concrete actions for duplicate/update/contradict relationships, which is meaningful for a writing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 by explaining all 8 parameters: source values, confidence range/default, dry_run effect, project prefixing and tag-dropping rules, metadata/tags usage, and context disambiguation. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Intelligently absorb facts into memory with dedup and consolidation,' which states a specific verb, resource, and distinctive behavior. The detailed process of searching, classifying, and consolidating clearly differentiates it from simpler creation tools like memory_create or memory_create_batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly state when to use it versus alternatives or when to avoid it. The mention that facts can be granular and get merged implies use cases, and the sibling list suggests memory_create_batch exists, but no direct comparison or routing guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavior itself. It does so effectively: it explains suggest_similar triggers consolidation suggestions, describes project resolution rules (never guessed from text, issue #47), and notes response_mode controls payload size. This goes beyond the schema, though it omits details like whether the creation is idempotent or what happens on duplicate content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line purpose followed by a readable bulleted list of arguments. It is slightly verbose in places (e.g., the project explanation) but generally efficient. The front-loaded purpose ensures immediate orientation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 7 parameters and a nested object, the description covers all essential usage details: parameter meaning, defaults, and behavioral nuances (like project fallback). An output schema exists, so the lack of return-value description is acceptable. Nothing critical is missing for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It successfully explains every parameter: content, metadata, tags, suggest_similar, similarity_threshold, response_mode, and project. It clarifies defaults and behavior for each, compensating completely for the schema's lack of prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a new memory entry,' a clear verb+resource statement. It does not, however, differentiate itself from sibling tools like memory_create_issue or memory_create_todo, so an agent may not know when to choose this generic creator over the specialized ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It neither lists conditions that favor memory_create nor excludes scenarios better served by memory_create_issue or memory_create_section. The only implicit hint is that specialized creators exist, but no criteria are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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 that the tool creates a memory, auto-assigns a project-scoped tag, handles the 'issues' fallback, and returns the created memory. It does not discuss validation, failure modes, or permissions, but the core side effects and return behavior are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized into a one-line purpose, an Args list, and a Returns line. There is no filler, and the length is justified by the need to document seven parameters clearly. Each sentence or clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives the agent enough to create an issue: inputs, defaults, allowed values, tag behavior, and return value. Minor gaps remain, such as explicit routing against sibling create tools and clarification of whether closed_reason is required when status is 'closed', but overall the tool can be invoked correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Every parameter is explained with plain-language meaning, allowed values, defaults, and the project-to-tag transformation. This adds substantial semantic value beyond the bare schema property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and object: 'Create a new issue/bug memory.' This clearly distinguishes it from sibling create tools (e.g., memory_create_todo, memory_create_section) by scoping it to issue/bug memories. It is non-tautological and immediately informative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The issue/bug framing implies when this tool should be used, but the description never explicitly names alternatives or states when not to use it. There is no comparison with memory_create_todo, memory_create_section, or memory_create_batch, so selection guidance is only implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 clearly states that section memories are organizational placeholders, are excluded from graph visualization and duplicate detection, and do not compute embeddings or cross-references. It also explains the auto-assigned tag behavior, though it does not mention permissions, idempotency, or error cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a clear opening, bulleted behavioral traits, and structured Args/Returns sections. It is appropriately sized and front-loaded. The only minor redundancy is repeating the tag assignment behavior in both the project parameter explanation and the Returns section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, behavioral constraints, parameter semantics, and the return value's tag behavior. Given there is an output schema and no annotations, this is a complete-enough picture for most call scenarios. It could be more explicit about prerequisites or failure modes, but those are not critical for a simple creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. Every parameter is explained: content is the title/description, section is the parent, subsection is the path, and project controls the tag namespace with concrete examples. This adds substantial meaning beyond the raw input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a new section/subsection header memory', a specific verb and resource. It further differentiates from sibling creation tools by listing distinctive traits: not graph-visible, not in duplicate detection, no embeddings/cross-references. This makes the tool's purpose unambiguous relative to memory_create, memory_create_issue, and memory_create_todo.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what section memories are and their special properties, which implies when to use this tool. However, it never explicitly says when to prefer this over alternatives or names any sibling that should be used instead. Usage guidance is therefore more inferred than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it discloses the key non-obvious behavior: auto-assigned tags ('<project>/todos' or 'todos') and the conditional closed_reason for closed tasks. No contradiction with annotations exists since none are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A one-line summary plus tight Args/Returns blocks; every line documents a parameter or behavior that the schema leaves unspecified. The project line wraps awkwardly across two lines, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward create operation, the description covers every parameter, default, conditional dependency (closed_reason tied to status), return value, and the tag side-effect. Minor edge cases (e.g., closed_reason supplied while status is 'open') go unaddressed, but nothing essential to invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero description coverage, so the description must fully compensate — and it does, documenting all six parameters with allowed values ('open'/'closed', 'complete'/'not_planned', 'high'/'medium'/'low'), defaults, and the project-to-tag relationship. This is a textbook example of compensating for a bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Create a new TODO/task memory" names a specific verb (create) and a distinct resource (TODO/task memory), which separates it from siblings like memory_create_issue and memory_create_section. The summary line is unambiguous about what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is written in API-reference style (Args/Returns) and never addresses tool selection. An agent among 40+ siblings gets no explicit signal about when todos are preferred over issues or generic memories, leaving selection to inference from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and delivers richly: it discloses determinism ('deterministic digest'), internal aggregation mechanics across multiple memory sources, that 'raw source ids are always returned,' that include_related_hops is 'capped at 3,' and that synthesize is 'Reserved for future LLM synthesis. False by default' — a stub parameter clearly flagged. It even explains the debug payload contents. These are behavioral facts absent from the schema and critical for an agent to predict tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but length is justified by 14 parameters with 0% schema coverage — the prose is the only parameter documentation. It is well-structured: core purpose, then behavioral context, then the always-returned guarantee, then Args. Every sentence earns its place, though a few lines (e.g., 'Optional metadata filters') are thinner than their siblings. Minor tightening would be possible, but overall it is dense without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool (14 params, nested objects, no annotations) the description is remarkably complete: it explains what the tool aggregates, what it always returns, all parameter semantics, the future synthesize stub, and fallback behavior. An output schema exists, so the description rightly omits return-value details. The only conceivable gap is explicit sibling routing, which is already covered by the purpose framing. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 — and it does. Every one of the 14 parameters receives semantic elaboration beyond the schema: k bounds both search hits and TODO matches, include_todos explains the matching rules and legacy memora/ prefixes, include_related_hops clarifies the cap, date_from/date_to specify ISO or relative '7d' formats, and seed_ids explains it 'expands lineage/related from' the given ids. This is exemplary compensation for an undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Return a deterministic digest of memories related to a topic.' It immediately distinguishes itself from siblings by framing the tool as an 'aggregation surface... not a narrative generator' and enumerating exactly what it combines (hybrid-search hits, supersession lineage, related ids, TODO/issue memories). This clearly differentiates it from memory_get, memory_list, and memory_hybrid_search without needing to open any sibling schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: 'aggregation surface for agents that need current context.' It also provides an implicit when-not ('not a narrative generator') and a fallback hint that callers can 'inspect primitives if the digest is too broad or too narrow.' However, it stops short of naming explicit sibling alternatives (e.g., 'use memory_hybrid_search for raw ranked hits') or stating hard exclusions, so the routing guidance is context rather than explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it succeeds: it discloses the marking mechanism, the read-hiding behavior, the live-lease exclusion, the exact threshold/condition for completing vs removing rows, automatic triggers, and the returned counts. The destructive 'removes' behavior is explicitly stated, so an agent can anticipate side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is about 90 words and every sentence adds distinct information: purpose, marker mechanics, lease exception, decision rule, automatic invocation, and return values. The purpose is front-loaded and the structure is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter admin sweep with no annotations, the description is unusually complete: it specifies the return counts, the automatic-trigger contexts, the lease exception, and the exact completion/removal rule. An agent has enough information to decide whether and how to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, older_than_minutes, has 0% schema description coverage, so this description must compensate. It does so by defining the threshold meaning: marked rows older than this value are acted on, while younger markers are left alone. It stops short of discussing edge values or the default, but the schema already provides the type and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific action ('finish or remove rows') and the exact context ('an interrupted import left behind'), which makes the tool's role immediately clear. The mechanism (D1 import row markers, metadata.import_attempt) further disambiguates it from the memory_* siblings, including memory_import itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly identifies the use case ('interrupted import left behind') and adds that it also runs automatically at import start and server startup, which is valuable context. It does not explicitly name alternatives or negative conditions, but no sibling sweeper tool exists and the auto-run note implies when manual invocation is or isn't needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full behavioral disclosure burden. It does so thoroughly: it explains eventual consistency, non-cascading updates to related lists, the effect of refresh=True, and the special handling of empty stored lists. This is far more than a typical surface-level description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the consistency information is structured into clear sections. Most sentences add real value, but the parenthetical changelog note ('Before this change an empty list was recomputed on every call.') is historical context that is not needed to call the tool correctly and adds minor bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the consistency model, refresh override, empty-list semantics, and the rebuild alternative. An output schema exists, so return-value details are not required. Overall, an agent has everything critical to correctly select and invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains refresh=True in detail, including consistency semantics and recomputation behavior. The memory_id parameter is only minimally described as 'a given entry,' but the schema already identifies it as a required integer memory identifier, making the combined meaning adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Return cross-referenced memories for a given entry.' It clearly identifies the tool's function and its scope, and distinguishes it from sibling memory_rebuild_crossrefs by describing the per-entry refresh path versus the store-wide rebuild path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage directives: pass refresh=True for the strong-consistency recompute path, and call memory_rebuild_crossrefs for a full rebuild across the store. It names an alternative and the condition that selects it, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it delivers: it discloses the parsing side effect, that version >1 supersedes the previous version, that crossref computation is skipped by default, and that tags/metadata/project propagate to root and fragments (including the '<project>/documents' tag transform). It stops short of a 5 by not stating same-key/same-version re-store semantics or permission requirements, but this is substantial behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary is front-loaded with the purpose, followed by a cleanly organized Args and Returns structure. Nothing is filler, but the prose is dense in places, particularly the project parameter description which is somewhat convoluted. Appropriately sized for a complex 7-parameter tool, though not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool (7 params, nested metadata object, markdown parsing, versioning, fragment propagation) with zero annotations and an output schema present, the description covers purpose, all parameter semantics, side effects, defaults, and the return shape. The remaining gaps — same-key re-store behavior and explicit sibling differentiation — are minor relative to the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates with an Args section that documents all 7 parameters with real semantics beyond names/types: defaults (version default 1, skip_fragment_crossrefs default True), side effects (tags/metadata merged into root and fragments), and behavioral rules (version >1 supersedes; project tag becomes '<project>/documents'). Every parameter gains meaning the schema alone lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource ('Store a structured document as a root memory + searchable fragments') and the second sentence details the mechanism ('Parses markdown into typed fragments... while the full document remains retrievable as a unit'). This clearly distinguishes it from siblings like memory_create, memory_create_batch, and memory_create_section by emphasizing the whole-document-plus-fragments structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through the mechanism described (markdown documents that should be split into searchable typed fragments), but the description never explicitly states when to choose this over alternatives such as memory_create, memory_create_batch, or memory_absorb, nor does it name any exclusions or sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.