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

The description goes beyond the readOnlyHint and destructiveHint annotations by detailing the internal process: recalling top-k entities, assembling context, and querying the configured LLM (Ollama) for an answer with cited sources. It also discloses the dependency on the '--llm-endpoint' configuration, which is critical for the tool's 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 extremely concise: two short sentences. The first sentence clearly states the primary function, and the second adds important internal details and a requirement. No extraneous words; every sentence 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?

For a tool with 2 parameters, full schema coverage, and an output schema (indicated by context), the description covers the key aspects: purpose, internal process (RAG, top-k, LLM), and a configuration requirement. It lacks explicit mention of which memories are queried (e.g., current workspace) but remains sufficiently complete for an agent to correctly invoke the 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?

The input schema provides full descriptions for both parameters ('query' and 'top_k'), achieving 100% schema coverage. The description mentions 'Internally recalls top-k entities' which adds marginal context to the 'top_k' parameter but does not significantly enhance understanding beyond the schema. Given high schema coverage, the description adequately complements but does not surpass the baseline.

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: ask a natural language question and get a grounded answer from stored memories via RAG. It uses a specific verb ('ask') and resource ('stored memories'), and the wording distinguishes it from sibling tools like 'mimir_recall' or 'mimir_synthesize' by emphasizing the natural language Q&A nature.

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 prerequisite ('Requires --llm-endpoint to be set') but does not provide explicit guidance on when to use this tool versus alternatives (e.g., mimir_recall for raw retrieval, mimir_synthesize for generation without memories). The usage context is somewhat implied through the tool's purpose, but lacking explicit when-not-to-use or alternative recommendations.

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?

Annotations already declare readOnlyHint=true. The description adds valuable context about history retention ('when a fact is overwritten, the prior version is kept') and the return behavior ('Returns found=false if not recorded yet'). This goes beyond annotations.

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

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

Four concise sentences, each adding value: purpose, history explanation, use cases, return behavior. 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 presence of an output schema (not shown but indicated), the description covers purpose, behavior, and return field ('found'). It lacks mention of error conditions but is sufficiently complete for a time-travel query 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 100%, so baseline is 3. The description mentions 'category + key' and 'as_of_unix_ms' but uses similar wording as the schema. It does not add significant new meaning 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 uses specific verb ('return the version of a fact') and resource ('category + key') and distinguishes from siblings by highlighting time-travel and history. It also gives concrete use cases like 'what did we believe about X back then?'.

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 says 'Use to answer...' providing clear context for when to use this tool. It does not explicitly exclude alternatives but implies that for current versions other tools would be used. This is sufficient for an agent.

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?

Annotations already indicate destructiveHint=true, and the description elaborates on the specific operations (promote, link, archive, recalculate decay) and the atomicity of the pass. It provides behavior beyond annotations, though it could detail what gets archived or destroyed more precisely.

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 succinct sentences: the first states the action and steps, the second provides the dry_run option. No wasted words, front-loaded with 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 composite nature of the tool and the presence of an output schema, the description adequately covers the operation, steps, atomicity, and dry_run feature. It 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?

