XMemo

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting optional grouping and the counting semantics, going beyond the annotations without contradicting them.

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

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

The description is a single, well-structured sentence that front-loads the action, resource, and key optional feature. 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 moderate parameter count, the presence of an output schema, and full schema coverage, the description provides sufficient context. It explains the core action, optional grouping, and trigger phrase. Slight gap: doesn't mention the 'visible memories' scope detailed 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?

The input schema covers all 7 parameters with detailed descriptions (100% coverage). The tool description adds minimal extra meaning, simply reinforcing the purpose of phrase and grouping. 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?

The description clearly states the tool counts a word or phrase across XMemo memories, with optional grouping. It distinguishes itself from sibling search/recall tools by emphasizing frequency counting.

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 specifies when to use it: 'when the user asks how often a given word or topic appears.' It doesn't explicitly name alternatives, but the context is clear and excludes retrieval 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds the behavioral context of explaining memory rationale, but does not disclose additional traits such as output format or limitations; the output schema covers return structure. This is adequate given the strong 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 a single, front-loaded sentence that clearly states the action and condition. There is no redundancy or filler, making it highly concise and 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?

The tool is simple with robust annotations and an output schema. The description covers purpose and usage, the schema covers parameters, and the annotations cover safety. A minor gap is the lack of an explicit prerequisite that memory_id must come from a prior search/recall, but the schema property description already states that, so the overall context is 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?

Both parameters (memory_id and query) have descriptive schema entries providing full coverage at 100%. The tool description does not add extra parameter-level detail, so the 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's function with a specific verb ('Explains') and resource ('why a memory exists or matched a query'). It distinguishes itself from sibling search/recall tools by focusing on the reasoning behind memory behavior rather than listing or retrieving 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?

The description gives an explicit usage condition: 'whenever the user asks why something was saved there or why it was retrieved.' This clearly signals when to invoke, though it does not explicitly name alternative tools or exclusions, which would have made it 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 the annotations (readOnlyHint=false, destructiveHint=true), the description discloses important behavioral details: it defaults to a recoverable soft delete, mentions restore_memory as a recovery path, and warns that hard delete is permanent and unrecoverable, requiring explicit user confirmation. This adds significant value and aligns with the destructiveHint.

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 paragraph, dense but not bloated. Every sentence contributes value: the action, the target types, the default behavior, the hard-delete caution, and the usage rule. It could be slightly more scannable with a list, but it remains efficient for the complexity involved.

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 destructive nature and multiple targets/modes, the description covers all essential aspects: what it deletes, how targets are specified, the soft/hard mode distinction, recovery via restore_memory, and the prerequisite of explicit user confirmation for permanent deletion. Combined with the detailed schema and annotations, it is complete for an AI agent to select and invoke correctly.

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

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

The input schema already provides 100% description coverage for all 4 parameters. The description adds context by explaining valid target formats (exact memory ID, TODO ID from current listing, Ledger transaction ID) and clarifying the mode aliases (soft/soft_delete, hard/hard_delete). It enriches rather than merely repeats the schema, though the schema already does a good job.

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: 'Delete one memory, TODO, or Ledger transaction by natural target'. It specifies the verb (delete) and the resources (memory, TODO, Ledger transaction), and distinguishes itself from sibling tools like restore_memory and update_memory by focusing on deletion.

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 the tool: 'Call this only when the user explicitly asks to delete a specific memory, TODO, or expense/income record'. It also provides guidance for ambiguous targets ('list/search or check activity first') and warns against using hard delete without explicit confirmation. This is clear and actionable 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral detail that the tool reports both connection status and the currently connected account/agent, which goes beyond the annotations and helps predict the tool's response. No contradictions exist.

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

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

The description is a single, well-structured sentence with no unnecessary words. It front-loads the core action ('Checks XMemo connection status') and then provides the usage trigger, making it easy to scan and understand.

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, output schema provided, annotations covering safety), the description adequately covers the purpose, trigger, and expected output. The output schema presumably details return values, so no further description is needed. The description is fully sufficient for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, and schema description coverage is trivially 100%. Even without parameters to document, the description adds meaning by clarifying what the tool checks and what information it exposes, meeting the baseline for parameterless 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 uses a specific verb 'Checks' to state the action on the XMemo connection, and clearly identifies the resource ('connection status') and the additional output ('currently connected account/agent'). This distinguishes it from all sibling tools, none of which handle connection checking, making the purpose immediately clear.

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

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

