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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds detail about output contents (provenance, trust, tier, last use, fade) and that it returns ledger rows. 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?

Two short sentences plus an Args line. Front-loaded with main purpose, no filler. 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?

For a read-only audit tool with one parameter and annotations covering safety, the description explains the output sufficiently. Doesn't mention ordering or pagination, but limit parameter covers row control.

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

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

Only parameter 'limit' with description 'Max rows' is already fully described in schema (100% coverage). Description adds 'default 30' which is also in schema. No extra 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?

Description clearly states it shows a transparent ledger of all memories with provenance, trust, tier, last use, and fade info. Distinguishes from siblings like mindmap_list (which likely lists without audit details) and mindmap_search (which searches).

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 gives use cases: user asks 'what do you know about me?', 'what's stored?', or wants to review/clean memory. Does not explicitly exclude cases where other tools might be better, but the context is clear.

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 show readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds value by explaining that the tool pulls prior thinking, promotes on reuse, and returns a brainstorm pack. There is no contradiction with annotations. It does not mention potential side effects beyond promotion, but for a brainstorming loader, the transparency is good.

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

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

The description is well-structured with separate paragraphs for purpose, usage, and flow. It front-loads the core functionality. While slightly verbose, every sentence contributes useful information. It could be trimmed slightly but remains efficient.

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 one parameter and no output schema, the description is complete. It explains the return value (brainstorm pack), the workflow (load, brainstorm, save), and the context (shared memory). It also references sibling tools appropriately, making the tool fully understandable in its ecosystem.

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

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