The input schema covers the single dry_run parameter (100% coverage). The description reinforces its purpose but adds little new meaning beyond the schema's description. Baseline score 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 the tool runs a full atomic grooming pass consisting of cohere, decay, and compact steps, and returns a summary report. This distinguishes it from sibling tools that operate individually (e.g., mimir_cohere, mimir_decay, mimir_compact).

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 mentions using dry_run=true to preview without changes, offering conditional guidance. However, it does not explicitly state when to use this composite tool versus running the individual steps separately, leaving some ambiguity for the agent.

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 states that the tool records a data point, which aligns with the destructiveHint annotation (modifying state). No contradictions; the annotation handles the behavioral trait, and the description adds the context of what is recorded. However, it does not disclose additional side effects like persistence or idempotency, which is acceptable given annotation coverage.

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 two sentences (40 words), front-loaded with the action verb 'Record', and contains no redundant information. Every sentence adds value: the first states the primary purpose, the second explains the metrics and relation to mimir_recall.

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 8 parameters (4 required) and an output schema (not shown), the description covers the core purpose and the relationship to sibling tools. It mentions the metrics being tracked but does not elaborate on the output schema or optional parameters like tags and session_id, which are adequately documented in the schema.

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 100%, so the schema already documents all parameters. The description adds collective meaning by mentioning the key metrics (turns, tokens, success, memory recall) but does not provide new details beyond what the schema offers. Baseline score of 3 is appropriate.

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 the specific verb 'Record' and clearly identifies the resource as a 'performance benchmark data point'. It lists the tracked metrics (turns, tokens, success, memory recall) and explicitly distinguishes from sibling mimir_recall by noting aggregation for trend analysis.

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 recording benchmark data to measure Mimir's impact and directs users to aggregate with mimir_recall for analysis. While it does not list exclusions or alternatives beyond mimir_recall, the context is sufficient for an agent to decide when to invoke this tool.

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 that the tool modifies memory (promotions, decay, auto-links, archives), which aligns with the 'destructiveHint: true' annotation. It adds context beyond the annotation by specifying what changes occur, though it could mention potential side-effects more explicitly.

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: the first clearly defines purpose and actions, the second adds a practical tip. No extraneous information, highly 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 the presence of an output schema and 100% schema description coverage, the description adequately covers the tool's behavior, parameters, and usage. It lacks nothing essential for an autonomous grooming pass.

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 covers all 4 parameters with descriptions (100% coverage). The description adds only a minor hint about dry_run. Baseline 3 is appropriate since the schema already provides adequate 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 tool's purpose: 'Run an autonomous coherence grooming pass over the memory.' It lists specific actions (promotes buffer entities, applies decay, auto-links, archives) that distinguish it from siblings like mimir_compact, mimir_decay, or mimir_prune.

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 a clear usage hint: 'Use dry_run=true to preview without making changes.' It implies the tool is for grooming memory but does not explicitly compare to alternatives or state when not to use it. This is sufficient but not exhaustive.

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 confirms destructive behavior via 'archive', aligning with the destructiveHint annotation. It adds the dry-run behavioral trait but does not disclose what archiving entails (e.g., reversibility, data loss). More transparency about consequences would improve this score.

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: first states purpose and dry-run support, second suggests usage pattern. No redundant words or fluff; every sentence 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 presence of output schema (not shown but indicated), the description covers the core action and usage pattern adequately. It could detail consequences of archiving (e.g., recoverability), but overall it is sufficiently complete for a tool with well-documented parameters.

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 100% description coverage, with clear explanations for both parameters ('dry_run' and 'min_decay'). The tool description does not add new meaning beyond reiterating the decay threshold and dry-run mode, so value is marginal.

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 'Archive' and the resource 'entities whose decay score has fallen below a threshold'. It specifies the dry-run mode and mentions periodic/threshold-triggered usage, distinguishing it from sibling tools like mimir_prune or mimir_purge.

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 advises to run 'periodically or threshold-triggered' and mentions dry-run mode for previewing. It does not explicitly state when not to use this tool or list alternatives, but the given context is clear and actionable.

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?

Contradiction: description claims 'Read-only by default' but annotations set readOnlyHint=false, indicating the tool may cause side effects. This inconsistency undermines transparency. Otherwise, description explains behavior well.

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?

Well-structured with main purpose upfront, then details on resolve mode. A bit lengthy but each sentence adds value. Could be slightly more concise, but still 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?

Comprehensive for a complex tool with 7 parameters and output schema. Covers both detection and resolution, safety mechanisms, and parameter behavior. No gaps 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?

All 7 parameters have descriptions in schema (100% coverage). Description adds value by explaining how parameters interact (e.g., dry_run with resolve, certainty_margin for ambiguity) and the trigram similarity context for threshold.

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?

Description clearly states the tool detects conflicting entities in the same category using trigram similarity on body_json. It distinguishes itself by offering both read-only detection and optional conflict resolution, specifying the exact purpose and key actions.

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 clear usage context: read-only by default, opt-in with resolve=true, dry_run preview, and certainty_margin to avoid ambiguous resolutions. Could explicitly state when not to use, but still strong 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?

Annotations already declare readOnlyHint=true. The description adds behavioral context by specifying the output is pre-formatted markdown and the downstream use case. It does not contradict annotations and provides useful information beyond them.

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 two sentences long, front-loaded with the core purpose, and every word adds value. No fluff or 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 presence of a full input schema (100% coverage), an output schema, and readOnlyHint annotation, the description is sufficient. It explains the output format and use case, but could optionally include details about the structure of the markdown or how 'most important entities' are determined.

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 100% description coverage for both parameters (limit and categories). The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a pre-formatted markdown context block of important entities for session injection, naming the downstream system Perseus. It is specific about the verb (return) and resource (context block), and the purpose is distinct from sibling tools like mimir_recall.

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 pre-loading AI agent context before work begins (session injection). However, it does not explicitly state when to avoid using this tool or mention alternatives among the many sibling mimir tools. The guidance is adequate but not explicit.

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?