The description provides explicit usage context by stating 'when the user asks whether XMemo is connected.' This gives a clear trigger for invocation. It does not explicitly mention alternatives or when-not-to-use scenarios, but no sibling tool offers a similar connection check, so the absence of exclusions is acceptable.

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, idempotentHint, destructiveHint), the description adds behavior: it returns concise text, never a raw context pack or workspace resource, and when no exact project is established it says so and guides the user. This provides useful context without contradicting 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 sentences, each serving a distinct function: purpose, usage examples, exclusion/alternative, and fallback behavior. No redundancy, properly 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 read-only summary tool with two optional parameters, the description covers purpose, usage, scope constraint, failure mode, and output type. Output schema and annotations handle the rest, making this 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%, with both parameters (focus and project_id) fully described. The description reinforces the single-project scope but adds no new parameter-level semantics, so the 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 the tool's purpose: returning a bounded quick-answer summary for a single exact project as concise text. It distinguishes from siblings by explicitly naming the alternative for workspace management (open_project_workspace).

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

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

The description gives explicit usage scenarios ('brief status, blockers, progress, or next-action questions') and explicitly says not to use it for opening/browsing/managing the workspace, naming the alternative. It also instructs how to handle ambiguous project references.

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 and readOnlyHint=false, so the agent understands the mutation potential. The description adds the useful context that reminders are not XMemo plans, preventing a common confusion. However, it doesn't disclose other behavioral traits like permission requirements or side effects, so the description only partially supplements 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?

The description is three succinct sentences: a clear purpose, an example, and action-specific prerequisite guidance. It's front-loaded with the core purpose and contains no filler. 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?

With 54 parameters and 8 actions, the description covers only add_expense and subscription_create in any detail. The other actions (list, summary, update_transaction, subscription_edit, subscription_transition) are merely listed with no explanation. Sibling tools like ledger_update_transaction and ledger_get_subscriptions exist for similar purposes, but no guidance distinguishes this tool from them. An output schema exists, so return values aren't required, but the operational scope is underexplained.

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 baseline is 3. The description adds meaningful semantics beyond the schema by naming the required parameters for subscription_create (owner_timezone, service_name, expected_amount, currency, cadence, next_charge_on), which are otherwise generic 'Input value' in the schema. This targeted clarification earns a 4.

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

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

The description clearly states the tool manages ledger transactions and renewal reminders for external services, with a specific example for add_expense. It lists the supported actions, providing a clear multi-action resource scope. However, it doesn't explicitly distinguish itself from sibling tools like ledger_update_transaction or ledger_get_subscriptions, so it's not a perfect 5.

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

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

The description gives explicit when-to-use guidance for add_expense with an example ('I paid 199 CNY...') and the prerequisite fields for subscription_create. It also clarifies that reminders are not XMemo plans. However, it lacks exclusions or alternatives for the other actions or sibling tools, so it's just short of 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds minimal behavioral context ('refresh, filter, cursor') but does not disclose return format, pagination behavior, or any side effects. It does not contradict annotations, but it also provides little value 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?

While the description is short, it is under-specified and grammatically awkward. It lacks a clear subject-verb-object structure and reads more like a label than a helpful explanation. It is not 'concise' in the sense of efficiently conveying meaning.

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 14 parameters and no output schema, the description should explain what the dashboard page returns, how the cursor works, and what 'refresh' or 'filter' means in practice. None of that is present. The description is far too sparse 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 description coverage is 100%, so the schema already documents all 14 parameters thoroughly. The description does not add any parameter-specific meaning, but the baseline of 3 applies because the schema carries the full burden.

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 is a cryptic noun phrase ('Widget-only authorized Ledger refresh, filter, or cursor page') rather than a clear verb+resource statement. It does not explicitly say what the tool retrieves or does, and it fails to differentiate from sibling tools like ledger_get_subscriptions or ledger_update_transaction.

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

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

No guidance is given on when to use this tool versus alternatives such as 'ledger' or 'open_ledger'. The term 'Widget-only' hints at a restriction but is never explained as a usage condition or compared to 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'refresh, filter, or cursor page,' indicating pagination and filtering actions, plus 'authorized' access context. However, it does not describe output format or pagination behavior; with annotations covering safety, this is acceptable but thin.

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 fragment, but it is under-specified rather than efficiently informative. It trades necessary clarity for brevity, making it not appropriately sized for a 13-parameter tool.

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

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

For a complex tool with 13 parameters and no output schema, the description is inadequate. It omits expected return values, how filters work, and any prerequisites, leaving the agent to guess from 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 documents all 13 parameters. The description itself adds no parameter-level meaning, so the 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 reads 'Widget-only authorized subscription refresh, filter, or cursor page,' which mixes verbs and nouns without clearly stating that the tool retrieves or lists subscriptions. It does not distinguish the tool from sibling tools like ledger_get_dashboard or ledger_subscription_mutate.

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

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

