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

Annotations are minimal (readOnlyHint: false, destructiveHint: false), and the description does not disclose behaviors beyond the basic creation, such as uniqueness enforcement or 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 a single clear sentence, but it could be more informative without losing conciseness, such as noting required fields or defaults.

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 no output schema and six parameters, the description is minimal; it fails to explain return values, validation (e.g., unique name), or what happens on success.

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 high (83%), so the description adds no meaningful parameter detail beyond what the schema already provides; the 'note' parameter lacks a description, but the description does not compensate.

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 'Create a new financial account' uses a specific verb and resource, clearly distinguishing it from sibling tools like update_account or delete_account.

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

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

No explicit when-to-use or alternative guidance is provided; it is implied that this tool is for creating accounts, but no exclusions or comparisons are given.

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

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

Annotations indicate no destructive or idempotent hints; the description adds that the tool is refused on stdio (Stream D Phase 4) due to no DEK, providing useful environmental 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?

Two sentences, no wasted words. The first states the action, the second adds critical usage restriction. Highly efficient.

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

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

No output schema exists, yet the description omits mention of return values. While parameter descriptions are rich, the tool description itself lacks completeness regarding expected results or prerequisites.

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

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

Schema has 100% coverage with parameter descriptions. The tool description adds value by noting the refusal of account_ids on stdio and labeling account as legacy, which aids selection.

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 'Create a new financial goal,' providing a specific verb and resource. This effectively distinguishes it from sibling tools like update_goal and delete_goal.

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

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

The description mentions refusal on stdio and hints at HTTP MCP for multi-account, but lacks explicit guidance on when to use this tool vs. alternatives or when not to use it.

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

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

Annotations show readOnlyHint:false and destructiveHint:false, but description adds no behavioral details beyond 'Create', e.g., side effects, permissions, or uniqueness constraints. Contradicts nothing but adds minimal value.

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

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

Extremely concise at 4 words, which is efficient but slightly under-informed. It's front-loaded and to the point, but could expand to add value without becoming verbose.

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 (12 params, 6 required, no output schema), the description is incomplete. It lacks context about the loan creation process, required account, or default behaviors.

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

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

Schema has 12 parameters with only 8% having descriptions. The tool description does not compensate by explaining parameters beyond the schema, leaving most parameters opaque.

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

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

Description clearly states 'Create a new loan', specifying verb and resource. It doesn't distinguish from siblings like 'update_loan' or 'delete_loan', but those are different operations and the purpose is still clear.

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

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

No guidance on when to use this tool versus alternatives, such as prerequisites like needing an existing account. The description provides no usage context.

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

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

Annotations provide no behavioral hints besides readOnlyHint=false, so the description must carry the burden. It states it creates a holding, which implies mutation, but does not disclose idempotency (false hint), uniqueness constraints, or failure modes. Adequate but not thorough.

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

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

Two sentences, no waste. Front-loaded with the core action and a differentiating note. Every sentence serves a purpose.

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

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

With 6 parameters and no output schema, the description is minimal. It lacks return value info, error conditions, and prerequisites (e.g., account must exist). Incomplete for a create operation in a complex context.

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

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

Schema has 50% description coverage; the description adds context for 'account' and 'symbol' via examples but neglects 'note', 'currency', and 'isCrypto'. For parameters without schema descriptions, the tool description offers no additional meaning, leaving a significant gap.

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

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

Clearly states 'Create a portfolio holding' with a concrete example 'VEQT.TO' and distinguishes from the import pipeline, making its purpose distinct from siblings like update or delete portfolio holding.

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

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

Explicitly says this is for manual addition when not using CSV/ZIP imports, providing a clear when-to-use. However, it does not mention prerequisites like account existence or when not to use the tool at all (e.g., if holding already exists).

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context such as effects on existing data, required permissions, or side effects. It is minimal beyond the annotation hints.

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

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

Two short sentences front-loading the purpose and critical usage limitation. Every sentence is necessary and informative.

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?

Missing details about the return value (e.g., confirmation or snapshot ID) and does not elaborate on the snapshot date meaning despite schema pattern. For a simple recording tool, it is adequate but not fully 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% and the description adds context with examples (house value, car value) and notes about account name resolution issues. This meaningfully complements 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 verb 'record' and the resource 'net worth snapshot for an asset', with examples like house or car value. This differentiates it from siblings like get_net_worth, which retrieves net worth.

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 warns that stdio cannot resolve account names and directs to use HTTP MCP or web UI. This provides clear when-not-to-use guidance and alternatives.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false) and the description only says 'add' without detailing side effects, permissions, or impact on the transaction. The tool creates a split but does not explain what happens to the parent transaction.

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 with no wasted words, but it is too brief to be helpful. It efficiently states the core function but omits important details.

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 7 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain what a split is, how it relates to transactions, or any constraints on amounts or categories.

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

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

Schema description coverage is 0%, leaving all 7 parameters undocumented in the schema. The description adds no information about parameters, not even the required transaction_id and amount. This is insufficient for an agent to understand correct usage.

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 ('Add'), the resource ('a single split'), and the context ('to an existing transaction'). It is specific and distinguishes this tool from siblings like 'add_goal' or 'add_account'.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_splits, update_split, replace_splits, or delete_split. There is no mention of prerequisites or context.

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

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

The description only restates the action already implied by annotations (readOnlyHint=false indicates write). It does not disclose idempotency, error behaviors, or side effects such as duplicate prevention or billing schedule implications.

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

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

A single sentence that is front-loaded and contains no fluff. However, it is perhaps too terse given the number of parameters and lack of output schema.

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

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

Given 8 parameters, 4 required, no output schema, and minimal annotations, the description is insufficient. It does not explain return behavior, validation rules, or what constitutes a successful creation.

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

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

With schema description coverage at only 13%, the description should compensate but does not mention any parameter meanings. The schema provides enums for cadence and currency, but the description adds no context for required fields like name, amount, or next_billing_date.

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 'Create a new subscription' clearly identifies the action (create) and resource (subscription). It distinguishes from sibling tools like list_subscriptions, update_subscription, delete_subscription, and detect_subscriptions.

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

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

No guidance on when to use this tool versus alternatives, such as bulk_add_subscriptions or detect_subscriptions. No prerequisites or context for invocation 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 already declare readOnlyHint=true and idempotentHint=true, so the description's main behavioral contribution is the decryption limitation in stdio. This adds useful context beyond annotations. No mention of other behaviors like data freshness or rate limits, but the safety profile is clear from 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 with no wasted words. The first defines the purpose, the second provides a key usage constraint. Front-loaded and efficient.

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

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

For a tool with 3 optional parameters, no output schema, and no parameter documentation, the description lacks completeness. It omits return value details, parameter roles, and any example usage, leaving the agent underinformed despite annotations covering safety.

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

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

Schema description coverage is 0%, meaning no parameter descriptions in the input schema. The description fails to explain the three parameters (symbol, holdingId, reportingCurrency) or their roles, offering no compensation. This is a critical gap for agent invocation.

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

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

Description clearly states 'Deep-dive analysis of a single holding', identifying the tool's specific verb and resource. It distinguishes from portfolio-level tools like `get_portfolio_analysis` by focusing on a single holding, but does not explicitly contrast with other single-holding analysis tools like `trace_holding_quantity`.

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

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