Annotations give destructiveHint: true, which the description aligns with by stating it stores entities. The description adds value beyond annotations by explaining the dual storage (correction entity and journal entry) and the self-improving feedback loop across sessions. 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 concise with two sentences, front-loading the purpose and usage. Every sentence is informative and necessary: first sentence defines the action and storage, second covers when to use and the learning benefit. 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 7 parameters and an output schema (not shown), the description covers the main action, usage, and outcome. It could mention side effects or prerequisites, but the core functionality is well explained for an AI agent to use 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 coverage is 100%, so parameters are well documented. The description reinforces the key parameters (wrong_approach, user_correction, task_context) by naming them in prose, adding context that they capture what went wrong and what the user said.

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 'Capture' and the resource 'user correction'. It distinguishes from siblings like mimir_remember and mimir_journal by specifying it stores corrections, not general facts. The phrase 'Use this every time the user corrects your approach' reinforces the specific purpose.

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 says when to use the tool: 'every time the user corrects your approach'. It does not explicitly list alternatives or when not to use, but the context implies other tools for other purposes, making it clear enough for an AI agent.

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 adds behavioral detail beyond the destructiveHint annotation by explaining auto-archiving of low-score entities and the effect on recall results. There is no contradiction with annotations.

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

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

Two sentences efficiently front-load the main action and then provide usage and consequence. Every sentence is valuable, with no unnecessary 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's simplicity (no parameters, clear destructive side effect) and the existence of an output schema, the description covers all necessary aspects: what it does, when to use it, and behavioral outcomes.

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 and 100% schema coverage, the description's baseline is 4. It adds no parameter information because none is needed, which is appropriate.

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 recalculates Ebbinghaus decay scores and auto-archives fully decayed entities, specifying both the verb and resource. This distinguishes it from sibling tools like mimir_forget or mimir_purge by its specific decay recalculation purpose.

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 advises running periodically to keep memory fresh, providing clear usage context. However, it does not explicitly exclude use cases or compare alternatives among siblings, so guidance is good but not exhaustive.

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?

Annotations already indicate destructiveHint=true, so the description's addition of 'Generate and store' and the dependency on Ollama adds some context. But it doesn't detail what gets overwritten or the exact 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?

Two sentences that front-load the purpose and then detail modes and requirements. Every sentence adds value with 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?

For a tool with 5 optional parameters and an output schema, the description covers operation modes and prerequisites. It doesn't describe return values, but the output schema likely handles that. It's mostly 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?

Schema description coverage is 100%, so the description adds minimal value beyond the overview of modes. It reiterates the mode logic but doesn't enhance parameter understanding significantly.

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 generates and stores dense vector embeddings for entities, distinguishes between single and batch modes, and mentions the Ollama endpoint. This differentiates it from sibling tools like mimir_recall or mimir_remember.

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 explains when to use single mode (category+key) vs batch mode (batch_category) and notes the requirement for --llm-endpoint. However, it lacks explicit exclusions or alternatives, so it's not a 5.

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?

Beyond annotations (readOnlyHint=true), description adds 'never writes to the store' and details on deterministic, local, no-network operation. No contradiction with annotations.

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

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

Two efficient sentences, front-loaded with main purpose. No redundant information.

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 output schema exists, description covers inputs, usage, and behavioral traits sufficiently. No gaps.

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 100%, description adds clarification on usage of `text` vs `category`+`key` and explains `strategy` enum values (local heuristics vs no-op). Adds meaning beyond 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 verb 'extract' and resource 'structured knowledge' from raw text or stored entity. Distinguishes from siblings by specifying local, deterministic rule-based extractor. No tautology.

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?

Explains usage options: provide `text` or `category`+`key` directly. Does not explicitly list when not to use or alternatives, but clear context is 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?

Annotations provide destructiveHint: true, so description doesn't need to repeat that, but the description says 'copying or moving' without clarifying whether source entities are preserved. No mention of authorization or rate limits.

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

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

Three sentences: purpose, mechanism, use case. Front-loaded with action verb. No unnecessary words. Efficient and readable.

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?