Only one parameter (topic) with full schema description coverage (100%). The description repeats the meaning ('what you're brainstorming about') but adds no new syntax or constraints beyond the schema. Baseline 3 is appropriate as the schema already provides the semantics sufficiently.

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 loads prior context for brainstorming on a topic using shared memory. It distinguishes itself by emphasizing that it pulls past brainstorms and related discussions, and it explicitly says when to call it proactively. The purpose is specific and actionable.

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

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

The description provides explicit guidance on when to use it: when the user wants to brainstorm, ideate, think through, or explore options on something that may have history. It also notes what it does not do (replace brainstorming ability) and gives a follow-up action (capture with mindmap_capture). It even mentions the 'promote-on-reuse' behavior.

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 indicate write operation (readOnlyHint=false), non-idempotent, non-destructive. The description adds the 'silently save' behavior and the lifecycle: captures start as 'captured' (warm tier) and become 'promoted' memories upon resume. It does not disclose potential limits or side effects, but the added context is valuable.

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

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

The description is front-loaded with the core purpose and proactive call instructions, then lists parameters with concise explanations. It is slightly long but every sentence earns its place by adding value. The structure is logical and easy to scan.

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

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

For a tool with 9 parameters and moderate complexity, the description covers purpose, usage guidelines, parameter semantics, and return value (thread id and formatted record). It lacks an explicit output schema but the return description is sufficient. Compared to siblings, it is complete enough for an agent to use correctly.

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

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

The input schema has 100% parameter description coverage. However, the description adds behavioral context: explains that next_steps enables resuming to 'continue the thread', gives examples for source, and clarifies the kind parameter's clustering effect. This adds meaningful guidance beyond the schema.

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

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

The description clearly states the tool's purpose: 'silently save a portable context summary from the current session so it can be resumed later in any tool.' It uses specific verbs ('save', 'capture') and resources ('portable context summary', 'session'). It distinguishes from sibling tools like mindmap_resume and mindmap_search by framing it as the 'capture half of the loop.'

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

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

The description provides explicit proactive guidance on when to call this tool: when a substantive discussion is wrapping up, the user signals they're done or says 'save this', a key decision is reached, or the user will continue later. It also advises to skip trivial exchanges. This clearly differentiates usage from siblings and sets context.

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

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

No annotation contradiction (idempotentHint aligns with settings update). Adds context that omitting args returns current settings and describes the return as 'effective config,' which is beyond the annotations.

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

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

Three sentences: first front-loads purpose, second gives usage tip, third lists args and return. No wasted 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 4 optional parameters, no required, no output schema, the description covers what the tool does, how to use it (view vs change), what each parameter affects, and what is returned ('effective config'). Sufficient for correct usage.

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

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

With 100% schema coverage, the schema provides basic parameter descriptions. The description adds semantic grouping ('decay windows,' 'promoted longevity factor') and clarifies the purpose of each parameter, adding 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 states 'View or change Mind Map settings' with specific settings listed, clearly distinguishing it from sibling tools like mindmap_audit or mindmap_get. The verb-resource pair is specific and unambiguous.

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

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

Explicitly says 'Omit all args to just view current settings,' providing clear context for when to use view vs change. While it doesn't mention when not to use or alternatives, the context is clear enough for correct invocation.

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?

Adds detail beyond annotations: soft forget keeps a searchable trace, recall never hard-fails. This is valuable context for the agent beyond the destructiveHint and idempotentHint tags.

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 clear sentences, front-loaded with purpose, efficient no-waste phrasing.

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

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

Covers all needed details: purpose, parameter behavior, return type (confirmation). No missing information for this simple 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 already covers both parameters (100% coverage). Description restates them but adds behavioral context (soft vs hard), which enhances understanding 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?

Clearly states the tool forgets a memory, distinguishes soft (archive) vs hard (delete) modes. Differentiates from sibling mindmap_persona_forget which targets persona memories.

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 when to use soft vs hard (default soft, hard for permanent deletion). Could mention not to use for persona memories, but siblings provide context.

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

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

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds 'does not change freshness' beyond annotations, clarifying a behavioral nuance. It also confirms read-only nature. 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 two sentences: one for purpose and one for args/returns. No filler, front-loaded with the key action. 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?

For a simple fetch-by-ID tool with one parameter and no output schema, the description is complete. It explains what to pass and what to expect in return. No missing critical information for straightforward usage.

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

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

Schema coverage is 100%, so baseline is 3. The description restates the parameter 'id (string)' and adds 'Returns: the full thread', which adds a little value but does not significantly expand on the schema's 'Thread id' 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 'Fetch the full content of one memory by id', which is a specific verb and resource. The title 'Get a memory' aligns. The description distinguishes it from siblings like mindmap_list, mindmap_search, and mindmap_update by focusing on fetching a single memory by ID.

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 'Read-only (does not change freshness)' implying safe use, but does not explicitly state when to use this tool over siblings like mindmap_list (for listing all) or mindmap_search (for searching). No exclusions or specific context are provided.

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

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

Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about the tool being opt-in, gamified, and rewarding pruning over hoarding, which goes beyond the annotations. 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?

The description is concise, with two sentences plus a short line about arguments and return value. Every sentence adds value, and the main purpose is 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 read-only tool with no output schema, the description provides sufficient context: what is reported (cleanliness score, stale candidates), the gamified nature, and the return structure. No additional information is needed.

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?

There are no parameters (0), and schema description coverage is 100% (vacuously). The description explicitly states 'Args: none', fulfilling the baseline expectation for zero-parameter tools.

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 reports a cleanliness score and lists stale candidates. It uses specific verbs ('reports', 'lists') and identifies the resource (memory health). The gamified curation surface aspect distinguishes it from sibling tools like mindmap_prune or mindmap_tidy.

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 that the tool should be used to check memory health and find candidates for pruning, but it does not explicitly state when to use it versus alternatives like mindmap_audit, mindmap_prune, or mindmap_tidy. No explicit when-not or exclusions are provided.

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

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

Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description adds value by detailing that it imports new sessions, optionally refreshes existing ones, and returns counts of imported/refreshed/skipped. It does not contradict 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 well-structured with a purpose paragraph followed by parameter and return details. It is front-loaded and each sentence adds value, though slightly verbose with the enumeration of trigger phrases. Still concise overall.

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 2 simple parameters and full schema coverage, the description explains the return value (counts) and provides context about auto-import. It is sufficiently complete for effective use, though no output schema exists to describe detailed response 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?

Schema coverage is 100% with descriptions for both parameters. The description adds meaning beyond the schema by explaining defaults ('default all', 'default false'), behavior ('limit to one source', 'refresh in place'), and the return value. This exceeds 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 the tool scans local AI-tool history and imports new sessions into Mind Map, specifying the verb 'import', resource 'sessions', and scope across multiple sources. It distinguishes from siblings like mindmap_list or mindmap_search, which serve different purposes.

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

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

The description provides explicit example phrases triggering use ('import my sessions', 'sync mind map') and contrasts with periodic auto-import as an alternative. However, it lacks explicit guidance on when not to use it or direct comparison with other siblings.

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 idempotentHint=true, readOnlyHint=false, destructiveHint=false. Description adds 'bidirectional' and 'lightweight', which are useful but not critical behavioral traits beyond annotations. No contradictions, but missing details like whether linking an existing link is safe (idempotent) or returns error.

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 plus a compact args/return line. Front-loaded with purpose, no wasted words. Well-structured and easy to scan.

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

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

Given tool simplicity, schema coverage, and annotations, the description gives enough context (purpose, bidirectionality, example). Could mention behavior if link already exists or what 'confirmation' means, but overall 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?

Input schema has 100% coverage with descriptions for both parameters ('First thread id', 'Second thread id'). Tool description simply restates these as 'id (string), target_id (string)' without adding new meaning. Baseline 3 applies per guidelines.

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

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

Description clearly states 'connect two memories so related threads cross-reference each other', uses specific verb 'connect' and resource 'memories'. It distinguishes from sibling tools by calling it 'lightweight map connective tissue', implying it pairs with other mindmap tools for cross-referencing.

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?

Description provides an example of when to use (planning in Chat + code in Claude Code) but lacks explicit guidance on when not to use or alternatives among the many sibling tools. Usage context is implied but not fully clarified.

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 readOnlyHint=true and destructiveHint=false. The description adds 'newest-used first' and 'Read-only', providing additional behavioral context without 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 efficiently convey purpose, characteristics, and parameters. No extraneous details, and key information is 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 rich annotations and full schema, the description is adequate for a simple list tool. It mentions return type, though lacks detail on memory structure; however, that is acceptable without an output 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 coverage is 100% with descriptions already provided. The description merely lists the filter names and defaults, adding no new meaning beyond what the schema already conveys.

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 (list), resource (saved memories), and key characteristics (newest-used first, read-only), which effectively distinguishes it from sibling tools like mindmap_search or mindmap_get.

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 optional filters but does not provide explicit guidance on when to use this tool versus alternatives like mindmap_search for more complex queries. The usage context is implied but not directly stated.

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

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

Annotations give idempotentHint true; description adds critical behavioral details: never stores API key, reads from env, stores only provider/model name, and returns status/ready/cost. This goes well 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?

Description is well-structured with clear sections (purpose, security, args, returns). It is slightly longer but every sentence adds value. Could be more concise, but overall effective.

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

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

Given 3 optional parameters and no output schema, the description covers everything: operation, security, arg details, return values (provider/model, ready status, cost note). It feels complete for a configuration 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% with enum for provider. Description adds meaning: all args optional, 'omit all to see status', default baseUrl, and enumeration examples. This adds value 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?

The description clearly states the tool configures an optional LLM with BYO key, and distinguishes it by being opt-in for smarter features. The verb 'configure' and resource 'LLM' are specific, and it stands out among sibling mindmap 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 explains when to use (to unlock smarter features) and that omitting all args returns status. It mentions security but does not explicitly state when not to use or list alternatives, though the context is sufficient.

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 and destructiveHint=false, so the description adds minimal behavioral context beyond stating the resource is owned by the user. 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?

Two sentences with no redundant words: first states purpose, second explains args and return value. Well-structured.

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

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

For a single optional parameter tool with no output schema, the description fully covers input (default path) and output (file path and counts). Complete for intended 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?

Schema describes parameter 'path' with basic description; the description adds the default filename pattern (~/mindmap-passport-<date>.json), providing value 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 verb 'Export', resource 'all memories + persona', and output format 'JSON'. Distinguishes from sibling 'mindmap_passport_import' by specifying export direction.

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 mentions use cases: 'to back up, move to another machine, or hand to a fork'. Implicitly suggests when not to use (when needing import), but does not explicitly state 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 non-read-only, non-destructive, non-idempotent. Description adds that it imports as 'distilled memories' and returns import counts. Could elaborate on side effects (e.g., duplicate handling) but sufficient.

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?

Front-loaded with 'Bring context IN.' Uses bullet points for kinds, making it scannable. Five sentences is appropriate; no redundant information. Slightly verbose in middle lines but still clear.

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

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

Given full schema coverage and no output schema, description mentions return of import counts. Covers all param semantics and tool purpose. Lacks error handling details but overall adequate for a simple import 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 covers both parameters with basic descriptions. Description enriches by showing default value for kind, listing enum options with explanations, and clarifying file is required. Adds meaningful context 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 imports data from files using 'Bring context IN' and explains three kinds (passport, chatgpt, claude). Distinguishes from sibling mindmap_passport_export which does the reverse. Specific verb+resource.

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?

Description provides clear context: use when you have a passport file from another machine or exported chat files. No explicit when-not or alternatives, but the purpose is well-defined and siblings are listed separately.

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, destructiveHint, idempotentHint. Description adds practical behavior: apply high-confidence facts silently, ask only for gaps. 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?

Well-structured with front-loaded purpose, then usage guidance, parameter, and return value. Every sentence adds value without redundancy.

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

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

Given no output schema, description explains return as 'About this user' block + fact count, which is adequate. Could be more specific about format, but sufficient for agent 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 covers the single optional 'project' parameter. Description adds context that it scopes preferences on top of global ones, adding value beyond the schema.

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

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

The description clearly states it returns a 'distilled profile of how they work'. It distinguishes from sibling tools like mindmap_persona_set and mindmap_persona_forget by focusing on retrieval rather than modification.

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 advises calling proactively at session start to avoid re-asking setup questions. Provides clear when-to-use and when-not-to-ask 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 mark destructive and idempotent. The description adds that default mutes are recoverable, and hard=true deletes, plus returns confirmation. This goes beyond annotations without 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 concise sentences plus a parameter list, no unnecessary words, front-loaded with key 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?

Covers all essential aspects for a simple tool: action, parameter effects, source of IDs, and return type. No output schema needed, but mention of confirmation is sufficient.

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

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

Schema coverage is 100%; the description restates parameters and links 'hard' to behavioral effect (delete vs mute), adding value 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?

The description clearly states the tool removes or mutes a persona fact, with specific examples (wrong or out of date). It distinguishes from siblings by referencing 'persona fact' and directing to mindmap_persona for IDs.

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

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

The description explains when to use (for outdated/incorrect facts) and implies origin of IDs, but does not explicitly mention when not to use or alternatives like mindmap_forget for non-persona facts.

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 annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses that inferred facts have lower confidence, never override explicit facts, and details two execution paths based on LLM configuration.

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. The first sentence states the core action and differentiation; the second explains the two modes and confidence behavior. 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 the simple tool (zero parameters, no output schema), the description covers all necessary aspects: purpose, execution modes, confidence behavior, and return value. It is complete for the agent to understand usage.

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

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

There are no parameters, so schema coverage is 100%. The description appropriately adds no parameter details, but it does describe the return value and execution paths, providing value beyond the schema.

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

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

The description clearly states the tool's purpose: to derive persona facts from existing memories. It distinguishes from sibling tools like mindmap_persona_set by noting that inferred facts have lower confidence and do not override explicit settings.

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

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

The description explains when to use the tool (to infer persona facts) and outlines two execution paths (LLM-rich vs keyword heuristic). It could be more explicit about when not to use or suggest alternatives, but the differentiation from explicit setting is clear.

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 are present and not contradicted. Description adds durability context ('future sessions don't re-ask') but doesn't specify overwrite or duplicate 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?

Front-loaded with purpose, then usage guidelines, then argument list. Each sentence is informative and concise.

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 no output schema, description explains returns. All necessary information for agent invocation is present.

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. The Args section in description mostly mirrors schema, adding minimal extra value.

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 saves durable preferences, distinguishes from sibling mindmap_capture, and provides concrete examples of when to use it.

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 usage context: 'when the user states a lasting preference' and alternative tool for saving discussions. Provides clear when-to-use and when-not-to-use.

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

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

Annotations (destructiveHint=false, idempotentHint=true) are supplemented by the description stating 'Writes only inside a managed block; never clobbers the user's own content.' This adds critical safety context beyond the structured data.

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 brief paragraphs: the first states purpose and a key safety feature, the second lists parameters and return. No wasted words, information is 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 tool with no output schema, the description mentions 'Returns: per-target outcomes,' which is adequate. It covers target selection, safety, and default behavior. Missing explicit usage guidance versus siblings, but overall 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%, but the description adds value by explaining default behavior for targets and the effect of force. It does not rely on the schema alone and provides meaningful context.

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 writes the user's persona into native instruction files of AI tools, specifying the key resources (CLAUDE.md, Cursor rules, etc.) and the action. It distinguishes itself from sibling tools like mindmap_persona which manage persona internally.

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 default behavior (global Claude config + detected project tools) and optional parameters. However, it does not explicitly state when to use this vs. alternatives like mindmap_persona_set, leaving some ambiguity about context.

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

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

Describes behavioral traits beyond annotations: promotion moves to hot tier, affects ranking and decay. Annotations already indicate mutability and idempotence, but description adds meaningful context. 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 plus args/returns line. Front-loaded with key action and effects. 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 single parameter, no output schema, and simple behavior, description fully covers purpose, usage, behavior, and return value. Agent can select and invoke correctly.

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

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

Schema coverage is 100% with a single parameter 'id' described as 'Thread id'. Description adds 'Args: id (string)' and return type, but no additional semantics beyond schema. 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?

Description clearly states verb (bless/promote), resource (memory), and specific effects: marks as promoted, moves to hot tier, impacts ranking and decay. Distinguishes from sibling 'resume' by noting use case even when not resumed.

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 when to use: when memory matters even if not resumed yet. No explicit when-not-to-use, but context makes it clear; alternatives are implied by the sibling list.

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?

Adds significant behavioral detail beyond annotations: explains that unused memories are cooled and cold ones collapsed to a trace (still searchable, never deleted). Annotations already indicate non-destructive and idempotent nature, and the description reinforces and elaborates on these traits.

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

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

Two concise paragraphs: first explains the process in detail, second describes arguments and return value. No unnecessary words. Highly efficient.

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 single parameter (fully documented), no output schema needed (description mentions return type), and the clear explanation of the consolidation process, the description is complete for an agent to understand usage and behavior.

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

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

The single parameter dry_run is fully described in the schema (100% coverage). The description repeats the same info verbatim, adding no additional semantics. 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?

Clearly states the action (run consolidation pass), the resource (memory tiers), and the specific operations (recompute, cool, collapse). Distinguishes itself from siblings like mindmap_forget by emphasizing that nothing is destroyed.

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?

Implies usage as a manual trigger for the automatic consolidation background thread, but does not explicitly state when to use this tool versus alternatives like mindmap_forget or mindmap_tidy. Lacks direct guidance on selection criteria.

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?

Describes behavioral traits beyond annotations: resolving description to best match, reassembling whole topic, merging fragments, promoting anchor on reuse, and surfacing next steps. Annotations are minimal; the description provides essential context about state modification.

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 well-structured paragraphs: first explains the core functionality, second gives proactive usage guidance. Every sentence serves a purpose without redundancy.

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

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

Given 3 parameters, no output schema, and modest complexity, the description fully covers what the tool does, how to use it, what it returns, and when to call it. 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 is 100%, providing descriptions for all parameters. The description adds value by explaining the relationship between parameters ('Provide query OR id') and the natural language usage for query.

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+resource combination: 'Restart a topic... resolves... reassembles...'. It clearly distinguishes from sibling tools like mindmap_resume_options and mindmap_get by explaining the merging and promotion behavior.

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

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

Explicitly states 'CALL THIS PROACTIVELY at the START of a session' and provides examples of user cues. It also explains when to use the id parameter (after user picks from mindmap_resume_options), giving clear context and 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, idempotentHint, and destructiveHint. The description adds that it is read-only and promotes nothing, which is consistent. It also describes the return format (up to 5 candidates with fields), adding context 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 well-structured: a purpose sentence, usage note, then bulleted args. It is concise without filler, though slightly longer than necessary.

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

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

Given the tool's low complexity (2 params, no output schema), the description covers purpose, usage, parameters, and return format. It also links to the sibling tool mindmap_resume, providing a complete context for agent decision-making.

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 rephrases parameter descriptions: 'query' as natural-language input and 'source' as optional origin restriction. This adds interpretative value over the schema-only descriptions.

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

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

The description clearly states the tool lists distinct candidate topics for resumption when the user's description is ambiguous. It uses specific verbs ('list', 'ask') and resources ('topics'), and distinguishes from sibling tools like mindmap_resume and mindmap_list.

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

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

The description explicitly says when to use the tool: when the user's description is ambiguous or matches several topics. It provides a follow-up action to call mindmap_resume after user picks. No explicit exclusions, but clear 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 indicate read-only, non-destructive, idempotent. Description adds 'does not change freshness or tiers' and clarifies behavior of include_archived and empty query. 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?

Very concise: a single paragraph with a bullet list of parameters. Each sentence is informative and earns its place. Front-loaded with the main purpose.

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

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

Given 6 parameters fully documented in schema and no output schema, the description explains scope (every tier, every tool), read-only nature, parameter details, and return type. Also distinguishes from a sibling 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 has 100% coverage of parameters with descriptions. The description paraphrases the schema but adds minimal extra semantic information beyond what is already in the input schema.

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

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

Clearly states it searches across all saved context to find past discussions. The verb 'search' and resource 'saved context' are specific, and it distinguishes from sibling tools like mindmap_resume.

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 when to use (relocate a past discussion), when not to use (use mindmap_resume to pull forward), and provides context like empty query browses by recency.

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 read-only and non-destructive; the description adds that it 'only suggests' and returns 'stalest cold memories', providing behavioral context beyond structured fields.

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 plus a param/return line, no filler, and the most important purpose is 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 simple read-only list tool with one optional parameter, the description covers purpose, usage, parameter, and results adequately. It could specify the return format more precisely, but it is sufficient given the context and sibling tool references.

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

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

The description simply restates the parameter 'limit' with its default, which is already present in the input schema. No additional meaning is added beyond the schema's 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 it returns a batch of stalest memories for review, and explicitly contrasts with sibling tools by indicating it is read-only and only suggests actions, which distinguishes it from mindmap_promote, mindmap_update, and mindmap_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?

It explains that this tool is for the 'opt-in curation game' and instructs the agent to use mindmap_promote, mindmap_update, or mindmap_forget to act on items, providing clear when-to-use and what-to-do-next 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, destructiveHint, and idempotentHint as true/false, so the tool is safe. The description adds context beyond annotations: it clarifies that the data is read 'live from its source transcript' and that the tool returns a notice when unavailable. 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 concise with three well-structured sentences. It front-loads the main purpose, then provides usage constraints, and finally specifies arguments and returns. Every sentence adds value without redundancy, making it efficient for an AI agent.

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

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

Given the tool's simplicity (single parameter, no output schema, annotations present), the description covers purpose, usage, limitations, and return behavior sufficiently. The only gap is that the format of 'turns' is not elaborated, but it's acceptable for a tool of this 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% with one parameter 'id' described as 'Thread id'. The description adds meaning by explaining that the return is 'the full discussion as turns, or why it's unavailable', providing clarity on what to expect from the output, which the schema does not cover.

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 ('Reconstruct and return') and clearly identifies the resource ('FULL original conversation for a memory'). It distinguishes itself from the summary by stating the summary is the distilled gist while this provides complete discussion, and it mentions the source limitation, which aids differentiation from 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 explicitly states when to use this tool ('when you need the detail') and when not to use it ('Only available for transcript-backed sources...'). It explains the limitation for non-transcript sources. However, it does not mention an alternative tool for those cases, so it lacks full 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 provide no safety flags (readOnlyHint=false, destructiveHint=false). The description adds value by explaining mutation behavior: partial updates and append mode. It does not contradict annotations and is consistent with a write 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 concise at four sentences, front-loads the purpose, and avoids redundancy. 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?

For a tool with 6 parameters (1 required) and no output schema, the description covers expected behavior, return value, and append mode. It omits mention of required id but the schema covers that. Overall 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 description coverage is 100%, but the description adds beyond the schema by explaining the effect of omitting fields and the append parameter. The inline argument list also aids clarity.

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: 'Edit a memory — the human curation moment. Trim a stale summary, refine key points, retitle, or retag.' This is a specific verb-resource combination and differentiates from siblings like mindmap_forget (delete) and mindmap_get (read).

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 usage context such as 'Any omitted field is left unchanged' and 'Set append=true to append instead of replacing.' However, it does not explicitly state when not to use this tool or mention alternative siblings for similar tasks.

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