No guidance is given on when to use this tool versus alternatives such as ledger_subscription_mutate. The phrase 'Widget-only authorized' hints at context but does not state exclusions or preferred scenarios.

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=false and destructiveHint=false. The description adds only 'one authorized subscription' and 'action selects the operation' – minimal extra behavior. It does not disclose effects, required authorization, or lifecycle specifics beyond generic create/edit/lifecycle.

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 18-word sentence that is front-loaded and wastes no words. However, for a 30-parameter tool, it is so terse that it sacrifices useful detail despite good conciseness.

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?

This is a complex mutation tool with 30 parameters, no output schema, and minimal annotations. The description provides no information about operation-specific required fields, versioning/conflicts, side effects, or return values. It is wholly inadequate for an agent to know how to correctly invoke it.

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%, and the description adds meaning to the critical 'action' parameter by noting it selects the operation. However, most schema descriptions are generic placeholder text ('Input value for...'), so the tool-level description does little to clarify the many parameters.

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 the tool 'create[s], edit[s], or lifecycle action for one authorized subscription', which clearly identifies both the action type and resource. It distinguishes from sibling read tools like ledger_get_subscriptions by implying a mutation operation, though it doesn't explicitly differentiate from ledger_update_transaction.

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 phrase 'Widget-only' hints at intended contexts, but there is no when-to-use guidance, no mention of alternatives, and no exclusions. It does not tell the agent when to choose this over ledger_get_subscriptions or ledger_update_transaction.

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?

It discloses a key side effect: 'The source Memory and Ledger projection are updated together,' which goes beyond the annotations. It also clarifies what the tool does not do (deletion). Annotations have readOnlyHint=false and destructiveHint=false, which are consistent with an update operation, so there is 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?

The description is only two sentences, with the first sentence front-loading the core purpose and the second covering side effects and exclusions. Every word contributes meaningful information, with no redundancy or filler.

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

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

The description covers purpose, side effects, and a limitation (no deletion). However, since there is no output schema, it does not mention what the tool returns or whether confirmation is provided after a successful update. For a mutation tool with 12 parameters, a brief note on expected output would improve completeness.

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

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

Schema coverage is 100%, and every parameter already has a description. The description adds value by mapping the editable fields ('category, authorized project, note, date, currency, or payment method') to the parameter names, but it does not add syntax, format, or additional constraints beyond what the schema provides. 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?

The description states 'Widget-only edit of category, authorized project, note, date, currency, or payment method,' providing a specific verb (edit), resource (ledger transaction), and the exact fields involved. This clearly distinguishes it from sibling tools like ledger_get_dashboard or ledger_subscription_mutate.

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

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

The description implies use for updating the listed fields and explicitly states 'Deletion remains in Chat and requires explicit confirmation,' which is a useful when-not-to-use exclusion. However, it does not name any alternative sibling tools for other operations, so guidance is somewhat implicit rather than 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations by explaining what each section produces (e.g., 'counts/breakdowns' and 'recent writes, deletions, restorations'), and that calling with no arguments returns a general overview.

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 tightly written sentences. The first sentence states the overall purpose, and the second provides actionable guidance on how to invoke it with different sections. Every word earns its place.

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

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

Given the tool has an output schema, rich parameter descriptions, and strong annotations, the description only needs to add usage context. It does this well by covering the no-argument default use case and all meaningful section variants. No critical usage information is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics beyond the schema. It clarifies the vague schema description for 'section' by explaining that stats gives counts/breakdowns and activity gives recent writes/deletions/restorations/TODO/timeline events. This helps the agent map user intent to the right parameter values.

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 ('Show') and clearly identifies the resource ('XMemo memories') plus the three possible outputs: a summary, aggregate stats, or recent activity. It also distinguishes itself from sibling search/recall tools by explicitly covering the 'without a specific query' use case.

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

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

The description gives explicit when-to-use guidance: 'Call this with no arguments when the user asks what XMemo remembers without a specific query.' It also explains when to use section='stats' and section='activity'. It does not directly name alternative tools for specific queries, but the guidance is clear enough to imply them.

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=true, idempotentHint=true), the description adds valuable behavioral context: view=subscriptions is a compatibility value and does not imply an XMemo plan, owner_timezone must be the user's real IANA timezone and never guessed UTC, and existing transactions can be edited inside the widget while deletion stays in Chat requiring confirmation. These details clarify agent expectations without contradicting 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?