Output schema exists and parameter coverage is high. However, the tool involves data transfer and potential destructiveness; the description should clarify what happens to source entities and handling of duplicates. Lacks these details.

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 100% with good parameter descriptions. The tool description reiterates the purpose of each parameter without adding new details beyond the schema, so baseline 3 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 it federates entities between workspaces via export, remap, import. It distinguishes from manual file transfer but does not explicitly name sibling tools like mimir_vault_export/import or mimir_share, though the usage hint helps.

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?

Explicitly says 'Use this for cross-agent or cross-project knowledge sharing without manual file transfer', indicating when to use. Lacks explicit when-not-to-use or 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?

Beyond the destructiveHint annotation, the description adds that it is a soft-delete (recoverable) and that the entity becomes hidden from queries. This provides useful behavioral context that annotations alone do not convey.

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, front-loaded with the key action and effect. Every sentence adds value: the first explains what it does, the second when to use it. 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's complexity, presence of an output schema, and full schema parameter descriptions, the description adequately covers purpose, behavior, and usage context. It is sufficient for an agent to select and 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?

Schema coverage is 100% and the schema already includes descriptions for all three parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline for this 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 the action ('soft-delete an entity'), the mechanism ('setting archived=1'), and the effect ('hidden from queries but recoverable'). It implies a contrast with permanent deletion tools like purging, distinguishing its purpose.

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?

Explicitly says to use it to 'clean up stale or incorrect facts without permanent data loss,' providing clear context. It does not, however, mention when not to use it or list alternative sibling 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?

The description aligns with the readOnlyHint annotation by stating 'Get an entity'. It adds behavioral context that the tool retrieves full body_json content, which is beyond what the annotation provides. 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 three sentences, each providing essential information: purpose, usage recommendation, and parameter source. It is efficient with 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's simplicity (one parameter, output schema present), the description fully covers purpose, usage context, and parameter explanation. No gaps remain.

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 coverage is 100%, so baseline is 3. The description adds extra context by explaining that the ID comes from a recall result or preview cap footer, which goes beyond the schema description 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 'Get an entity by ID with its full body_json content', using a specific verb and resource, and distinguishes it from the sibling tool mimir_recall which returns preview-capped results.

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 says 'Use after mimir_recall with preview_cap to read the complete body of a truncated result', providing clear context for when to use this tool, though it does not explicitly mention when not to use it.

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

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

Annotations already declare readOnlyHint=true. Description adds that it checks server and DB, and returns simple status, which is useful context but doesn't go beyond what's expected.

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, no wasted words, front-loaded with purpose and 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?

Fully covers what the tool does, when to use it, and what it returns. Output schema exists, so no need to detail return structure.

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; baseline 4 applies as description doesn't need to add parameter info.

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 verb (check), resource (Mimir server and its SQLite database), and output (healthy/unhealthy). Distinguishes from sibling mimir_stats.

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?

Explicitly says to use for health checks and monitoring, and not for detailed stats, naming the alternative tool mimir_stats.

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?

Annotations already provide destructiveHint: true, indicating mutation. The description adds context about preview mode (dry_run) and connector selection, but does not detail potential side effects like overwriting or merging behavior, which would be useful. Overall, it adds some value beyond annotations.

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

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

The description is extremely concise (two sentences), front-loads the main purpose, and avoids any unnecessary words or repetition.

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 annotations and output schema present, the description adequately covers the tool's purpose, invocation patterns, and preview capability. It does not explain the exact behavior of syncing (e.g., upsert vs replace), but that is likely implied by the tool's name and common patterns.

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 100%, so the schema already documents both parameters. The description reiterates the dry_run and connector usage but does not add significant new semantic information 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 tool syncs external data connectors (GitHub issues, file watcher) into Mimir, distinguishing it from many sibling tools that are about querying, managing, or modifying Mimir data.

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 call with no arguments (run all enabled connectors) and when to specify a connector, and mentions dry_run for preview. It does not explicitly discuss when not to use it or alternatives, but the context is sufficient for an AI agent to select it appropriately.

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 beyond the destructiveHint annotation: it is local-only ('no cloud, no network'), describes format support (plaintext/markdown/structured-text work always, DOCX/PDF require a feature flag), and explains that extracted text is stored as a normal entity recallable via mimir_recall. No contradictions with annotations.

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

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