The description provides a situational constraint: 'stdio cannot decrypt holding/account names — use HTTP MCP or the web UI for this query.' This guides usage for different transports but does not advise when to choose this tool over alternatives like `get_portfolio_analysis` or `get_investment_insights`.

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 (which show no special hints), the description reveals that rules with side-effect actions (set_account, create_transfer) are skipped and that skipped rules are surfaced in the response. This adds valuable behavioral context, though it doesn't disclose the mutability of the operation or whether changes are reversible.

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

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

Two sentences: the first provides the core purpose, the second adds a critical behavioral detail. No superfluous words, achieving high information density.

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 batch operation with no output schema, the description partially explains the response (skipped rules) but lacks overall return format details. It also doesn't relate to sibling categorization tools, leaving the agent to infer use cases. Adequate but not fully comprehensive.

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

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

Schema coverage is 100% (one parameter with description). The description confirms the limit's role but adds no new semantic value beyond the schema's default mention. 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 action ('apply matching rules') and the target resource ('uncategorized transactions'). It is distinct from sibling tools like 'list_rules' or 'create_rule' by specifying the operation and the precondition of uncategorized status.

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 automatically categorizing uncategorized transactions using existing rules, but it does not explicitly contrast with alternative tools like 'execute_bulk_categorize' or 'suggest_transaction_details'. No when-not-to-use guidance is provided.

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

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

Annotations already indicate readOnlyHint=false (mutation). The description adds only 'Commit' which is obvious. No details on side effects, partial failures, or prerequisites beyond the required parameters.

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

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

Single sentence that is direct and front-loaded. No unnecessary words.

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

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

For a bulk operation, the description lacks information about return values, partial success/failure handling, or validation. No output schema exists, so description should compensate.

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?

Description mentions that 'candidates' come from detect_subscriptions, adding context beyond the schema which has 0% coverage. However, it does not describe the format or constraints of each parameter in detail.

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

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

Clearly states it commits detected subscriptions, and references detect_subscriptions. However, it does not explicitly differentiate from add_subscription or list_subscriptions, which are sibling tools.

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

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

Says to pass candidates from detect_subscriptions and confirmationToken, implying a workflow. But no explicit guidance on when not to use this tool (e.g., for single subscriptions) and no mention of alternatives.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds the stdio limitation and mentions DEK and dropped columns, but lacks details on return behavior, effects, or error conditions, especially given no output 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 relatively concise with two sentences that front-load the primary purpose. It avoids unnecessary details, though the stdio limitation could be condensed without losing 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?

For a tool with 4 parameters (including a nested array), 1 required, and no output schema, the description is incomplete. It omits success/error semantics, usage of dryRun, idempotencyKey, and account_id, leaving critical gaps for the agent.

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 only 25%, and the description adds no explanation of the parameters (dryRun, account_id, transactions, idempotencyKey). The text focuses on the stdio issue instead of clarifying parameter meaning, leaving the agent underinformed.

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 'Record multiple transactions at once' which is a specific verb and resource. It distinguishes from sibling 'record_transaction' by implying bulk, though not explicitly. The stdio refusal context adds clarity.

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

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

Explicitly advises to use HTTP MCP or web UI instead of stdio, providing clear environment-based guidance. However, it does not discuss when to use this tool versus alternatives like record_transaction or other bulk 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 mark the tool as destructive, and the description adds specific behaviors: marks as cancelled and deletes the file. Consistent with annotations, adds useful context 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?

Single, well-structured sentence that front-loads the core action and consequences. No extraneous information.

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

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

For a simple tool with one parameter and clear action, the description covers the essentials. Absence of output schema or return value info is acceptable given the destructive nature.

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

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

Schema coverage is 0% and the description does not explain the sole parameter 'upload_id' beyond its type. The meaning and required format are left to the agent to infer.

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

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

Description clearly states the verb 'Cancel', the specific resource 'pending MCP upload', and the actions performed (marks cancelled, deletes file). It distinguishes from sibling tools like preview_import and execute_import.

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 pending uploads that need cancellation but does not explicitly state when to use it versus alternatives or any prerequisites. Lacks explicit when-not guidance.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds value by specifying 'triangulated FX rates', which implies internal conversion via a base currency. No contradictions with annotations.

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

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

The description is a single sentence of 12 words, front-loading the core action and resource. No unnecessary information.

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

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

Given there is no output schema and low schema coverage, the description lacks crucial details such as the return format (e.g., converted amount or object), error handling for invalid currencies, and the role of the 'date' parameter for historical rates. The annotations partially compensate for safety, but not for functional 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 description coverage is 0%, so the description must compensate, but it only vaguely references 'amount', 'from', and 'to' without explaining their semantics or constraints. The optional 'date' parameter is not mentioned at all, despite having a regex pattern 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 states the specific action ('Convert an amount') and resource ('from one currency to another'), and includes the method ('using triangulated FX rates'). It clearly distinguishes from sibling tools like 'get_fx_rate' which only retrieves rates, not conversions.

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 implicitly indicates when to use this tool (for actual amount conversion) vs sibling tools (e.g., 'get_fx_rate' for just the rate). However, it does not explicitly state when not to use it or mention alternatives.

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

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

The description simply says 'Create', which implies mutation. Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent. However, no additional behavioral details are disclosed, such as whether existing categories with the same name cause an error or if there are limits on creation.

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

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

The description is a single sentence, which is concise. However, it lacks structure and could be expanded to include important details without becoming verbose.

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 4 parameters, 2 required, and no output schema, the description is too minimal. It does not explain what happens after creation (e.g., returns the created category) or any side effects, which is needed for complete understanding.

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

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

With only 50% schema description coverage, the description adds no parameter information. It does not explain the meaning or constraints beyond what is already in the schema, such as the uniqueness requirement for name or the semantics of 'group'.

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 (create) and the resource (transaction category). It is specific enough to convey the tool's function. However, it does not highlight any unique aspects that distinguish it from sibling tools like delete_category or other creation tools.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, constraints, or situations where this tool should not be used.

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

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

Annotations indicate no readOnly, idempotent, or destructive hints. The description adds the note about assign_category being refused on stdio, but does not disclose side effects like immediate activation, permissions required, or whether existing transactions are affected. Behavioral transparency is adequate but not thorough.

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

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

The description is two concise sentences that start with the primary purpose and immediately add a critical implementation detail. No redundant information, and the structure is front-loaded.

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

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

The description covers the core purpose and a key parameter nuance, but lacks details on post-creation behavior, wildcard usage in match_payee, or how to confirm rule activation. Given no output schema and six parameters, it is somewhat incomplete.

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

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

With 67% schema coverage, the description adds value by clarifying the relationship between assign_category and assign_category_id, and the default value for priority. This goes beyond the schema, making parameter usage clearer.

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

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

The description clearly states the verb 'Create' and the resource 'auto-categorization rule' with the scope 'for future imports'. It distinguishes this tool from siblings like update_rule, delete_rule, and test_rule by specifying the action and timing.

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

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

The description provides explicit guidance on when to use assign_category_id over assign_category, especially for Stream D Phase 4. However, it does not contrast with other rule-related tools beyond that, missing opportunities to exclude alternatives like update_rule.

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: it explains the conditional deletion (only if no transactions unless force=true) and the stdio protocol restriction. This aligns with the destructiveHint=true and idempotentHint=true 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 core action, and every word adds value. No redundancy or fluff.

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

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

The description covers the essential usage, conditions, and parameter guidance. For a destructive tool without output schema, it provides sufficient context for an AI agent to invoke it 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 description provides a concise explanation of the 'account_id' and 'account' parameters, reinforcing the schema descriptions. It adds value by clarifying the stdio context, but the schema already covers 67% of parameters with descriptions.

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

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