The description is compact yet information-dense, front-loading the primary purpose and then covering usage, disambiguation, and behavioral caveats. Every sentence serves a distinct disambiguation or instruction purpose, with no filler or repetition of schema fields beyond critical clarifications.

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 (10 parameters, many sibling tools, rich schema), the description is complete: it covers purpose, use cases, alternatives, special parameter semantics, timezone rules, and widget interaction behaviors. The output schema exists, so return value details are not needed. No significant 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% with detailed parameter descriptions, so the baseline is 3. The description adds extra semantic clarity for view (clarifying subscription compatibility and XMemo warning) and owner_timezone (reinforcing real IANA timezone), which pushes it above baseline. However, most parameter meanings are already well-documented in 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 opens the interactive Ledger for Net flow or Renewal reminders, with a specific verb and resource. It proactively distinguishes itself from a non-existent open_subscriptions tool and differentiates from sibling ledger tools by clarifying it is the entry point for opening/browsing the Ledger.

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 when to use this tool ('when the user asks to open, browse, explore, or work with Ledger') and names alternatives: ledger(action='summary') for quick totals, ledger(action='list') for transaction rows/search, and ledger(action='add_expense') for recording. Also warns against inventing a separate open_subscriptions tool, providing clear when-not-to-use guidance.

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

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

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description reveals resolution rules: no reference always opens Home even with one accessible project, exact matches open the eight tabs, multiple/no matches return Home with candidates or no-match state, and legacy ledger values open Overview. This is valuable behavioral context not available in 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 dense yet well-structured: it opens with the core action, then sequentially covers parameter resolution, tab enumeration, edge cases, and sibling differentiation. Every sentence contributes meaningful information, with no filler 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 tool's complexity (4 parameters, 8 tabs, multiple edge cases), the description is fully complete: it covers no-reference behavior, match resolution outcomes, tab list, legacy handling, and alternative tools. The presence of an output schema reduces the need to describe return values, and annotations cover safety, so the description fills all remaining 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%, so the baseline is 3, but the description adds important meaning: it explains project resolution logic (exact project_id vs. unique name/alias), outcome on multiple/no matches, and the initial_tab legacy behavior. This enriches the schema parameter descriptions with practical consequences.

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 'Open' with the resource 'Project Workspace' and lists the eight tabs, clearly distinguishing it from siblings like get_project_summary, open_todo_board, and open_ledger. It states exactly what the tool does: opens Home or a specific project's workspace.

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 given for when to use alternatives: 'For a quick text-only status, blockers, or next-actions answer use get_project_summary. Explicit standalone TODO or Ledger intent keeps using open_todo_board or open_ledger.' The description also clarifies behavior with no project reference, making the usage context unambiguous.

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, and the description adds the important behavioral constraint: 'The owner_timezone input must be the user's real IANA timezone; never guess UTC.' It also clarifies that mutations are handled elsewhere, avoiding the possibility of the 'manage tasks' phrase suggesting write actions. 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 somewhat long but every sentence contributes: purpose, critical timezone note, use cases, and alternatives. It is front-loaded with the main purpose and structured clearly, though slightly wordy.

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 and thorough annotations, the description adequately covers when to use it, key behavioral constraints, and how it differs from siblings. It could mention pagination behavior but that is not necessary for a board-opening tool with 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 description coverage is 100%, so each parameter is already documented. The description repeats the owner_timezone requirement but adds no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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 a specific verb+resource: 'Open the interactive TODO Board workspace to view, browse, and manage tasks.' It clearly distinguishes from sibling tools by explaining that this is for visual/browse workflows while todo(action='list') is for quick text answers.

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 guidance is provided: 'Use this when the user wants to open, browse, filter, or work with their TODOs visually' with examples, and explicit alternatives: 'For a quick text-only answer..., use todo(action='list') instead' and 'Create, update, or complete TODOs with todo(action='create'|'update'|'complete')' and deletion via 'forget'. This leaves no ambiguity about when to choose 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?

With annotations already declaring readOnlyHint=false and destructiveHint=true, the description reinforces and expands on behavioral traits. It reveals important details such as optimistic concurrency via 'expected_version' and 'conflicts rejected', the distinction between memory_ref and memory_id, and the link-only nature of resource_type. These are useful behavioral disclosures 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?

The description is a single dense paragraph, but it is front-loaded with the main purpose. It efficiently packs action-specific requirements into a compact form. Slightly run-on but each clause adds necessary nuance, and it avoids redundancies.

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 36 parameters and multiple oneOf branches, the description covers the most critical branches (project, memory, decision, document, conversation) but omits settings mutation and memory review due. It also includes guidance on read alternatives and mentions general edit/unlink requirements. Missing a couple of branches keeps it from being fully complete, but given the schema covers them, the shortfall is minor.

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?