The description is compact (three sentences) and front-loaded with the core action. Every sentence adds essential information: what it does, where it runs, format quirks, defaults, and recall mechanism. 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 the tool's moderate complexity (format-dependent behavior, local processing, default values), the description covers all necessary aspects: processing location, format support with fallback, default values, and integration with recall. The presence of an output schema is noted but not required for 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?

Schema coverage is 100%, and the description adds valuable defaults: key defaults to file name, category defaults to 'document'. This enriches the schema-defined parameters. The description also implies that path is the primary parameter.

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 that the tool ingests a document file into memory by extracting text locally. It specifies the verb 'Ingest', the resource 'document file', and the scope (local extraction, no cloud/network). It distinguishes from siblings like mimir_ingest (general ingest) by focusing on file-based ingestion with local text extraction.

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 guidance on when to use the tool (ingesting document files) and mentions limitations (DOCX/PDF require --features multimodal, otherwise error). It does not explicitly list when not to use, but the context is sufficient. It implies an alternative (mimir_recall for retrieval) but does not contrast with other ingest 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?

Annotations declare destructiveHint: true, suggesting the tool may have destructive side effects, but the description only says 'Append,' which implies additive behavior. No explanation of why it's destructive, what gets destroyed, or other behavioral traits beyond the annotation.

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: the first states the purpose, the second explains the pattern. No superfluous content. Front-loaded with the core 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 tool has an output schema (not shown but present), the description does not need to explain return values. Parameter count is 8, all described in schema and enriched by pattern explanation. The description is complete for a logging tool with clear audit trail purpose.

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 100% with descriptions for all 8 parameters. The description adds value by explaining the 'evaluated/acted/forward' pattern, which provides context for how parameters like 'evaluated', 'acted', and 'forward' relate to each other, enriching 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's purpose: 'Append a structured decision/observation log entry.' It uses specific verbs ('append', 'log') and names the resource ('decision/observation log entry'). Sibling tools like mimir_recall and mimir_context are differentiated by this logging focus.

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 'essential for audit trails and timeline reconstruction' but does not explicitly state when to use this tool versus alternatives (e.g., mimir_recall for retrieval, mimir_context for context). No exclusions or alternative suggestions are provided, leaving ambiguity.

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 confirms the link creation is destructive (as per destructiveHint) but adds no further behavioral context beyond building a graph. Since annotations already flag destructiveness, the description provides marginal added value.

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

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

The description is three concise sentences, front-loading the key action and purpose. Every sentence adds necessary context without redundancy or 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?

The tool has 4 parameters and an output schema. The description covers the core functionality and relationship types, but omits prerequisites (e.g., entities must exist) and potential side effects. Given the output schema exists, the gap is moderate.

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 100%, so parameters are already documented. The description mentions relationship types, which are also in the schema's 'relationship' parameter description. Thus, no significant extra meaning is added 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 uses a specific verb ('Create') and resource ('relationship link from one entity to another'), clearly stating the purpose. It distinguishes from sibling tools like mimir_unlink and mimir_traverse by explaining that it builds a knowledge graph for traversal.

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 lists allowed relationship types ('depends_on', 'implements', 'extends', 'references', or custom) and connects it to mimir_traverse. While it doesn't state when not to use, the sibling name mimir_unlink implies the complementary operation.

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 that deduplication archives the oldest entity, vacuum reclaims disk space, and reindex rebuilds FTS5. It also mentions dry_run for preview. This adds detail beyond the 'destructiveHint' annotation, though it does not specify whether orphan detection deletes or only lists.

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 two concise sentences. The first immediately states the tool's purpose and lists operations, the second gives actionable usage tips. 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?

For a maintenance tool with 6 boolean parameters and an output schema, the description covers the key operations and gives usage hints. It doesn't mention prerequisites or safety notes, but the destructiveHint annotation and dry_run option partially address that. Overall, it is sufficient for basic 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 100% schema coverage, each parameter already has a description. The description adds value by showing how to combine parameters (dry_run with all) and the general usage pattern, providing context beyond the schema's individual 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 explicitly lists the specific maintenance operations (deduplicate, detect orphans, vacuum, reindex) and states it covers database maintenance. This clearly distinguishes it from sibling tools like mimir_ask or mimir_compact by its domain and actions.

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 basic usage tips (dry_run=true to preview, use 'all' to run everything) but does not explain when to prefer this tool over individual siblings like mimir_prune or mimir_reindex. There is no explicit when-not or alternative 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?