The description clearly states 'Delete an account by id' and includes the condition about transactions and force flag, distinguishing it from sibling delete tools for other entities.

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

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

The description specifies when to use (delete account) and includes a note about the 'account' parameter being refused on stdio, guiding the agent to use 'account_id' instead. However, it does not explicitly contrast with other delete 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 indicate destructiveHint=true and idempotentHint=true. The description adds useful behavioral context: the category parameter is refused on stdio and category_id must be used. It does not cover what happens if the budget entry does not exist, but overall adds value beyond annotations.

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

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

The description is extremely concise: two sentences that front-load the purpose immediately and then deliver a crucial usage caveat. Every word serves a purpose with no redundancy.

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

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

Given no output schema, the description adequately covers essential behavior for a delete tool. It could mention prerequisites (e.g., budget entry must exist) or error handling, but the combination with annotations and high schema coverage makes it fairly complete.

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

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

Schema coverage is 100%, but the description provides critical parameter semantics: it clarifies that category is refused and category_id should be used instead. This goes beyond the schema's own description for the category field.

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 'Delete a budget entry for a category/month.' It uses a specific verb (delete) and resource (budget entry), and distinguishes from sibling tools like set_budget (create/update) and get_budget_summary (read).

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

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

The description provides specific guidance: 'Stream D Phase 4 (stdio): pass category_id (numeric) — category (name) is refused.' This clearly advises which parameter to use and warns against using the category name. However, it does not explicitly compare to alternatives like delete_category for deleting entire categories.

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?

Builds on annotations (destructiveHint=true, idempotentHint=true) by describing the refusal behavior when dependencies exist. Also explains parameter-level behavior (name refused, confirmation_token optional). No contradictions with annotations.

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

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

Three sentences with no fluff. The first sentence states the core purpose immediately, and the remaining two add essential contextual details. 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?

Adequate for a deletion operation, but lacks explicit mention of return value or success/error behavior. The purpose of 'confirmation_token' is mentioned but not fully explained. The description is functional but could be more complete.

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

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

Schema coverage is 100% (baseline 3), but description adds significant value: clarifies that 'name' parameter is refused on stdio and that 'confirmation_token' is optional despite being part of the schema. This goes beyond the schema descriptions.

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

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

Clearly states 'Delete a category by id' with specific verb and resource. Distinguishes itself from sibling delete tools (e.g., delete_subscription, delete_account) by mentioning the refusal condition when referenced by transactions/rules/subscriptions.

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 guidance: refuses if category is still referenced, advises using 'id' instead of 'name' on stdio, and clarifies that confirmation_token is optional. Lacks direct comparison to alternatives like updating instead of deleting, but the context is clear enough.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true, signaling destructive but idempotent behavior. The description adds only 'by id' but no additional context (e.g., authorization needed, what happens if id not found). With annotations covering the safety profile, the description contributes minimally.

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, complete sentence with no superfluous words. It is front-loaded and efficient.

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

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

For a simple delete operation with one parameter and annotations providing destructive and idempotent hints, the description is mostly adequate. It lacks return value or error details, but given no output schema and the straightforward nature, it is sufficient.

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

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

Schema description coverage is 0%, so the description must clarify the parameter. It only says 'by id', implying the id is an identifier, but does not specify its meaning (e.g., FX override id from list_fx_overrides) or format. The agent lacks guidance on how to obtain the 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 clearly states 'Delete a manual FX rate override by id', specifying the action, resource, and method. It distinguishes from sibling tools like set_fx_override or list_fx_overrides, which handle create/update or read operations.

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 no guidance on when to use this tool vs alternatives. It does not mention prerequisites, typical workflow, or scenarios where deletion is appropriate. Sibling tool names are listed but not 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?

Annotations already indicate destructive and idempotent behavior. The description adds context about the stream-dependent parameter refusal, which is useful beyond annotations.

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

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

Two sentences, front-loaded with action and resource, no wasted words.

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

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

For a simple delete tool with fully described parameters and no output schema, the description covers all necessary context including the stream nuance.

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

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