Although the schema descriptions cover 100% of parameters, the description adds valuable semantic clarifications: 'memory_ref (never memory_id)' prevents a common mistake, 'resource_type is link-only' clarifies a restricted value, and 'use top-level content/tags or patch.content/patch.tags, with conflicts rejected' explains the patch structure and validation. This 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?

The description clearly states the tool's purpose: 'Create or mutate an authorized project' and distinguishes it from read-only siblings by explicitly directing users to open_project_workspace or get_project_summary for reading. It outlines the specific entities and actions handled, making the tool's scope unambiguous.

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

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

The description explicitly says when not to use the tool (for reading) and names two alternative tools. It also provides conditional usage rules for each entity/action, such as project create requiring name and omitting project_id, memory update requiring memory_ref and expected_version, and decision create requiring context. This gives clear when-to-use 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=false, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds context about widget-only access and project-locking, but does not disclose any side effects or dependency on required parameters like mount_capability.

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

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

The description is a single concise sentence that packs the core purpose and operation-selection mechanism. No redundant or filler content.

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?

This is a complex mutation tool with 13 parameters, an action selector, and no output schema. The description is too terse to convey the full behavioral context, such as what each action does, prerequisites, or return values. It leaves too much to be inferred from parameter names.

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% coverage with descriptions for every parameter, meeting the high-coverage baseline. However, many parameter descriptions are generic boilerplate ('Input value for...'), and the tool description itself provides no parameter semantics. Still, the schema covers the essential details for action, expected_version, and client_mutation_id.

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

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

The description names specific operations (link, edit, availability, unlink) on a project-locked conversation, clearly distinguishing it from sibling mutate tools for documents, todos, and decisions. The phrase 'action selects the operation' further clarifies the polymorphic behavior.

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

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

The description provides context ('Widget-only', 'project-locked conversation') but no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. Sibling tools exist for related mutations, but no comparison or selection logic is offered.

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 (non-read-only, non-destructive, idempotent), the description adds behavioral context: the tool is widget-only, handles one project-locked decision, and action selects the operation. It does not detail side effects of superseding or required permissions, but it adds meaningful context.

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

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

The description is a single concise sentence containing the tool's purpose, supported operations, and a key constraint. Every word contributes value; there is no redundancy or filler.

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

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

This tool has 12 parameters, multiple operations, and no output schema, yet the description is only one sentence. It does not explain which parameters apply to each action, the practical meaning of 'widget-only', or the outcome of operations like supersede. This is insufficient for reliable 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?

Schema description coverage is 100%, so the baseline is 3. The tool description adds some meaning for the action parameter ('action selects the operation'), but most other parameters (title, options, decision, rationale, resolution, etc.) have only generic schema descriptions and receive no clarification in the tool 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 identifies a mutation tool for project-locked decisions, listing specific operations (create, resolve, reopen, supersede) and noting that the action parameter selects the operation. This distinguishes it from sibling mutate tools such as conversation, document, and todo.

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

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

The description gives a usage context ('widget-only') and implies it is for project decisions, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternative tool names 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 provide idempotentHint=true and destructiveHint=false, but the description adds little beyond listing the actions. It fails to disclose side effects of each action, permission requirements, or what 'unlink' implies. The description does not contradict annotations, but it also does not enrich 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 a single, dense sentence that conveys the core concept without wasted words. It is front-loaded with action types and resource scope. The phrase 'Widget-only' is opaque and unexplained, but the structure is efficient and appropriately sized for its content.

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?

This is a 14-parameter mutation tool with no output schema, yet the description is extremely brief. It does not explain the actions, which parameters apply to each action, or any domain context needed for correct invocation. The description is severely under-specified for an agent to use reliably.

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 baseline is 3. However, most parameter descriptions are generic placeholders ('Input value for...') and the tool description does not clarify any parameters. The schema's descriptions of expected_version and client_mutation_id are helpful, but that is schema information, not tool description 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?

The description identifies the resource (a project-locked document) and the action types (link, edit, availability, unlink), and notes that the 'action' parameter selects the operation. This distinguishes it from sibling mutate tools focused on conversations, decisions, or todos. However, it does not explain what each action actually entails, so it falls short of a perfect score.

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 offers no guidance on when to use this tool versus alternatives like project_workspace_todo_mutate or project_workspace_decision_mutate. It lacks any context about prerequisites or the intended workflow. The only hint is 'Widget-only,' which is vague and not elaborated.

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 and idempotentHint, and the description adds useful context about widget-only authorization and the supported modes (switch, refresh, cursor page, home re-read). It does not conflict 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 a single sentence, concise and front-loaded, but the word order is slightly cryptic. It contains no filler, though it could be clearer.

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 9 parameters and no output schema, the description does not sufficiently explain what the tool returns, how pagination works, or the full scope of a 'tab page'. It is too terse given the tool's complexity.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The tool description adds no additional parameter semantics, which is acceptable given the high schema 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 states the tool is for reading a Project Workspace tab with actions like tab switch, refresh, cursor page, or home re-read. It clearly identifies the resource (Project Workspace tab) and distinguishes it from sibling mutate tools. However, the phrase 'Widget-only authorized' is vague and could confuse.

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 viewing a specific workspace tab and mentions pagination and home re-read, but it does not explicitly state when to use this tool over alternatives or any exclusions. No alternative tools are referenced.

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

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