The description explains the process (reads old DB, converts, merges) adding behavioral context beyond the destructiveHint annotation, confirming it modifies the current database.

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-load the main action without any extraneous words, every sentence 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 presence of an output schema, the description covers purpose, process, and usage comprehensively for a one-time migration 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 100% schema coverage and only one parameter fully described in the schema, the description adds no additional parameter meaning 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 tool migrates a v0.1.x Mimir database to v0.5.0 schema, distinguishing it from siblings that perform other operations like ask or forget.

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?

'Use this once per legacy database during upgrade' provides explicit when-to-use context, but no exclusions or alternatives are mentioned, which is acceptable given the one-time migration nature.

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?

Annotations provide destructiveHint=true; description adds that dry_run allows preview and mentions cleaning purpose, but does not detail what 'archive' entails (e.g., reversibility, side effects) or how entities are affected beyond filtering criteria.

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: first states action and criteria, second provides a tip and use case. 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?

With 5 parameters, destructive behavior, and an output schema, the description covers core action and a preview tip but omits behavioral details (e.g., what 'archive' means, error handling, or output format). Output schema exists, so return values need not be explained, but other gaps remain.

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?

Input schema has 100% coverage with descriptions for all parameters. Description adds context for dry_run and relates cleaning to decay/age, but this is minimal beyond 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?

Description clearly states it bulk archives entities by category, decay threshold, or age, with the verb 'archive' and resource 'entities'. It hints at cleaning stale memories but does not explicitly distinguish from siblings like mimir_forget or mimir_purge.

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 guidance to use dry_run=true for preview and states it's useful for cleaning stale memories, but lacks explicit when-not-to-use or alternative sibling 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?

Beyond the destructiveHint annotation, the description explicitly states that archived entities are deleted and NOT RECOVERABLE, and that VACUUM is performed. This adds crucial behavioral context not captured by annotations alone.

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 convey the core action, context, sibling differentiation, and parameter hint. No wasted words; front-loaded with the primary function.

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 covers return values, the description fully addresses what the tool does, side effects (irreversibility), comparison to siblings, and parameter usage. Complete for the tool's complexity.

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

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

Schema coverage is 100%, and the description adds value by explaining that dry_run=true allows preview without changes, which clarifies the parameter's purpose beyond its schema description.

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: permanently delete archived entities and run VACUUM. It distinguishes from sibling tools (prune/forget) by specifying that it is the only operation that actually removes entities.

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 that this tool is for permanent deletion versus soft-archive from prune/forget, and mentions dry_run preview. It does not explicitly state prerequisites or when not to use, but the contrast with siblings provides sufficient 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?

Annotations already declare readOnlyHint=true; description adds valuable behavioral details: OR'ing of words, relevance sorting, expanded fields, and transparent decryption of body_json, which is beyond what annotations offer.

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

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

Three sentences, front-loaded with key information, no fluff. Every sentence adds 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?

Despite a complex tool with 17 parameters and output schema, the description omits mention of search modes (fts5, dense, hybrid) and filtering capabilities, leaving gaps for a complete understanding.

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 100% with each parameter already described; the tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

Clearly states it searches entities with FTS5 keyword search, but does not explicitly differentiate from sibling tools that may offer alternative search methods like vector or hybrid.

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 use cases (find facts, decisions, architecture notes) but lacks explicit guidance on when not to use or when alternatives like mimir_recall_when might be better.

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?

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds behavioral context (proactive, context-matching) but does not detail edge cases (e.g., no match behavior, performance). With annotations covering the main safety aspect, a score of 3 is appropriate.

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. The first sentence defines the function, the second gives concrete usage scenarios. Front-loads key information 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?

Given the moderate complexity (2 params, output schema present), the description covers purpose, usage, and context. With output schema, return details are not needed. Some might expect a note on default limit, but schema covers that. Score 4 reflects slight gap in explaining the 'recall_when trigger' concept.

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 100%, so both parameters are documented. The description adds minimal extra meaning beyond the schema: it reinforces that 'context' is the task description to match triggers. This is marginal improvement, hence baseline 3.

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 searches entities based on recall_when triggers matching a given context. It uses specific verb and resource ('Search entities whose recall_when triggers match') and distinguishes from sibling tools like mimir_recall by focusing on trigger-based recall.

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 states when to use: 'for proactive just-in-time memory injection — before writing code, before plans, at session start.' It implies usage context but does not explicitly mention when not to use or name alternatives like mimir_recall.

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?