Schema coverage is 100% with descriptions. The description adds value by explaining the stdio restriction on the `goal` parameter and reinforcing the numeric nature of `goal_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 clearly states the action (Delete) and the resource (a financial goal). It specifies the key parameter `goal_id` and distinguishes this tool from siblings like add_goal and update_goal.

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

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

The description provides explicit guidance on using `goal_id` instead of `goal` on stdio, which helps the agent choose the correct parameter. It implies this is the only way to delete a goal, but does not mention when not to use it or prerequisites.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond confirming deletion. It does not discuss permanence, cascading effects, or error states.

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

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

The description is extremely concise at 4 words, front-loading the verb and resource without unnecessary elaboration.

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 delete operation with one param and no output schema, the description is minimally adequate but could include a note on effects (e.g., permanent deletion) or success/error behavior. Sibling delete tools have similar brevity.

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

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

With 0% schema description coverage, the description only mentions 'by id' for the single required parameter. It does not clarify that the ID is the loan's numeric identifier obtainable from list_loans, leaving ambiguity.

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 'Delete a loan by id' clearly states the action (delete), the resource (a loan), and the mechanism (by id), distinguishing it from siblings like add_loan or update_loan.

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

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

No guidance on when to use this tool or alternatives is provided. The description does not indicate prerequisites, such as first using list_loans to obtain the ID, or when to prefer other tools.

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

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

Annotations already indicate destructiveHint=true. The description adds valuable context: transactions survive, no data loss, and fallback to orphan-aggregation path. This goes 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: the first states the action, the second explains the impact. It is concise and front-loaded with no unnecessary words.

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

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

Despite no output schema, the description fully explains the effect of the tool (what happens to transactions) and the parameter is well-defined in the schema. It is complete for a delete operation.

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

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

Schema coverage is 100% and the schema already describes the parameter as 'Holding name OR symbol (fuzzy matched)'. The description does not add additional meaning to the parameter, so baseline score applies.

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

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

The description clearly states 'Delete a portfolio holding' with a specific verb and resource. It also explains the behavioral nuance about transactions surviving, which distinguishes it from siblings like update or add holding.

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

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

The description explains that transactions referencing the holding survive with FK set to NULL, indicating when to use (delete while preserving transactions). However, it does not explicitly state when not to use or mention alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds no extra behavioral context. It does not contradict the annotations, but also does not elaborate on any side effects or requirements.

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. It is efficient but could benefit from slightly more detail without becoming verbose.

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 delete tool with one parameter, the description minimally covers what the tool does. Annotations fill in safety context. However, it does not mention that the id must correspond to an existing rule or what happens upon deletion.

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

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

Schema description coverage is 0%. The description only mentions 'by id' without adding any meaning beyond the schema's property definition. No constraints, format, or semantics are clarified.

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

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

The description clearly states the verb 'Delete' and the resource 'transaction rule', and specifies the identifier 'by id'. It effectively distinguishes from sibling tools that delete other resources like subscriptions or splits.

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

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

The description provides no guidance on when to use this tool vs alternatives such as update_rule or list_rules. No prerequisites, exclusions, or context for invocation are given.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no new behavioral context beyond confirming deletion. Adequate but no extra detail.

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

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

Single sentence of 5 words, very concise. However, brevity sacrifices useful detail; still well-structured for a simple operation.

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?

Simple tool with one parameter and no output schema. Description is minimal but covers the basic action. Lacks error handling, return value, and differentiation from sibling delete tools.

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

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

Schema description coverage is 0%, so description must compensate. It only mentions 'by id' without clarifying what split_id represents, its format, or constraints. Insufficient for a parameter without schema descriptions.

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

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

Description clearly states the verb 'Delete' and resource 'split', with the identifier 'by id'. It distinguishes from siblings like list_splits (read), add_split (create), and update_split (modify).

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

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

No guidance on when to use this tool vs alternatives (e.g., update_split, replace_splits). No context or exclusions 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 already provide destructiveHint=true and idempotentHint=true. The description adds 'permanently', reinforcing the destructive nature, but does not disclose additional behavioral details (e.g., cascading effects, permissions required).

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 with no superfluous words. It is front-loaded with the key action and resource.

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 simplicity of the tool (one parameter, no output schema) and the presence of annotations, the description is nearly adequate but lacks details on error behavior or what happens post-deletion. It meets a minimal standard.

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

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

Schema coverage is 0%, and the description only mentions 'by id' without explaining what the id represents or constraints on its value. The agent must infer the format and source from context alone.

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

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

The description clearly states the action ('permanently delete') and the resource ('subscription by id'), making the tool's purpose unambiguous. It is specific and distinguishes it from other delete tools by resource name.

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

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

No guidance on when to use this tool versus alternatives, such as when to delete a subscription vs. update or disable it. No preconditions or contexts are mentioned.

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

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

The description specifies that the deletion is permanent, which adds behavioral context beyond the annotations' destructiveHint=true and idempotentHint=true. However, it does not disclose potential side effects like cascading deletions or permissions needed.

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 with no redundant words. It is front-loaded and efficiently conveys the core action and resource.

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

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

For a tool with one parameter, no output schema, and a straightforward destructive operation, the description is complete. It states the action, permanence, and identification method without unnecessary detail.

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

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

The only parameter 'id' is described in the input schema with equivalent detail. The description adds no additional meaning beyond what the schema already provides, and schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the verb (delete), resource (transaction), and method (by ID). This distinguishes it from sibling delete tools for other resources like delete_subscription or delete_split.

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 when wanting to delete a transaction, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. For a simple delete, the purpose is clear enough.

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 context beyond annotations: it specifies that both legs are deleted and mentions identification methods. It does not contradict annotations (destructiveHint=true is consistent) and supplements the idempotentHint with operational details.

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

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

Two concise sentences with no wasted words, front-loading the action and essential identification info.

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 destructive operation with no output schema, the description covers the main action and identification, but could mention irreversibility or error conditions for completeness.

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

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

With 0% schema coverage, the description compensates by indicating that either linkId or transactionId can identify the transfer. However, it does not explain the relationship between parameters or their exact roles (e.g., transactionId is a leg's 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 clearly states the action 'delete', the resource 'transfer pair', and specifies it deletes both legs. It also explains identification methods (by linkId or leg id), distinguishing it from siblings like delete_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 description implies use for deleting both legs of a transfer in one operation, suggesting efficiency over deleting legs individually, but lacks explicit when-not-to-use guidance or direct alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries a lower burden. It adds that the tool returns candidate subscriptions and a confirmationToken, which is helpful but not deeply detailed (e.g., no mention of whether the tool modifies state or requires specific permissions).

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

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

The description is two sentences long, front-loaded with the primary action, and contains no redundant words. Every sentence adds value.

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

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

Given the tool's simplicity (one optional parameter, clear output token), the description covers the essential functionality and return value. It is complete enough for an agent to understand the tool's purpose, though it could mention default behavior for lookback_months.

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

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

Schema description coverage is 0%, so the description should compensate. It mentions 'recent transactions' which implicitly relates to the lookback_months parameter, but does not explicitly explain the parameter's meaning or effect. The description fails to fully clarify the parameter's usage.

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 specifies the action ('Scan recent transactions'), the resource ('subscriptions'), and the criteria ('regular cadence + stable amount'). It distinguishes itself from sibling tools like list_subscriptions (which lists existing ones) and bulk_add_subscriptions (which uses the token).

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 indicates the return value is a 'confirmationToken for bulk_add_subscriptions', which provides clear context for the tool's role in a workflow. However, it does not explicitly state when to use this detection tool versus alternatives like list_subscriptions.

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 (not read-only). The description confirms it commits, which is expected. No additional behavioral traits (e.g., side effects, permissions) are disclosed.

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

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

The description is extremely concise: two sentences that front-load the core purpose and prerequisite. 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?

The tool has three required parameters (including a nested 'filter' object) and no output schema, but the description provides no details about these parameters or the return value, making it incomplete for complex invocations.

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

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

Schema description coverage is 0% and the description does not explain any parameters, leaving the agent to infer meaning solely from names and types.

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 ('Commit') and the resource ('bulk-categorize'), and distinguishes from siblings by specifying the prerequisite preview_bulk_categorize.

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 it must be preceded by preview_bulk_categorize, providing a clear prerequisite. However, no alternative tools or exclusion criteria are mentioned.

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

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

Annotations already indicate destructive and idempotent. The description adds the ordering constraint but little else regarding behavioral traits.

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

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

Two concise sentences with no redundancy, front-loading the key action and prerequisite.

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?

Does not describe return values or success/error outcomes, and lacks explanation for the required parameters; given no output schema, more context is needed for a destructive operation.

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

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

The schema has no descriptions (0% coverage), and the description does not explain the purpose of the filter or confirmation_token parameters, leaving the agent to infer from names alone.

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

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

The description clearly states the action (commit) and resource (bulk delete), and distinguishes from preview_bulk_delete by noting it's the commit step.

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 that it must be preceded by preview_bulk_delete, providing a clear precondition and usage context.

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

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

Describes return value structure and abort condition. Annotations indicate mutation (readOnlyHint false, destructiveHint false) but no contradiction. Adds context beyond annotations.

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

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

Concise, front-loaded with key action and precondition. Four sentences cover essential details without 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?

Describes changes keys and return format, but filter and confirmation_token are under-documented. No output schema, so return info is helpful but still incomplete for a complex tool with nested objects.

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

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

Schema description coverage is 0%. Description only lists accepted changes keys, but does not explain filter or confirmation_token parameters. Missing key information for agent usage.

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 'Commit a bulk update.' and differentiates from preview_bulk_update by specifying it must be preceded by it. The verb 'commit' and resource 'bulk update' are specific.

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

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

Explicitly says 'Must be preceded by preview_bulk_update with the same filter+changes', providing a clear precondition. Also explains abort behavior. Does not discuss when to avoid, but context is sufficient.

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

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

Annotations include destructiveHint=false, but the description does not clarify what 'commit' entails (e.g., whether it modifies data permanently) beyond stating it's an upload commit. The note about stdio is a transport limitation, not behavioral disclosure. No additional behavior is explained.

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

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

The description is short but includes irrelevant debugging information ('Stream D Phase 4: stdio cannot resolve...') that does not aid tool usage and wastes tokens. The core message is buried under technical jargon.

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 (5 params, nested objects, no output schema) and low schema coverage, the description is severely incomplete. It fails to explain prerequisites, return values, the commit process, or how to obtain the required confirmation_token. An AI agent lacks sufficient context to use the tool correctly.

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

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

The input schema has 5 parameters with 0% schema description coverage. The description provides no explanation of any parameter (e.g., confirmation_token, file_path, column_mapping). The agent receives no guidance on parameter meaning or usage.

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 'Commit an uploaded file,' which clearly identifies the action and resource. It distinguishes from sibling tools like preview_import and cancel_import. However, the additional technical note about Stream D Phase 4 and stdio is confusing and detracts from clarity.

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

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

The description advises using HTTP MCP or web UI instead of stdio, providing a usage constraint. However, it lacks explicit guidance on when to use this tool vs. alternatives like import_with_template or preview_import, and no when-not-to-use scenarios are described.

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, and idempotentHint=true. The description 'Discover' aligns with read-only behavior, but it adds no extra information about traits like rate limits, permissions, or the nature of returned content. It does not contradict annotations.

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

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

The description is extremely concise: a single sentence of six words. It is front-loaded and contains no filler, earning its place by capturing the tool's entire purpose efficiently.

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

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

Given the tool's simplicity (help function with two optional parameters), the description is largely adequate. However, it does not mention what the output or return format looks like, which could be helpful but is not critical for a discovery tool.

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

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

Schema description coverage is 50% (only tool_name has a description). The description does not add any parameter meaning beyond what is already in the input schema. The topic enum is fully defined in the schema, and tool_name's schema description is minimal.

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: 'Discover available tools, schema, and usage examples'. It uses a specific verb 'Discover' and identifies distinct resources, distinguishing it from sibling tools that perform specific financial operations.

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 when the agent needs to explore available tools or their details, but it does not explicitly state when to use this tool versus alternatives (e.g., for specific task-oriented queries). No exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: currency handling (each balance in its own currency, reportingCurrency surfaced for cross-currency) and a critical streaming limitation ('stdio cannot decrypt account names'). This goes beyond annotations to inform agent behavior.

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

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

Three sentences, each adding unique value: purpose, currency behavior, streaming limitation. No redundant text, front-loaded with core purpose.

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

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

Without an output schema, the description should more thoroughly explain the response structure. It mentions grouping and currencies but doesn't specify fields like account names or whether balances are arrays. The decryption note hints at content, but overall, it's adequate but not fully explicit for a medium-complexity tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context for reportingCurrency (returned as response metadata) but adds nothing beyond the schema for the currency parameter. Overall, it provides marginal added meaning.

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

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

The description clearly states 'Get current balances for all accounts, grouped by type (asset/liability)'. This is a specific verb and resource, and it distinguishes the tool from siblings like get_net_worth or get_budget_summary which serve different financial summary purposes.

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

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

The description does not explicitly guide when to use this tool over siblings. It includes a note about stdio decryption limitations, which is useful for tool selection context, but lacks direct comparisons or 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the important behavioral limitation about category name decryption in stdio, which goes beyond annotations. No contradictions.

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

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

The description is extremely concise with two sentences. The first sentence states core purpose, and the second adds critical context. No unnecessary words.

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

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

Given 2 parameters, no output schema, and siblings list, the description covers core function and a key limitation. It could hint at response structure, but is sufficiently complete for the complexity level.

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 parameter descriptions already present. The tool description does not add additional meaning to the parameters beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's verb ('Get') and resource ('budget vs actual spending for a specific month'), making the purpose distinct from siblings like get_spending_trends or get_income_statement.

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 specific guidance: stdio transport cannot decrypt category names, advising use of HTTP MCP or web UI when full category names are needed. However, it does not explicitly compare with sibling tools like get_spending_trends.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral context by specifying that the forecast is based on recurring transactions and current balances, which goes 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, clear sentence that front-loads the verb and resource. Every word is meaningful and there is no redundancy or unnecessary detail.

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 one parameter and no output schema, the description covers the purpose and data sources. However, it does not specify the return format (e.g., numeric values, chart), which is a minor gap. Still, it is largely complete given the tool's simplicity.

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

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

Schema coverage is 100% and the parameter 'days' is well-described in the schema. The description adds the context of the forecast being based on recurring transactions and balances, but this doesn't significantly enhance the parameter semantics beyond the schema's description.

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

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

The description clearly states the tool projects cash flow for specific horizons (30, 60, or 90 days) based on recurring transactions and balances. It distinguishes from sibling tools like get_budget_summary or get_spending_trends by focusing on future cash position.

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 forecasting cash flow but does not explicitly state when to use this tool versus alternatives or provide exclusion conditions. The context of sibling tools gives some implicit guidance, but no direct when/when-not/alternatives are mentioned.

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

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

Annotations already indicate read-only, non-destructive behavior. Description adds crucial transport-specific limitation about decryption, which is beyond annotations. Does not detail output format or other behaviors.

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 purpose, no fluff. Every sentence adds value.

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

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

For a zero-parameter list tool with rich annotations, description is adequate. Missing details about output format but acceptable given simplicity and the transport caveat.

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

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

No parameters, so baseline 4 applies. Schema coverage is 100% trivially. No additional parameter info needed.

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

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

Description clearly states 'List all available transaction categories' with a specific verb and resource. Distinguishes from siblings like get_account_balances or create_category.

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

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

Provides clear context that stdio transport cannot decrypt names, advising to use HTTP MCP or web UI. Implicitly tells when not to use this tool under stdio, though lacks explicit alternatives for normal use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. Description adds valuable context about loan balances staying in original currency and reportingCurrency as metadata, enhancing transparency beyond annotations. 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 concise sentences convey the core function and an important detail. No superfluous words. Well-structured and front-loaded.

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

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

No output schema, and the description does not specify the return format (e.g., plan details, comparison results). While the purpose is clear, an agent might need more context about what data is returned. Adequate for a simple tool but could be more complete.

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

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

Schema coverage is low (33%). Description explains the 'strategy' parameter implicitly but does not clarify 'extra_payment' or 'reportingCurrency' beyond the schema's brief description. The description adds limited value to parameter understanding.

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

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

Clearly states the verb 'compare' and the resource 'avalanche vs snowball payoff across all user loans'. Distinguishes from siblings like get_loans and get_loan_amortization. Adds specific context about multi-currency handling.

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

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

Implies usage for comparing debt payoff strategies. Does not explicitly state when not to use or provide alternatives, but the context is clear enough given sibling tool names. Could be more explicit about 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 read-only, non-destructive, idempotent behavior. The description adds a useful note about decryption constraints (stdio cannot decrypt category names) and suggests an alternative interface (HTTP MCP or web UI). This exceeds what annotations provide without contradiction.

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

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

The first sentence is clear and front-loaded, but the second sentence is verbose and includes technical implementation details that are not concise. It could be reduced to focus on the core purpose.

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

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

Given no output schema, the description should explain what the financial health score represents or its range. It does not, leaving the agent without information about the return value. The presence of many sibling tools also suggests more context would help.

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

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

There are no parameters, so the description does not need to add parameter semantics. According to guidelines, 0 parameters yields a baseline of 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 states 'Calculate a financial health score' which is a clear verb+resource, but the following sentences add extraneous technical details about decryption and HTTP MCP that distract from the purpose and may confuse the agent. It does not explicitly distinguish from sibling tools.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It mentions a technical limitation regarding decryption but does not clarify usage context or 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 declare readOnlyHint, idempotentHint, and no destructiveness. The description adds value by disclosing that cross-rates triangulate through USD and that user overrides win, which are important behavioral traits beyond the annotations. It does not contradict any annotations.

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

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

The description is extremely concise: two sentences that efficiently convey purpose and key behavior. The first sentence front-loads the core action, while the second adds critical nuance. Every word earns its place with no redundancy.

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

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

For a simple tool with no output schema and no parameter descriptions, the description covers the essential purpose and key behavioral context (triangulation, override priority). However, it lacks clarification on the return value format (e.g., numeric rate for 1 unit of from in terms of to) and any assumptions about date handling, leaving minor 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?

With 0% schema description coverage, the description must compensate. It gives context to 'from', 'to', and 'date' by placing them in a sentence ('convert 1 unit of from into to on date'), indicating their roles. However, it does not specify acceptable formats (e.g., ISO currency codes for from/to) or provide examples, leaving some interpretation to the user.

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 and resource: 'Get the FX rate to convert 1 unit of `from` into `to` on `date`'. It clearly states the action and the inputs, leaving no ambiguity about what the tool does. It also differentiates from sibling tools like convert_amount by focusing on rate retrieval rather than amount conversion.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It mentions cross-rate behavior and user overrides, but fails to explicitly state when to use get_fx_rate over convert_amount, list_fx_overrides, or set_fx_override. No when-not or alternative tools are mentioned.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds crucial behavioral details: names return null on stdio transport, progress numbers are not surfaced, and accountIds array is present. No contradictions.

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

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

The description is front-loaded with the core purpose and then provides necessary technical details. It is slightly lengthy but each sentence adds value; no redundancy. Could be slightly more concise but still effective.

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

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

Given no parameters and no output schema, the description comprehensively explains what the tool returns (goals with null names, accountIds) and why. It also notes limitations and alternative tools for richer data, making it 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% (no parameters), so baseline is 3. The description does not need to add parameter info since there are none. No additional value or deficit.

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

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

The description clearly states 'Get all financial goals.' The verb and resource are specific, and it distinguishes itself from sibling tools that handle transactions, budgets, accounts, etc., by focusing on goals.

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

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

The description explicitly states when to use this tool vs alternatives: 'use HTTP MCP or the web UI to see decrypted names AND progress numbers.' It also explains what is missing on stdio transport, providing clear guidance on usage boundaries.

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 that supplying headers returns match scores, which is behavioral context beyond the annotations. 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, no filler, front-loaded with the primary purpose. Every sentence adds value.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers both base functionality and the optional scoring behavior completely. No missing details noted.

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

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

Schema coverage is 100% and the description explains that the 'headers' parameter is used to get match scores, adding meaning beyond the schema's field 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 uses specific verbs ('List') and a clear resource ('saved CSV import templates'), and optionally describes a secondary function (scoring against headers). It distinguishes itself from sibling tools like 'import_with_template' by focusing on listing rather than importing.

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 listing templates and optionally scoring headers, but it does not explicitly state when to use this tool versus alternatives (e.g., preview_import) or provide 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=true, destructiveHint=false, and idempotentHint=true. The description adds a behavioral trait (inability to decrypt category names via stdio) that annotations do not cover, enhancing transparency.

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: purpose and a critical usage caveat. No redundancy, 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?

No output schema, and the description does not explain the return structure of the income statement. However, given the tool's name and common knowledge, it is partially complete. Lacks details on what financial data is returned.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions 'period' indirectly but does not add meaningful semantics beyond what the schema already provides for start_date, end_date, and reportingCurrency.

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

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

The description clearly states it generates an income statement for a period, with a specific verb and resource. It distinguishes from sibling tools like get_budget_summary or get_net_worth.

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 warns against using with stdio transport for category decryption and directs to HTTP MCP or web UI, providing clear when-not-to-use and alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a notable behavioral trait: that stdio transport cannot decrypt holding names, which is a valuable context for the agent. However, it does not disclose other potential behaviors like response format or error conditions. Overall, adequate beyond annotations.

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

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

The description is only two sentences, no wasted words. The first sentence states the purpose, the second adds a key limitation. It is front-loaded with the main action. However, it could be slightly more structured (e.g., parameter descriptions) without losing 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?

Given the tool has 4 parameters (including a nested array), no output schema, and the description clarifies neither parameters nor return values, the description is incomplete. The annotation provides safety info, but the agent would not know what insights are returned or how to use parameters effectively. The limitation info helps a bit, but overall insufficient for a tool with this complexity.

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

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

Schema description coverage is 0%, meaning the description provides no information about the four parameters (mode, targets, benchmark, reportingCurrency). The parameter names and types are in the schema, but their semantics are completely unexplained. For a tool with multiple parameters including a nested array, this is a critical gap. The description must compensate but fails to do so.

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 'Portfolio-level investment analytics' which clearly indicates the tool provides aggregated insights about investments. However, it does not differentiate from sibling tools like get_portfolio_analysis or get_portfolio_performance, which likely have similar scopes. The mention of 'decrypt holding names' gives a hint of the data involved, but overall purpose is adequately communicated.

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

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

The description mentions a limitation (stdio cannot decrypt holding names) and suggests using HTTP MCP or web UI instead. This provides some context on when to use this tool, but it lacks explicit comparisons to sibling tools or guidance on when to choose this over others. No when-not-to-use scenarios are described.

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 that declare read-only and idempotent behavior, the description adds significant context: amounts are in the loan's own currency and the response includes both loan currency and reportingCurrency. This helps the agent understand currency handling without needing to call the tool.

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

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

Two concise sentences, front-loaded with the primary purpose. Every word adds value 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?

For a tool with 3 parameters and no output schema, the description gives the core output type (amortization schedule) and currency context. However, it omits details like the schedule's temporal range (per payment period) or whether it's a future projection. Adequate but not thorough.

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 67% (as_of_date and reportingCurrency described). The description adds slight value by mentioning that reportingCurrency appears in response, but does not explain loan_id or as_of_date. Overall, the description does not substantially enhance parameter 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 explicitly states 'Full amortization schedule for a loan', clearly identifying the resource (amortization schedule) and action (get). This distinguishes it from sibling tools such as list_loans or get_debt_payoff_plan.

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

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

No guidance on when to use this tool vs alternatives. For example, it does not contrast with get_debt_payoff_plan (a summary) or other loan tools. The agent must infer usage from the tool name alone.

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 destructiveHint, but the description adds a key behavioral limitation: stdio cannot decrypt loan names. This goes beyond annotations by disclosing a real-world constraint.

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

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

Two sentences: first defines purpose, second provides crucial usage constraint. No superfluous words, front-loads the key information.

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

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

Given no output schema, the description 'amortization summary' gives a reasonable expectation of return content. However, it could be slightly more explicit about the returned fields. Overall sufficient for a zero-parameter read 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?

There are zero parameters, so baseline is 4. The description does not need to add parameter details, and the schema coverage is 100%.

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 retrieves all loans with amortization summary, distinguishing it from siblings like list_loans (likely basic info) and get_loan_amortization (single loan). The verb 'get' and resource 'loans' are specific.

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 warns that stdio cannot decrypt loan names, advising to use HTTP MCP or web UI instead. This provides clear when-not-to-use guidance, though it does not mention alternative sibling tools like list_loans.

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 critical context: it explains the calculation basis (SUM of transactions) and warns that market-valued investment balances are only available over HTTP. This goes beyond annotations without contradiction.

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

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

The description is concise and well-structured, front-loading the core purpose then explaining parameters and a note. However, the note about HTTP vs stdio is somewhat lengthy and could be slightly trimmed without losing 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?

Given the absence of an output schema, the description adequately explains the return shape (per-currency assets/liabilities/net) and parameter effects. It also addresses the stdio limitation for investment balances. Some might expect more detail on the trend structure, but it's sufficient.

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

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

Schema coverage is 100%, and the description adds value: 'months > 0' for trend, 'reportingCurrency' defaults to user's display currency, and 'currency' filters. The description clarifies the behavior beyond the schema's description fields.

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 'Net worth across all accounts. Returns per-currency assets/liabilities/net.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like get_account_balances.

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

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

The description explains when to pass the 'months' parameter for a trend and when to omit it for current totals. It also notes that 'reportingCurrency' is metadata for cross-currency context. While it doesn't explicitly list when not to use, the instructions are clear for the intended use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing that holding/account names cannot be decrypted on stdio (Stream D Phase 4 limitation) and that account/account_id filters are ignored on this transport. This goes beyond the annotations to set transport-specific expectations.

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

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

Two concise sentences. The first sentence immediately states the core purpose. The second adds critical transport-specific limitations with no redundant or extraneous 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?

Given the lack of output schema, the description should ideally outline return fields or behavior. It covers the main purpose and a key limitation, but omits details about the 'symbols' parameter's effect, what allocation breakdown entails, and the response structure. Adequate for a simple read-only tool but with 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?

With 75% schema coverage, baseline is 3. The description notes that account and account_id are unused, but does not clarify the purpose of the 'symbols' parameter (which lacks a schema description) or provide additional semantics for reportingCurrency. The description adds no meaning beyond what the schema already provides.

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

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

The description clearly states 'Portfolio holdings with allocation breakdown' which specifies the verb (get/retrieve), resource (portfolio holdings), and output (allocation breakdown). It distinguishes from siblings like get_portfolio_performance, analyze_holding, and trace_holding_quantity by focusing on current holdings and allocation rather than performance or deep analysis.

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

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

Explicitly tells when not to use this tool on stdio ('use HTTP MCP or the web UI for this query') and notes that account/account_id filters are unused on this transport, guiding agents to alternative tools or transports for decrypted names or account-specific queries.

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, which the description aligns with. The description adds useful behavioral context about decryption limitations (stdio cannot decrypt holding names), which annotations do not cover. No contradiction.

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

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

Two concise sentences: first states the core purpose, second provides a critical usage limitation. No wasted words; information is front-loaded and easy to parse.

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

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

Given the parameter simplicity and no output schema, the description covers the essential purpose and a key behavior (decryption limitation). However, it does not hint at the output structure (e.g., list of holdings with cost basis), leaving some ambiguity for the agent.

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 50%: only reportingCurrency has a description. The description does not add any parameter-specific information beyond the schema. For period, the enum values are self-explanatory, but no additional context like 'all includes everything' is given. The description could have compensated but does not.

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

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

Description clearly states the tool returns 'portfolio performance: cost basis and realized P&L by holding', specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like get_portfolio_analysis or get_investment_insights, leaving some ambiguity about when to use each.

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

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

The description provides a specific usage limitation: 'Stream D Phase 4: stdio cannot decrypt holding names — use HTTP MCP or the web UI for this query.' This guides the agent when to avoid this tool over alternative transports. No explicit when-not or alternatives for sibling tools, but the context is helpful.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds limited behavioral context. It states that average amounts stay in account currency and reportingCurrency is metadata, but does not disclose pagination or other traits beyond what annotations cover.

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

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

The description is two sentences long and directly addresses the tool's function and key detail without extraneous text. It could be slightly more structured, but it remains concise and front-loaded with purpose.

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

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

No output schema is provided, so the description should elaborate on return values. It mentions average amounts and metadata but does not fully describe the response structure or fields. For a read-only list tool, it is adequate but not completely thorough.

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

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

The only parameter (reportingCurrency) is well-described in the schema as ISO code. The description adds that it defaults to the user's display currency, providing clarity beyond the schema definition. Schema coverage is 100%, so description adds meaningful 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 clearly states the tool retrieves detected recurring transactions and provides concrete examples (subscriptions, bills, salary). It specifies average amounts and reportingCurrency behavior, making the purpose distinct from sibling tools.

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

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

The description implies usage for fetching recurring transaction data but does not explicitly state when to use this tool versus alternatives like get_spending_trends or get_budget_summary. No exclusion criteria or alternative guidance is provided.

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

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

Annotations declare the tool as read-only, idempotent, and non-destructive, which the description complements by warning that stdio cannot decrypt category names. This behavioral insight is valuable and goes beyond annotations, though it doesn't detail what the output contains.

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

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

Two concise sentences: one explaining the core functionality, another providing a critical usage limitation. Every sentence is necessary and front-loaded. No redundant or extraneous information.

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

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

The tool is simple with no parameters and good annotations, but it lacks any description of the output format. Given no output schema, the agent might not know what to expect (e.g., a list of categories, percentages). This is a moderate gap for completeness.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description correctly omits parameter details, as there are none. The baseline for no parameters is 4, and no extra value is needed.

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 finds spending categories with >30% deviation from their 3-month average. This is a specific verb-resource pair with a precise threshold, differentiating it from sibling tools like 'get_spending_trends' which do not focus on anomalies.

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

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

The description mentions a limitation ('stdio cannot decrypt category names') and suggests alternatives (HTTP MCP, web UI), but does not provide guidance on when to use this tool versus other spending-related tools. No explicit when-to-use or when-not-to-use 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses that category names are undecryptable in stdio, which is a behavioral trait affecting interpretation of results. This adds value 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?

The description is concise with two sentences. The first sentence clearly states the purpose. The second sentence adds a useful caveat about decryption limitations. No unnecessary information.

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

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

The description covers purpose and a key behavioral constraint, but lacks information about return values or output structure. Given the absence of an output schema and moderate complexity, a more complete description would include expected data format or ranges.

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 all parameters having descriptions. The description adds no additional meaning beyond what the schema already provides. 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 retrieves spending trends grouped by category over time. The verb 'get' and specific resource 'spending trends over time grouped by category' make the purpose clear. It does not explicitly differentiate from sibling tools, but the purpose is specific enough.

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

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

The description provides no explicit guidance on when to use this tool versus other tools. While it mentions a limitation (category names not decrypted in stdio), it does not suggest alternative tools for different contexts or when not to use 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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint; the description adds a specific behavioral constraint: 'stdio cannot decrypt category/subscription names.' This provides valuable context beyond the annotations without contradiction.

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

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

The description consists of two short sentences with no fluff. The first sentence states the core purpose, and the second provides important behavioral context. Every word contributes value.

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

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

Given the tool's simplicity (one optional parameter, no output schema, annotations present), the description covers the main purpose and a key limitation. However, it does not describe the return value, which is a minor gap.

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

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

The input schema has 100% description coverage for the single parameter 'reportingCurrency'; the description does not add any additional meaning or context for this parameter, 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 states 'Get current attention items,' which clearly identifies the action and resource. The verb 'Get' and noun 'attention items' provide a specific purpose, and it is distinguishable from sibling tools that focus on budgets, transactions, or categories.

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 retrieving current attention items but does not explicitly state when to use this tool versus alternatives. It provides a limitation note about stdio decryption but lacks direct guidance on when not to use the 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, non-destructive operation. The description adds a behavioral note about decryption limitations during stdio transport, which is beyond what annotations provide. This adds valuable context for the agent, though it could be more comprehensive.

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

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

The description is extremely concise with two sentences. The first sentence clearly states the function. The second provides an important usage constraint. No wasted words or information.

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

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

The tool has no input or output schema. The description explains what it returns (subscriptions with total monthly cost and upcoming renewals) and offers a constraint. For a summary tool, this is reasonably complete, though it could elaborate on the output format or structure.

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

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

There are zero parameters, and schema coverage is 100% (empty schema). The description does not need to explain parameters. Baseline for 0 params is 4. The description does not add anything beyond the schema, but that is acceptable.

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

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

Description states 'Get all tracked subscriptions with total monthly cost and upcoming renewals.' This clearly identifies the tool as retrieving a summary of subscriptions with specific cost and renewal info. However, it does not explicitly distinguish from the sibling tool 'list_subscriptions', which might also list subscriptions. The difference is implied but not stated.

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 includes a caveat about stdio not being able to decrypt names, advising to use HTTP MCP or web UI. This provides context but does not give explicit guidance on when to use this tool versus alternatives like 'list_subscriptions' or other query tools. No when/not-when instructions are given.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds value by specifying the return structure (JSONB conditions+actions) and a key limitation: stdio cannot decrypt joined category names, only FK ids. This goes 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 consists of only two sentences, both front-loaded. The first states the core purpose, and the second adds two specific notes. No wasted words.

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

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

For a parameterless tool with strong annotations and no output schema, the description covers the key behavioral aspects (return format, limitation). It could mention pagination or that it returns all rules, but overall it is sufficient.

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

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

The input schema has no parameters and 100% schema description coverage. Since there are no parameters to document, the description adds no further parameter semantics. A baseline of 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 clearly states the verb 'List' and the resource 'transaction auto-categorization rules', making the tool's purpose immediately identifiable. It also includes specific details about the return format (JSONB conditions+actions) to differentiate from similar tools like list_rules.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_rules. It lacks context about prerequisites, when not to use it, or how it fits into a workflow.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds value by disclosing that via stdio, category names will not be decrypted, which is a behavioral constraint 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 very concise: two sentences, no fluff. The first sentence states the purpose, and the second provides a critical usage limitation. 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 no output schema, the description does not explain what a 'weekly recap' contains, leaving the agent without knowledge of the expected return structure. However, the purpose is clear and the input schema is fully documented, making it minimally adequate.

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

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

The input schema covers all parameters with descriptions, achieving 100% coverage. The description adds no additional meaning beyond what the schema provides, so it meets the baseline expectation.

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: 'Get a weekly financial recap.' It uses a specific verb and resource. However, it does not differentiate from sibling tools like get_budget_summary or get_spending_trends, which could also provide financial summaries.

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 includes a usage note about stdio not being able to decrypt category names, suggesting an alternative (HTTP MCP or web UI). However, it does not explicitly state when to use this tool versus others or provide clear when-not guidance.

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

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

Annotations already indicate a write operation (readOnlyHint=false). The description confirms mutation and adds that duplicates are skipped, but doesn't detail side effects like overwrite behavior or error handling beyond the summary.

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

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

Two sentences with no wasted words. The first sentence front-loads the core purpose, and the second efficiently summarizes the return value.

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

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

Adequately covers the core action and return, but lacks details on expected CSV format, prerequisites (e.g., template existence), and error scenarios. Given the presence of similar sibling tools, more context would help.

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

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

Schema coverage is 100%, providing descriptions for all parameters. The tool description adds minimal extra meaning beyond the schema, such as 'using a saved template' for template_id, but doesn't elaborate on dry_run or account_id behavior.

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

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

The description clearly states the verb 'import', the resource 'transactions', and the method 'using a saved template'. It distinguishes from sibling tools like preview_import and execute_import by specifying template usage and return summary.

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

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

No explicit guidance on when to use this tool versus alternatives like preview_import or execute_import. Prerequisites like template existence are implied but not stated, and there is no mention of when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, making the safety profile clear. The description adds value by specifying that the tool lists 'manual FX rate overrides' and explains they are 'rate_to_usd pins by currency over date ranges', providing context 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, concise sentence (19 words) that front-loads the action and resource. Every word serves a purpose, with no redundancy or unnecessary detail.

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

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

For a tool with no parameters, no output schema, and annotations covering safety, the description is complete. It adequately explains what the tool lists and the nature of the overrides, leaving no gaps for an AI agent.

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

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

The input schema has no parameters (0 params) and schema description coverage is 100% (trivially). With no parameters, the description adds no parameter-specific info, but the baseline for 0 params is 4, and the description does not detract.

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

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

The description clearly states the verb 'List' and the resource 'manual FX rate overrides', with additional context explaining they are 'rate_to_usd pins by currency over date ranges'. This effectively distinguishes it from siblings like get_fx_rate, set_fx_override, and delete_fx_override.

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

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

The description does not explicitly state when to use this tool over alternatives (e.g., get_fx_rate). Usage is implied by the action 'List' but lacks explicit guidance on when-not-to-use or alternative tool names. The presence of sibling tools like get_fx_rate provides some implicit differentiation.

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, idempotentHint, and destructiveHint. The description adds valuable context about a limitation (no decryption in stdio mode) that goes beyond the annotations, enhancing transparency for selecting the correct invocation channel.

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 a critical constraint. Every sentence adds value without redundancy or unnecessary detail.

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

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

Given no parameters, no output schema, and annotations covering safety, the description provides sufficient context: it lists all loans and warns about a platform limitation. This is complete for an agent to use the tool correctly.

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

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

There are no parameters, and schema description coverage is 100%. The description does not need to add parameter info. With zero parameters, the baseline is 4, and the description meets expectations.

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

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

The description clearly states the tool lists all loans. However, it does not explicitly differentiate from the sibling tool 'get_loans', which may have a similar purpose. The additional context about decryption limitations adds clarity but does not scope the tool's core function uniquely.

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 that the tool cannot decrypt loan names when using stdio and directs the agent to use HTTP MCP or the web UI instead. This provides clear when-to-use and when-not-to-use guidance, including specific alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the status filter ('pending or previewed'), which is useful behavioral context but does not disclose other traits like authentication needs.

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 essential information without any unnecessary words.

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

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

Given the tool's simplicity (no parameters, no output schema), the description adequately explains the purpose and scope. However, it omits details about the return format, which might be useful.

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

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

No parameters exist, so the description does not need to elaborate. Baseline for zero parameters is 4.

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

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

The description clearly states the verb 'list' and the resource 'uploaded files' with a specific status filter ('pending or previewed'), distinguishing it from other list tools like preview_import or execute_import.

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 pending/previewed uploads but does not provide explicit guidance on when to use this tool over alternatives or mention 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 indicate readOnlyHint, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context: the output returns JSONB conditions+actions and notes that stdio cannot decrypt certain names. 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?

Three sentences, front-loaded with the main purpose. Every sentence adds value: listing, output format, and a critical limitation. 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?

Tool is simple with no parameters and good annotations. The description covers output format (JSONB conditions+actions) and a key limitation. Could elaborate on the return structure (e.g., array of objects) but is adequate for use.

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

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

The input schema has no parameters, so the description does not need to add parameter meaning. Schema description coverage is 100% (trivially). Baseline score of 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 clearly states the tool lists 'all auto-categorization rules,' which is a specific verb-resource pair. It distinguishes from siblings like 'get_transaction_rules' by specifying the resource type. No ambiguity.

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

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

The description provides some context (returns JSONB conditions+actions, stdio limitation on decryption) but does not explicitly state when to use this tool versus alternatives, nor does it give when-not conditions or prerequisites. Usage is implied by purpose.

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