With annotations already covering idempotency and destructive intent, the description adds useful behavioral constraints: 'widget-only' and 'one project-locked memory', plus the clearing behavior when empty. It does not contradict annotations and provides value 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 a single, well-structured sentence that front-loads the main purpose and includes the key edge case (empty clears) without 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 rich schema and annotations, the description is sufficient for a simple mutation. It explains the core function and the clearing behavior, while the schema covers parameters and error conditions (e.g., VERSION_CONFLICT). It leaves out no critical information, though it could theoretically mention return 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?

Schema description coverage is 100%, so the baseline is 3. The description's 'empty clears it' is helpful but redundant with the schema's review_due_at description. It does not add new parameter semantics beyond what the schema already documents.

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 a specific verb ('update'), a specific resource ('one project-locked memory's review-due date'), and a key behavior ('empty clears it'). It clearly distinguishes this from sibling tools like update_memory by noting it is 'widget-only' and limited to one memory.

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

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

The description provides clear context: it is widget-only, applies to a single project-locked memory, and updates only the review-due date. It implies this is a specialized tool for a specific UI context, but it does not explicitly name alternatives or provide exclusion 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?

Annotations already signal readOnly=false, destructive=false, idempotent=true; the description adds meaningful behavioral details of optimistic concurrency (version check) and clientMutationId replay protection, plus the project-locked constraint. This supplements rather than contradicts 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?

Two sentences, front-loaded with the verb and target; every clause adds information (scope, concurrency, replay protection, deletion exclusion). No fluff.

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

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

Given the rich schema covering all 7 parameters and the annotations, the description covers the key behavioral context: widget-only scope, mutable fields, concurrency, idempotency, and deletion exclusion. It does not describe the response shape, but without an output schema that is a minor gap for a mutation tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds cross-cutting meaning by linking 'content or tags' to the two mutable fields and by naming the concurrency and replay-protection mechanisms that correspond to `expected_version` and `client_mutation_id`.

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

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

The description names the exact operation ('edit'), the target resource ('one project-locked memory's content or tags'), and distinguishes it from deletion and other memory tools by calling out 'Widget-only' and 'Deletion stays in Chat.' This is specific enough to differentiate from siblings like `update_memory` 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?

It communicates clear context: this is the widget-based edit path, and deletion is explicitly out of scope ('Deletion stays in Chat'). It stops short of naming alternative tools for other cases, but the exclusion is useful.

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 idempotence (idempotentHint=true) and non-read-only, but the description adds concurrency control via expected_version (VERSION_CONFLICT on stale values), idempotent replay via client_mutation_id, and the host-private mount_capability. These are meaningful behavioral details beyond the annotation flags.

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 and front-loads the action and resource, then adds constraints. Every clause adds information 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?

The description is adequate for a save operation with 8 parameters and no output schema. It explains the purpose, the concurrency/idempotency mechanisms, and what is out of scope. It could mention success response or side effects, but the client_mutation_id schema description already covers replay 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?

All parameters have schema descriptions, but most are generic ('Input value for the Project Workspace Settings Save Preferences tool') and add little. The tool description compensates by explaining the role of expected_version, client_mutation_id, and mount_capability, and lists the preference fields. Since the description goes beyond the schema for the meaningful parameters, a 4 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 states 'Widget-only save of the caller's per-user Workspace preferences' with a specific verb and resource, and enumerates the preference fields. It also distinguishes from sibling tools by explicitly stating what it does not do ('Project Profile, lifecycle, retention, and visibility writes do not exist here').

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

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

The description gives clear context: it is for saving Workspace preferences in a widget context, and explicitly excludes other write types. However, it does not name an alternative tool or provide a direct when-to-use comparison with siblings, so slightly less than 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?

The description adds the 'widget-only' and 'locked project scope' constraints, but other behavioral details (write operation, idempotency) are already covered by annotations. It does not mention side effects, concurrency checks, or error conditions beyond what the schema notes for expected_version.

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, front-loaded sentence that conveys the core operation without unnecessary 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?

While the schema covers parameter details, the description does not explain how the three actions differ in terms of required parameters or expected behavior. It lacks guidance on parameters like expected_version, client_mutation_id, or todo_id usage per action, making it incomplete for a complex 3-operation mutation tool.

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

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

The description clarifies the action parameter by enumerating 'create'|'update'|'complete', which the schema leaves vague. It also implies that content and todo_id are used depending on action, but it doesn't map each parameter to actions explicitly. Since the schema already describes all parameters, this added clarification is useful.

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

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

The description clearly states the tool creates, edits, or completes one TODO within a locked project scope, using the action parameter. This specific verb-resource pairing distinguishes it from sibling mutation tools like project_workspace_document_mutate.

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 phrase 'Widget-only' provides clear context for when this tool should be used, and 'locked project scope' indicates a constrained environment. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full usage guide.

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 cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds behavioral context by describing the operation as 'lightweight' and 'unscoped', and noting it retrieves 'few most relevant' memories. No contradiction with annotations, and the added context is useful beyond the structured metadata.

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, front-loaded with the core purpose followed by alternates. Every word earns its place; no filler 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?

For a simple read-only lookup with complete annotations, full schema coverage, and an output schema present, the description supplies purpose, usage context, and sibling differentiation. It provides sufficient information for an agent to decide when to 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?

The input schema already provides full descriptions for both parameters (query and limit), achieving 100% coverage. The description's phrase 'few most relevant' reinforces the limit behavior but doesn't add substantive meaning beyond the schema's own documentation, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as a recall operation for saved memories, specifying it returns 'the few most relevant saved memories.' It distinguishes itself from siblings by explicitly calling it a 'lightweight, unscoped lookup' and naming alternatives, making the purpose unmistakable.

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 when-to-use guidance ('lightweight, unscoped lookup') and direct alternatives: 'use search_memory for a scoped lookup, or recall_context for a multi-item context pack.' This gives the agent clear decision criteria and exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context by emphasizing the output is 'bounded' and composed from 'multiple relevant memories', which goes beyond the annotation flags. 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, front-loaded with the primary purpose and then usage guidance. Every word earns its place, no fluff 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 an output schema present, the description need not explain return values. It provides clear purpose, usage, and boundaries for the tool's complexity (3 simple params). Complete for agent 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description only lightly references max_items and max_tokens as bounds, and mentions query as the ranking mechanism. This adds marginal value beyond the schema, consistent with the baseline for full 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 builds a 'read-only, bounded context pack' from 'multiple relevant memories', using a specific verb and resource. It explicitly distinguishes itself from siblings by mentioning 'multiple relevant memories' and bounded output, and names alternatives.

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

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

The description gives explicit when-to-use guidance: 'Use it when an answer needs several memory items within max_items and max_tokens'. It also names specific alternatives with their use cases: 'use recall for a quick forgiving lookup or search_memory for strict targeted matching'.

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?

Discloses that existing Projects paths attach automatically, which is not evident from annotations. Also flags create_project as deprecated compatibility input and clarifies proper routing. Annotations already establish read/write and destructiveness hints, so the description adds qualitative behavior beyond those.

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 sentence states purpose, second adds a behavioral detail, third contains two routing caveats. No redundant fluff; all information is actionable.

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

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

Given the output schema exists and annotations provide safety hints, the description effectively covers purpose, exclusions, parameter nuances, and routing alternatives. It is sufficient for an agent to decide when to invoke and how 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 covers 100%, but description adds meaning to create_project by labeling it 'deprecated ordinary-client compatibility input' and directing to project tool. Also notes automatic attachment for Projects paths, which clarifies the path parameter's behavior.

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

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

The opening phrase 'Save durable information for future recall' clearly identifies the tool's function. It distinguishes itself from transient chat and from Ledger for financial records, and mentions project creation routing, separating it from the project tool.

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 instructs to skip transient chat, provides an alternative for financial records (Ledger), and clarifies that project creation should be routed to project(entity='project', action='create') rather than using create_project. This goes beyond merely implying usage.

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

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

The description adds a key behavioral constraint ('previously deleted memory') and clarifies the intent ('undo a deletion'), which goes beyond the sparse annotations. However, it does not disclose potential error conditions, whether the operation is reversible, or what happens if the memory is already restored. With no meaningful annotations, the description carries the burden but remains thin on side effects.

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

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

The description is two sentences: the first states the action, the second provides a usage condition. It is front-loaded, contains no redundant information, and every word earns its place. This is a model of concise, well-structured documentation.

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

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

For a simple tool with a clear schema and output schema available, the description is largely sufficient. It explains the precondition and the exact trigger for use. It falls slightly short by not mentioning error scenarios or edge cases, but given the low complexity, this is a minor gap rather than a critical omission.

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 100% coverage with descriptions for both parameters: 'reason' and 'memory_id'. The description does not add any parameter-specific information, so it neither enhances nor detracts from the schema. Baseline of 3 is appropriate given the schema already fully documents the parameters.

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: 'Restore a previously deleted memory.' It specifies the resource (memory) and the action (restore), and distinguishes itself from siblings like 'forget' (deletion) and 'recall'/'search_memory' (retrieval). The title reinforces this but the description adds the 'previously deleted' qualifier, making the scope explicit.

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 second sentence provides explicit guidance: 'Call this only when the user explicitly asks to restore or undo a deletion.' This directly tells the agent when to use the tool, and the 'only when' phrase acts as an exclusion for all other scenarios. It effectively communicates the when and when-not, leaving no ambiguity about alternative 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds the key behavioral trait of strong-match semantics, meaning weak matches are excluded. It clarifies the tool's precision-oriented nature, which is not captured by annotations or schema.

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, with the main purpose in the first sentence and succinct alternatives in the rest. Every sentence adds value and there is no filler 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 tool's simplicity (2 parameters), strong annotations, and existing output schema, the description covers all necessary context: what it does, when to use it, how it differs from alternatives, and a pointer to deletion. It is complete for an agent to invoke correctly.

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

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

The input schema already provides descriptions for both parameters (query and limit) with 100% coverage, so the baseline is 3. The description does not add additional parameter semantics beyond the schema, so no extra credit is given.

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 XMemo memories with strong-match semantics, defining a specific verb, resource, and behavior. It distinguishes itself from sibling tools recall and recall_context by explicitly contrasting their match semantics.

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: use this for targeted lookups where weak matches must not be returned, use recall for best-effort retrieval, and recall_context for multi-memory context packs. It even mentions forget for deletion, covering alternatives comprehensively.

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 context beyond annotations: 'bulk soft-delete' and 'recoverable' clarify the destructiveHint=true annotation, and the confirmation requirement is a critical safety trait. It also clarifies that single deletion should go through 'forget', preventing misuse.

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 concise sentences, each earning its place: the operation list, the delete_all safety caveat, and the single-delete bypass. No redundant content; front-loaded with the primary verbs.

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

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

The description covers the operational scope and the two dangerous edge cases (delete_all and single-delete routing). Given the output schema and full parameter documentation, it is sufficiently complete, though it could benefit from a note on how this tool relates to project_workspace_todo_mutate. Overall, it's above average for a multi-action 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?

All 22 parameters have schema descriptions (100% coverage), so the baseline is 3. The description reinforces confirm_delete_all=true but does not add semantic detail beyond the schema. It doesn't explain any parameter relationships beyond what the schema constraints already convey.

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 defines the tool as managing authorized TODOs with five specific operations (create, update, complete, list, bulk soft-delete). It distinguishes itself from the sibling 'forget' by directing single deletions there. The verb+resource+scope is explicit.

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 provides explicit usage guidance for delete_all, requiring user confirmation and confirm_delete_all=true, and names 'forget' as the alternative for single deletions. It doesn't address overlap with project_workspace_todo_mutate, but the key when-to-use/not-use cases are covered.

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 and readOnlyHint=false, setting the safety baseline. The description adds useful context about the need for an exact reference and the updatable aspects, but it does not explain side effects like partial vs. full replacement, handling of non-existent IDs, or whether all optional fields default behavior. Thus it adds some value beyond annotations but not extensive.

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: two sentences, no filler, and front-loaded with the action and resource. It covers the purpose and the key constraint (exact reference) without redundancy.

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

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

For a mutating tool with an output schema and annotations, the description is reasonably complete: it explains the trigger, the aspects updated, and the need for an exact reference. However, with many sibling tools including project_workspace_memory_update, it does not explicitly distinguish from that potentially similar tool, which could cause confusion in selection. The description is adequate but not exhaustive.

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 descriptions already cover 100% of the four parameters with detailed explanations. The description's mention of 'content, location, or type' maps to the content, path, and memory_type parameters, reinforcing the schema but not adding new semantics. The baseline for full schema coverage is 3, and no additional parameter insight is provided.

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 updates a specific saved memory, with a specific verb ('Updates') and resource ('saved memory'). It specifies the scope (content, location, or type) and the trigger (user asks to correct, revise, move, or reclassify), distinguishing it from create/delete/read siblings like 'remember', 'forget', and 'search_memory'.

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

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

The description provides clear context for when to use the tool ('when the user asks to correct, revise, move, or reclassify it') and notes that an exact reference identifies the record, implying that memory_id is required and likely obtained from prior search/recall. It does not explicitly name alternatives or exclusions, but the context is sufficient for most cases.

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