Annotations already mark destructiveHint=true. The description adds the return value (number reindexed) and specific triggers, but does not disclose other behavioral traits like potential locking, idempotency, or performance impact, which would be helpful.

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. The first sentence states the action, the second provides context and return. Efficiently 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?

For a zero-parameter tool with destructive hint and output schema, the description covers purpose, triggers, and return. Could mention whether it is safe to run repeatedly, but overall sufficient given low 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?

The input schema has zero parameters, so no parameter documentation is needed. Baseline is 4 for zero-parameter tools, and the description does not need to add parameter info.

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 rebuilds the FTS5 search index, with specific triggers like direct SQLite writes or interrupted archives. It distinguishes from siblings by focusing on index drift repair for recall/search, though it could explicitly contrast with other maintenance tools like mimir_compact.

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 lists when to use the tool (after direct SQLite write, interrupted archive, legacy database). It does not provide when-not-to-use or alternatives, but the context is sufficiently clear for the intended use 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?

The description adds significant behavioral details beyond the annotations: idempotency, encryption at rest (AES-256-GCM) when enabled, and the effect of always_on=true injecting into mimir_context. This complements the destructiveHint annotation.

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, consisting of four clear sentences. It front-loads the core function and immediately follows with key behaviors and use cases. No unnecessary 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 complexity (10 parameters, 3 required), the description covers essential aspects: idempotency, encryption, always_on, certainty usage, and appropriate use cases. An output schema exists, so return values need not be described. It could mention behavior on conflict or error, but overall it is adequate.

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 100% so the schema already documents all parameters. The description adds context for key parameters (e.g., key as unique within category, body_json as JSON object) and explains the purpose of optional fields like always_on and certainty. It does not cover every parameter in detail but provides meaningful usage guidance.

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 'Store or update an entity by (category, key)' and lists specific use cases such as saving facts, decisions, architecture notes, and conventions. This distinguishes it from sibling retrieval or deletion tools.

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 mentions when to use the tool ('for saving facts, decisions, architecture notes, and conventions') and describes optional parameters like always_on and certainty. However, it does not explicitly state when not to use it or mention 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?

Annotations already indicate destructiveHint=true. The description adds that high scores resist decay and rank higher, but lacks details on idempotency, reversibility, or required permissions. The behavioral context is sufficient but not comprehensive.

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

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

The description is two sentences long, front-loaded with the action and followed by consequences. Every sentence adds value with 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?

For a simple scoring tool, the description covers purpose, effect, and usage. It does not explain the output format, but an output schema exists. It could mention prerequisites or error cases, but overall it is fairly 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?

Schema coverage is 100%. The description does not add new meaning beyond what the schema provides for the three parameters. The baseline of 3 is appropriate as the schema already documents parameters clearly.

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 'Assign', the resource 'entity', and the score range 0.0-1.0. It explains the effect on decay and recall ranking, and lists usage scenarios (mark as accurate, verified, deprecated). This distinguishes it well from the many sibling tools.

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 context on when to use the tool (to assign quality scores and mark entities) and hints at the consequences. However, it does not explicitly state when not to use it or compare to alternatives, which would further improve clarity.

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 states the original entity is unchanged, but the destructiveHint annotation is true. The description does not clarify if the tool can overwrite an existing entity in the target workspace or if it always creates a new one. Additionally, it does not mention permission requirements or other side effects, leaving some behavioral 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 two sentences, each serving a clear purpose: stating the action, detailing the effect, and providing usage guidance. No extraneous words, making it efficient and easy to parse.

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 (3 required params, no enums, output schema present), the description covers the core behavior well. However, it lacks details on source workspace determination, error handling for non-existent entities, and potential overwrite behavior. The presence of an output schema likely covers return values, so the description is nearly 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?

The input schema covers all three parameters with descriptions, achieving 100% coverage. The description adds context that the source workspace is implied (not a parameter), which is a minor addition. Baseline 3 is appropriate as the schema already provides adequate information.

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 copies an entity from its current workspace to another workspace, preserving content and metadata while generating a new ID. It distinguishes this from sibling tools like mimir_migrate or mimir_ingest by specifying the copy action and cross-workspace transfer.

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 says 'Use this for controlled cross-workspace knowledge transfer,' providing clear guidance on when to use the tool. It does not mention alternatives or when not to use it, but the context is sufficient for the primary use case.

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?

Annotations already declare destructiveHint=true, indicating the tool is destructive. The description adds that deletion is permanent and contrasts with soft-delete, providing useful context beyond the annotation. No contradiction.

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

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

Two sentences, each serving a distinct purpose: first states the action, second adds usage guidance and sibling differentiation. No unnecessary 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?

For a simple one-parameter tool with an output schema (present), the description adequately covers purpose, usage, and behavioral nuance. It is complete for the agent to correctly select and invoke the 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 coverage is 100% and the schema already describes the key parameter as 'State key to permanently delete'. The description mentions 'by key' but does not add substantial meaning beyond the schema, meeting the baseline for high 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 deletes a state entry by key, using a specific verb and resource. It distinguishes from the sibling tool mimir_forget, which is a soft-delete, making the purpose unambiguous.

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

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

Explicitly tells when to use: 'Use this to clean up expired or unused state entries.' Also clarifies when not to use by contrasting with mimir_forget, providing clear context for decision-making.

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?

Annotations already declare readOnlyHint=true. The description adds behavioral detail beyond annotations by stating 'Returns null if the key has expired or doesn't exist,' which informs the agent about return 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?

Two sentences, no wasted words. The description is front-loaded with the action, then provides return behavior and usage guidance, all in a compact form.

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 (1 parameter, output schema exists), the description covers purpose, null handling, and when to use, which is adequate. A minor gap is no mention of expiration behavior details, but overall 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 100%, so the input schema already documents the 'key' parameter. The description does not add extra meaning beyond what is in the schema, meeting the baseline of 3.

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 'Get a state value by key' with a specific verb and resource. It distinguishes itself from the sibling tool mimir_recall by mentioning transient session state and FTS5 search, ensuring no ambiguity.

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 is provided: 'Use this instead of mimir_recall for transient session state that doesn't need FTS5 search.' This clearly tells the agent when to use this tool over 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?

Annotations already declare readOnlyHint=true, so description adds value by specifying the listing behavior and prefix filtering, but could mention potential limits or pagination.

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

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

Two succinct sentences: first defines action, second provides use case. No extraneous information.

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 presence of an output schema and single optional parameter, description is mostly complete; could explicitly state that it returns a list of keys.

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 100% with a documented prefix parameter; description restates the parameter briefly but adds no new details 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?

Description clearly states it lists all state keys with optional prefix filtering, distinguishing it from sibling tools like mimir_state_get, mimir_state_set, and mimir_state_delete.

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 clear context about when to use (discover state entries without exact keys) but does not explicitly mention when not to use or contrast with alternatives like mimir_state_get.

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?

Annotations mark destructiveHint=true. Description adds TTL auto-expiration and permanent state option. Does not explicitly mention overwriting behavior, but that is implied by 'Set' and output schema may cover.

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, no fluff. First sentence states function, second gives usage context. Perfectly compact.

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?

Adequate for a simple setter with 3 parameters. Covers purpose, use cases, and TTL behavior. Output schema likely handles return values. Missing explicit overwriting note, but not critical.

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 100%. Description reinforces TTL parameter purpose and connects to use cases, adding marginal semantic value beyond schema 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 'Set a key-value state entry' with a specific verb and resource. It distinguishes itself from sibling state tools (get, delete, list) by focusing on creation/update with optional TTL.

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 explicit use cases: session state, temporary flags, configuration values with TTL. Does not specify when not to use or contrast with alternatives like mimir_remember, but the context is clear enough for an agent.

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?

Annotations declare readOnlyHint=true, which is consistent with the description. The description adds value by detailing exactly what statistics are returned, which goes beyond the annotation's simple read-only indication. 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 a single sentence that efficiently enumerates all returned statistics without redundancy. It is front-loaded with the main verb and resource, and every phrase adds 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 the tool has no parameters and an output schema exists (as per context signals), the description is complete. It covers all aspects of the output, and the agent can rely on the output schema for detailed structuring.

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, so the description doesn't need to explain parameters. However, it compensates by describing the output, which is useful for an agent. Baseline for 0 params is 4, and this description meets that.

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 specific verbs ('Return') and clearly lists the types of statistics (entity counts by category, type, decay layer; journal count; state count; file size; date range). It distinguishes itself from sibling tools like 'mimir_health' which likely focuses on system status, whereas this focuses on database content statistics.

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