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

The annotations only include idempotentHint: false, so the description carries most of the behavioral disclosure burden. It clarifies that this is a non-idempotent mutating add operation and gives a precondition, but it does not disclose duplicate-handling behavior, success/failure semantics, or side effects if the symbol is already present.

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. The first sentence states the core action and input; the second gives the decisive usage condition. This is appropriately compact 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?

For a single-parameter mutation tool with no output schema, the description covers the action, input format, and when it is needed. The only notable gap is that it does not describe what the API returns or how duplicate submissions are handled, but these are not critical for selecting and invoking 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 already fully documents coingecko_url with format and example, so schema coverage is 100%. The description adds no significant parameter meaning beyond saying the URL is a CoinGecko coin-page URL, which the schema already conveys.

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

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

The description states a specific action ('Add'), a specific resource ('supported manual-crypto list'), and the required input mechanism (CoinGecko coin-page URL). It also names get_supported_cryptocurrencies as the related check, distinguishing this write operation from the read-only list operation.

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

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

The description explicitly states when this tool is needed: only when get_supported_cryptocurrencies does not already list the symbol. This gives clear when/when-not guidance and points to the sibling tool to consult first.

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 only idempotentHint=false, so the description carries the full burden of behavioral disclosure. It thoroughly explains that the file is read from the host's local filesystem, the type is determined from actual contents rather than extension, invalid files are rejected, and LUNCHMONEY_ATTACHMENTS_DIR restricts accessible paths. This far exceeds the minimal annotation.

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

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

Three dense sentences front-load the action and object, then pack in all critical constraints: allowed types, size cap, local filesystem source, content-based validation, and environment-directory restriction. No filler or repeated schema 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?

For a mutation tool with no output schema, the description is remarkably complete: it covers what is attached, what file types are allowed, the size limit, where the file comes from, how validation works, and an environment-specific restriction. Nothing needed to correctly invoke the tool is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful tool-level semantics beyond the schema: the 10MB size limit, the local-filesystem source, and the content-sniffing behavior. These details help the agent understand the true constraints on file_path and content_type without being redundant.

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 ('Attach') with a clear resource ('a transaction') and object ('a local image or PDF receipt'), and distinguishes this from sibling tools like get_transaction_attachment_url and delete_transaction_attachment by its action alone. It is immediately obvious what the tool does.

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

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

The description clearly establishes when to use this tool: when a receipt file needs to be attached to a transaction. It provides strong contextual constraints (local filesystem, allowed MIME types, max size, environment-directory restriction) but does not explicitly name alternatives or state when not to use it. This is clear context without 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?

The only annotation is idempotentHint=false, so the description must carry behavioral weight. It discloses a notable side effect: passing strings in children creates new sub-categories during the same call. It does not cover return values or failure modes, but the core recursive behavior is clearly stated and does not contradict the annotations.

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

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

Two short, front-loaded sentences with no filler. The first sentence states the core purpose and the second covers the mode-specific behavior. Every word contributes to invocation understanding.

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

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

Given 9 parameters, no output schema, and minimal annotations, the description captures the most important invocation nuances: the is_group switch and the dual ID/string behavior of children. The remaining parameters are fully documented in the schema. Return-value details are absent, but the description is sufficient for correctly selecting and calling the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the is_group and children behavior seen in the schema rather than adding new parameter meaning. It usefully frames the category versus category-group decision, but does not go beyond the schema's own parameter 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 uses a specific verb and resource: 'Create a new category or a category group.' It clearly distinguishes the dual purpose of the tool and immediately explains how the two modes are selected. This is enough to tell it apart from sibling tools like create_tag or create_transaction_group.

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-not-to-use or alternative is named, but there is no close sibling for category creation. The description gives clear context for the two main usage modes: set is_group=true for a category group, and use children to add existing IDs or names of new sub-categories. This effectively communicates usage without leaving mode selection to inference.

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

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

The description discloses only the obvious mutation intent ('Create') and does not add behavioral context beyond what annotations provide. With only idempotentHint=false annotated, there is no mention of side effects, whether duplicates are allowed, required permissions, or what happens after creation. The description does not contradict the annotations, but it also does not meaningfully expand on them.

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

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

The description is extremely concise, with the core purpose front-loaded in the first sentence. The parenthetical about the former name is short and provides useful legacy context. Every element earns its place, and no verbose or redundant content is present.

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

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

The description, combined with the fully documented schema, is minimally viable for an agent to understand the core operation and required parameters. However, it lacks broader context such as when to create a manual account versus other account types and what the tool returns, and the annotations are sparse. These gaps prevent it from being 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?

The input schema has 100% coverage, with each parameter including a clear description, so the description itself need not explain parameters. The tool description adds no parameter-specific meaning beyond what the schema already provides, which aligns with the baseline score for high schema coverage.

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

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

The description states a specific action ('Create') and a specific resource ('a new manually-managed account'), making it immediately clear what the tool does. The phrase 'manually-managed' distinguishes it from synced or crypto account creation tools, and the parenthetical notes the former name without obscuring the current purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives such as create_manual_crypto, create_transactions, or synced account tools. It only mentions the former name 'create_asset', which is historical context, not usage direction. An agent must infer appropriate use entirely from the tool name and sibling list.

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

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

The description adds the symbol-validation constraint, which is beyond the sparse annotation (idempotentHint=false). However, it doesn't reveal behaviors like duplicate handling, creation side effects, or failure modes, leaving much of the behavioral burden on the 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?

Two short sentences, front-loaded with the core purpose and then the key constraint. 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 simple create operation, the description combined with the complete schema is adequately informative. It lacks an explicit output description, but with no output schema defined, this is acceptable.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description's mention of symbols matching get_supported_cryptocurrencies is useful but also already embedded in the symbol parameter'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 'Create a manually-managed crypto asset' with a specific verb and resource. The distinction from sibling tools (delete_manual_crypto, update_manual_crypto, get_all_manual_crypto) is evident from the name and phrasing.

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 prerequisite of matching a symbol from get_supported_cryptocurrencies gives concrete guidance on a precondition to calling this tool. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when 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 only include idempotentHint=false, which is minimal. The description does not disclose any behavioral traits beyond the basic creation action, such as whether creating a tag with an existing name fails, whether colors are validated, or what the response contains. With no output schema and sparse annotations, the description carries the burden but doesn't add behavioral context.

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

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

The description is a single concise sentence that is front-loaded with the action and resource. It is appropriately sized for a simple create operation, though it could add a bit more context 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 create tool with 5 parameters and no output schema, the description is thin. It doesn't explain what happens after creation, whether the tag is immediately usable, or any constraints like uniqueness. The schema covers parameters, but the description lacks operational context that an agent would need to call 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?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies. It doesn't clarify relationships between parameters (e.g., whether text_color and background_color are validated together).

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 tag' uses a specific verb and resource, clearly indicating the action. It distinguishes from siblings like update_tag and delete_tag, though it doesn't explicitly differentiate from other create_* tools, which is less necessary given the resource is named.

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. It doesn't mention that tags are likely used to categorize transactions, nor does it state any prerequisites or exclusions. The context is implied by the name and siblings, but there is no explicit usage direction.

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

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

The description discloses a key behavioral trait beyond the annotations: source transactions are hidden from get_transactions and become accessible via the new group's children with include_children=true. It also states a constraint (cannot include split or recurring transactions) that is not visible in the schema. The only annotation is idempotentHint=false, which the description does not contradict, and the description adds meaningful behavioral context.

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

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

The description is three sentences with no wasted words. It front-loads the core action and constraints, then adds the behavioral consequence and exclusions. Every sentence earns its place.

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

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

Given the tool's moderate complexity (7 params, 3 required) and no output schema, the description covers the essential behavioral context: what happens to source transactions, how to access them later, and what inputs are invalid. It does not mention error cases or whether the operation is reversible, but the idempotentHint=false annotation and the clear constraints make it sufficiently complete for an agent to invoke correctly.

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

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

Schema description coverage is 86%, so the schema already documents most parameters. The description adds context for the 'ids' parameter by explaining the 2-500 range and the behavioral consequence of grouping, but it does not add much beyond the schema for date, payee, notes, status, tag_ids, or category_id. The category_id inheritance behavior is already in the schema description, so the description adds minimal extra value.

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

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

The description states a specific verb ('Create'), a resource ('transaction group'), and a precise scope ('from 2-500 existing transactions'). It also distinguishes the tool from siblings by noting that source transactions are hidden from get_transactions and accessible via the new group's children, which clearly differentiates it from create_transactions and other transaction tools.

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

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

The description provides clear context on when to use this tool: when grouping existing transactions. It also gives an explicit exclusion ('Cannot include split or recurring transactions'), which helps an agent avoid invalid calls. However, it does not explicitly name alternative tools for creating individual transactions or splitting/unsplitting, though the sibling list makes this inferable.

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 only provide idempotentHint=false; the description adds that duplicate transactions are skipped and that the response includes inserted transactions plus skipped duplicates, and states the per-call limit. It doesn't mention default side effects such as balance updates or rule application, though those are covered in the parameter descriptions.

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 that front-load the action and resource, then add the key constraint and return behavior. No filler or repetition of schema 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?

The rich schema covers parameter semantics and the description supplies the missing return-value information. It is slightly incomplete only in not flagging default mutating side effects, but those are inferable from skip_balance_update's description.

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

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

All parameters already have detailed schema descriptions, so the description adds little beyond echoing the 1-500 array constraint. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description names a specific action ('Insert') and resource ('transactions'), and adds a batch-size range and return behavior. This clearly distinguishes it from sibling tools like get_transactions, update_transactions_bulk, and create_transaction_group.

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 makes the use case clear: call this when you need to add one or more transactions. It doesn't explicitly name alternatives or exclusions, but the verb and resource leave little ambiguity against the sibling set.

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 annotations already declare destructiveHint=true, but the description adds meaningful behavioral context: the operation is irreversible and affects Net Worth views. It also clarifies the scope ('ALL') which is crucial for a destructive operation. This goes beyond what the annotation alone conveys.

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 with no wasted words. The primary action and scope are front-loaded, the consequence is stated clearly, and the alternative tool is mentioned succinctly. Every sentence earns its place.

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

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

For a destructive, irreversible operation with two well-documented parameters, this description is complete. It explains scope, irreversibility, impact on Net Worth, and the correct alternative for a narrower operation. No output schema exists, but for a delete tool this is acceptable and not a meaningful 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?

Schema description coverage is 100%, so both account_id and account_type are already documented in the input schema. The main description does not add parameter-specific details, but it doesn't need to because the schema already explains each parameter, including the account_type enum semantics and the note about synced crypto using dedicated tools.

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

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

The description states a specific verb ('Delete'), a precise resource ('ALL historical balance entries for a single account'), and the scope ('ALL'), clearly distinguishing it from the sibling tool delete_balance_history_entry. An agent can immediately understand what this tool does and what it does not do.

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 provides the when-to-use guidance: use this when deleting the entire history, and use delete_balance_history_entry when removing a single month. It names the alternative tool directly, leaving no ambiguity about routing between the two.

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 destructiveHint annotation already flags this as a destructive operation, and the description adds meaningful context by specifying exactly what is deleted and which entries cannot be deleted. It clarifies the 'current' entry edge case, which is valuable beyond the annotation alone.

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

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

Two concise sentences with no filler. The primary action is front-loaded, followed by the key constraint and prerequisite in a natural order.

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

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

For a single-parameter destructive tool with a strong annotation and complete schema description, everything an agent needs to call it correctly is present: what to delete, how to find the id, and what cannot be deleted.

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

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

Schema description coverage is 100%, so the parameter semantics are fully documented in the schema. The description restates the id-based deletion but does not add significant new 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 states a specific action ('Delete'), a specific resource ('a single historical balance entry'), and the mechanism ('by its id'). It also distinguishes deletable entries from ephemeral current entries, making the tool's scope unambiguous.

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

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

It clearly explains when the tool applies: the entry must be historical and have an id, and current entries cannot be deleted. The schema reinforces that the id should be discovered via get_balance_history or get_account_balance_history. It does not name alternative deletion tools, but the intended usage context is clear.

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

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

The description discloses the default failure mode (HTTP 422 with structured dependents payload), the force=true behavior, and irreversibility. The destructiveHint annotation is true, and the description aligns with it, adding valuable context about what happens with dependencies.

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 waste. The default behavior is front-loaded, the force option is explained, and the irreversibility warning is included. Every sentence earns its place.

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

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

For a destructive tool with no output schema, the description covers the key decision point (force flag), the failure mode, and the consequence. It doesn't describe the success response format, but that's less critical for a delete operation. The description is complete enough for an agent to call 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context about force=true's irreversibility and the default failure behavior, but doesn't add much beyond the schema's parameter descriptions. 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 deletes a single category or category group, distinguishing it from sibling tools like delete_tag or delete_transaction. It also specifies the key behavior of failing by default when dependencies exist, which differentiates it from a simple delete.

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

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

The description explains when to use force=true vs default behavior, which is essential usage guidance. It doesn't explicitly name alternative tools for deleting other resources, but the context of category deletion is clear and the force flag guidance is strong.

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 only flag destructiveness; the description adds meaningful context that the operation is irreversible and affects Net Worth views. This goes beyond the structured annotation and helps an agent understand impact.

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-loaded with the action and scope, with no filler. Every word contributes.

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 two-parameter destructive tool with no output schema, the description covers scope, irreversibility, and downstream impact. It could mention confirmation/return behavior or contrast with single-entry deletion, but nothing essential is missing.

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

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

The input schema already documents both parameters with 100% coverage, including descriptions for symbol and account_id. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

States a precise action ('Delete ALL historical balance entries'), a specific resource ('synced crypto holding'), and the scope ('ALL'), which clearly distinguishes it from single-entry deletion siblings like delete_balance_history_entry.

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 word 'ALL' implies this is the full-history deletion tool, and 'synced crypto holding' identifies the target. However, it does not explicitly name alternatives or state when not to use it, so usage guidance is only implicit.

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

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

The destructiveHint annotation is supplemented well by the description: it discloses that transactions, rules, recurring items, and balance history can be optionally removed, and explicitly warns that both deletion options are irreversible. This adds meaningful behavioral context beyond the annotation.

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

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

The description is compact and well-structured: the primary action is front-loaded, the optional behaviors are summarized in a single sentence, and the irreversibility warning is placed directly after. No filler or redundant detail is present.

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

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

For a destructive tool with a simple required parameter and fully documented optional flags, the description covers the core operation, the cascading deletions, and the irreversibility warning. An agent has enough information to invoke the tool correctly without missing critical details.

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

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

The input schema already documents all three parameters with 100% coveragecars. The description's mention of transactions, rules, recurring items, and balance history mostly mirrors the schema's property descriptions rather than adding new semantic meaning, so it stays at the schema-covered baseline.

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

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

The description opens with a specific verb and resource: 'Delete a manually-managed account.' This immediately identifies the operation and, alongside sibling tools like delete_manual_crypto, clearly distinguishes this as the deletion tool for manual non-crypto accounts.

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 how to use the optional cascade flags, which is useful for invoking the tool correctly. However, it does not explicitly state when to prefer this tool over sibling deletion tools such as delete_manual_crypto or delete_account_balance_history, leaving that distinction to be inferred from the tool name.

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

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

Beyond the destructiveHint annotation, the description adds critical behavioral detail: the operation is irreversible, and the API rejects the request if balance history exists and keep_history is not explicitly set. This materially changes how the agent should invoke 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?

Three short sentences, each earning its place: one identifies the target, one states the critical precondition, and one states irreversibility. There is no filler, repetition, 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?

With complete parameter schemas, a destructiveHint annotation, and the description covering the key behavioral caveat, the agent has everything necessary to call this tool correctly. The absence of an output schema does not create a gap for this straightforward deletion 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 description coverage is 100%, so the baseline is 3. The description reinforces the keep_history condition and notes the rejection consequence, but it does not add substantial new parameter-level meaning beyond what the schema already states.

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

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

The description states a specific verb and resource: 'Delete a manually-managed crypto asset.' The qualifier 'manually-managed' distinguishes it from sync-related sibling tools and leaves no ambiguity about what the tool operates on.

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

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

The description clearly frames the tool as applying to manually-managed crypto assets, which gives the agent a solid context for selection. It does not explicitly name a sibling alternative or state when not to use it, but the 'manually-managed' qualifier effectively excludes synced crypto operations.

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 annotation only signals destructiveHint=true. The description adds substantial behavioral detail beyond that: the HTTP 422 failure case, the structured dependents payload, and the disassociation behavior when force=true. This is exactly the kind of context an agent needs before invoking a destructive operation.

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

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

Two tight sentences deliver the core action, default failure behavior, and the force option with zero filler. The most important information is front-loaded, and every clause earns its place.

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

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

For a delete tool with annotations covering destructiveness and a schema covering both parameters, this description is complete. It explains the failure payload, the success path for forced deletion, and the disassociation effect. No additional context is necessary for an agent to call 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?

Schema description coverage is 100%, so the input schema already documents tagId and force, including the irreversibility of force. The description reinforces force's effect in the context of dependency disassociation, but it adds no genuinely new parameter-level semantics. 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 identifies a specific verb and resource: 'Delete a tag.' It goes beyond a simple action by explaining the default failure mode and the force option, making the tool's purpose unmistakable and distinct from create_tag, update_tag, and get_single_tag.

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

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

The description provides clear operational context: use default deletion for tags not in use, and set force=true when the tag must be deleted despite dependencies. It does not explicitly name alternatives or state when not to use this tool, but the tag-specific behavior is unambiguous.

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

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

The destructiveHint annotation already marks this as destructive; the description adds concrete behavioral context beyond it: failure on split/group transactions and their parents, the requirement to unsplit/ungroup first, and irreversibility. This is valuable, though it stops short of describing failure semantics (e.g., error type) 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?

Two sentences carry the full behavioral contract: the action, the key failure condition, the prerequisite action, and irreversibility. Every sentence earns its place, and the most important fact (what the tool does) is front-loaded.

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

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

For a single-parameter delete tool with a destructiveHint annotation and one complete schema description, the description covers the essential operational knowledge: scope, preconditions, and irreversibility. It omits return/error behavior, but that is minor for such a simple operation and no output schema exists.

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 covers 100% of the parameter documentation (transaction_id with a clear description), so the baseline is 3. The description does not add any additional parameter-level detail, but none is needed given the complete 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 a specific verb and resource: 'Delete a single transaction.' It distinguishes from siblings like delete_transactions_bulk and delete_transaction_group by emphasizing 'single' and by noting the split/group constraint. The scope is unambiguous.

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

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

The description gives clear usage context: this tool deletes exactly one transaction, and it explicitly warns that split/group transactions and their parents must be unsplit/ungrouped first. It does not name alternatives like delete_transactions_bulk or delete_transaction_group, but the 'single' qualifier and the precondition effectively route the agent away from incorrect 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?

The destructiveHint annotation already signals that the operation destroys data. The description adds the important caveat 'Irreversible,' which provides useful behavioral context beyond the annotation. It also identifies what is destroyed, but it does not describe response behavior, error conditions, or any cascading effects on the associated 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 two sentences: the first states the action, and the second delivers a meaningful caution about irreversibility. There is no filler, no unnecessary restatement of the schema, and the important warning is placed immediately after the verb.

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 one-parameter destructive action with full schema coverage and a destructive annotation, the description is nearly complete: it names the object, the effect, and the irreversible nature of the operation. The main gaps are explicit sibling distinction and expected return behavior, but those are minor for such a simple 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?

The schema fully documents the only parameter, file_id, with the description 'ID of the file attachment to delete,' so the semantic burden is already carried by the schema. The tool description adds no additional parameter-level detail beyond what the schema provides, warranting the baseline score of 3.

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

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

The description uses a specific verb and resource, 'Delete a transaction file attachment,' which clearly distinguishes it from broader transaction deletion tools like delete_transaction or delete_transactions_bulk. It is unambiguous about what action is performed. It does not explicitly name sibling tools for contrast, but the resource phrase 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?

No guidance is provided on when to use this tool versus alternatives, such as detaching a file vs. deleting the entire transaction, or when to avoid using it. The action is only stated directly, leaving the agent to infer usage context from the tool name and schema. There are no exclusions, prerequisites, or alternative routes 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 annotation destructiveHint=true already flags this as destructive, but the description adds critical nuance: it explicitly states that the original child transactions remain and revert to ungrouped normal transactions. This goes beyond the annotation to clarify the non-destructive effect on children, which is essential for an agent to avoid mistakenly thinking it deletes the entire group including children.

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 states the action and the critical caveat about child transactions. It contains zero filler and every word adds value, making it highly efficient and easy for an agent 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?

For a tool with a single required parameter, no output schema, and a destructive annotation, the description fully covers what an agent needs: the exact effect on child transactions and the parameter meaning is already in the schema. Nothing essential is missing.

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

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

The input schema provides 100% coverage for the single parameter transaction_id, describing it as 'ID of the transaction group (the group parent transaction) to delete.' The description adds no additional parameter semantics beyond what the schema already states, so it meets the baseline for full schema coverage without extra enrichment.

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 group', and immediately clarifies the nuanced behavior: it ungroups rather than deletes the underlying transactions. This distinguishes it from sibling tools like delete_transaction or unsplit_transaction by specifying the exact effect on child transactions.

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

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

The description provides clear context that this tool is for ungrouping while preserving the child transactions. However, it does not explicitly name alternative tools (e.g., delete_transaction for full deletion, unsplit_transaction for split transactions) or state when NOT to use this tool. The context is sufficient but lacks explicit 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?

The destructiveHint annotation is reinforced and expanded with valuable behavior: the operation fails on split/group-related IDs and is irreversible. This goes well beyond the annotation by telling the agent about failure conditions and the need to pre-process data.

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

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

Three short sentences with no filler. The core action, constraints, count limit, prerequisite, and irreversibility are all front-loaded and each sentence earns its place.

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

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

For a simple one-parameter destructive tool, the description covers the operation, constraints, prerequisite, and irreversibility. It does not describe the success/error response format, but there is no output schema and the behavior is otherwise sufficiently explained.

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 already fully describes the single parameter (array of transaction IDs, 1-500). The description adds context about split/group behavior but does not materially extend the schema's parameter documentation, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Bulk-delete transactions by ID'. It also adds a clear scope boundary (1-500 IDs), which distinguishes it from the singular delete_transaction sibling without needing to open schemas.

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

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

The description clearly conveys this is the bulk deletion path and provides an explicit precondition: IDs that are split/group parents or members must be unsplit/ungrouped first. It does not explicitly mention alternatives, but the 'bulk' framing and 1-500 limit make the intended use clear.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful scoping details like monthly granularity and single-account restriction. However, it does not disclose return format, pagination, or behavior for invalid/deleted accounts. This is adequate but not rich, matching the calibration where annotations carry the safety burden.

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 purpose, followed by a necessary prerequisite and an explicit alternative. Every sentence earns its place with no filler or redundancy.

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

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

For a read-only single-account query tool with 100% schema coverage and a readOnlyHint annotation, the description is complete enough. It tells the agent what the tool does, what to call first, and when to use a different tool. No critical invocation information is missing.

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

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

Schema description coverage is 100%, so the schema already documents account_type, account_id, start_month, and end_month with constraints and format rules. The description does not add parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('monthly balance history for a single account'), clearly differentiating it from broader or synced-crypto alternatives. It also explicitly names get_crypto_synced_balance_history as the tool for synced crypto, so an agent can distinguish it from siblings without opening the schema.

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

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

The description gives an explicit prerequisite: call get_all_manual_accounts, get_all_plaid_accounts, or get_all_manual_crypto first to discover ids. It also states a clear exclusion: use get_crypto_synced_balance_history for synced crypto holdings. This leaves little ambiguity about when to use this tool versus 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 readOnlyHint annotation already signals safety, and the description adds useful behavioral context: results are scoped to the user's account and returned in alphabetical order. It does not contradict the annotation.

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

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

Two short sentences with no filler. The main action and resource are front-loaded, and the sorting behavior is added in a single extra clause.

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

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

For a read-only list tool with fully documented optional parameters, the description is nearly complete. It covers scope and sort order; the only minor gap is not explicitly mentioning category groups, but the is_group parameter description fills that in.

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

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

Schema description coverage is 100%, so the format and is_group parameters are fully documented in the schema. The description adds no parameter-level meaning, so the 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 states a specific verb and resource: 'Get a list of all categories associated with the user's account.' It also adds a meaningful detail, alphabetical ordering, and clearly distinguishes itself from single-category or tag 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 listing use case is implied by 'all categories,' but the description gives no explicit guidance about when to choose this over get_single_category or the category CRUD siblings. No alternatives or exclusions are named.

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=true. Description adds that it returns a list and mentions the former name, but does not disclose other traits like pagination or data format.

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 with a parenthetical note, highly concise and front-loaded with the main action.

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

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

For a simple list tool with no parameters and no output schema, the description is fairly complete. It could mention pagination or output format, but the core purpose is clear.

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 0 parameters, so baseline is 4. Description does not need to add parameter meaning; it correctly describes the output.

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

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

Description clearly states it gets a list of manually-managed accounts, using specific verb and resource. It distinguishes from sibling tools like get_all_plaid_accounts and get_single_manual_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 on when to use this tool versus alternatives (e.g., get_all_plaid_accounts) or when not to use it. The description only mentions the former name 'assets'.

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 readOnlyHint annotation covers the safety profile, and the description adds the scoping context of 'associated with the user' and 'manually-managed.' However, it does not disclose potential pagination, return format, or other behavioral details, which would be useful for a list-returning endpoint.

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

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

The description is a single, front-loaded sentence that clearly conveys the action and target. Every word earns its place, with no redundant or vague phrasing.

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

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

This is a simple zero-parameter, read-only tool with no output schema. The description sufficiently states what it does and the scope, though it leaves the exact return structure unstated. Given the low complexity, this is nearly complete.

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

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

There are zero parameters in the input schema, so there is nothing to explain. The baseline of 4 applies as the description cannot add parameter-related meaning beyond what the empty schema already conveys.

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

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

The description states a clear verb ('Get'), a specific resource ('manually-managed crypto balances'), and a scope ('associated with the user'). It distinguishes from sibling tools like get_all_synced_crypto (manual vs synced) and get_single_manual_crypto (all vs single).

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 are no explicit exclusions or references to sibling tools like get_all_synced_crypto or get_single_manual_crypto, leaving the agent to infer usage from the 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 provide readOnlyHint=true, so the safety profile is clear. Description adds 'synced' context but no other behavioral traits (e.g., pagination, ordering).

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, front-loaded sentence with no unnecessary words. High 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 no params, simple read-only operation, and no output schema, the description is fully adequate. It specifies scope and source (Plaid synced accounts).

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

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

No parameters in input schema, so schema description coverage is 100%. Description doesn't need to add parameter info; baseline 4 for zero-param tools.

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

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

Description clearly states the tool gets a list of all Plaid (synced) accounts, using a specific verb ('Get') and resource. It distinguishes from siblings like get_all_manual_accounts and get_single_plaid_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 guidance on when to use this tool vs alternatives. The sibling names imply choices, but the description lacks when-to-use or when-not-to-use instructions.

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 readOnlyHint annotation, the description explains that synced accounts are web-app connected and not API-editable, adding meaningful context about data origin and constraints. It also mentions the nested per-symbol balance structure, providing additional behavioral detail without being verbose.

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 front-loads the primary purpose, the second adds essential context about the data source and limitations. 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 zero-parity, read-only list tool with no output schema, the description adequately conveys what is returned (synced accounts and per-symbol balances) and the operational context (web-app connected, not API-editable). It is complete for its 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?

The tool has zero parameters and an empty input schema, so schema coverage is 100%. The description doesn't need to explain parameters; the baseline for 0 params is 4, and this is met.

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 synced crypto accounts with their nested per-symbol balances. It distinguishes from siblings by specifying 'synced' versus manual accounts and 'all' versus single account tools.

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

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

The description provides context that synced accounts are connected via the Lunch Money web app and cannot be created/edited via API, implying this tool is for read-only retrieval of such accounts. It does not explicitly name alternatives but clearly sets expectations for when this tool applies.

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. Description adds no further behavioral details (e.g., pagination, sorting, or effect). Consistent but not additive.

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, front-loaded, no redundant words. Perfectly concise for a simple list 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?

Despite no output schema, description adequately describes return value (list of tags). No other context needed for this simple tool.

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

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

No parameters exist; description does not need to add parameter info. Baseline score for 0 params is 4.

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

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

Description clearly states verb (Get), resource (tags), and scope (user's account). It distinguishes from siblings like create_tag, delete_tag, update_tag, and get_single_tag.

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 versus alternatives like get_single_tag or other tools. No context on prerequisites or use cases.

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

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

Beyond the readOnlyHint annotation, the description discloses monthly granularity, the ephemeral calculated `current` entry, that the value may change between requests, and that only months with data are returned. This meaningfully affects how an agent should treat results, especially regarding caching.

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

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

Four short sentences with the main purpose front-loaded. Every sentence adds either scoping, behavioral, or default-value information, with no filler or redundancy.

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

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

For a read-only tool with zero required parameters and rich schema coverage, the description covers default behavior, granularity, and volatility. It does not detail the shape of each history entry, but the lack of an output schema makes that a minor gap rather than a critical omission.

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

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

The schema already documents both optional parameters with formats and constraints. The description adds the valuable default behavior when no month range is provided, which the schema does not state, so it goes beyond the baseline.

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

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

The description states a specific verb and resource: 'Get monthly account balance history across all accounts'. The 'across all accounts' scope and 'data behind the Net Worth views' context clearly distinguish it from single-account tools like get_account_balance_history.

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 'across all accounts' and Net Worth view context provide a clear use case, and the default no-range behavior is explicitly stated. However, it does not name alternative tools or say when not to use it, so it falls just short of full routing 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 provide readOnlyHint=true, so the description need not restate safety. The description adds value by enumerating the specific settings returned, which is useful behavioral context beyond the annotation.

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

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

The description is a single, well-structured sentence that front-loads the purpose and lists key fields 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?

With no parameters and readOnlyHint provided, the description covers the tool's purpose and return fields adequately. While it could mention the zero-param nature, the simplicity makes it sufficiently 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?

There are zero parameters, so the baseline is 4 per guidelines. The description does not need to add parameter info; the schema coverage is 100% and no parameters exist.

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 'Get' and the resource 'budget period and display settings' with a specific list of fields. The tool name 'get_budget_settings' uniquely identifies it among siblings like 'get_budget_summary', establishing clear differentiation.

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 or provide exclusions or alternatives. However, given the self-explanatory name and sibling tools, usage context is implied but not formally guided.

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

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

With readOnlyHint=true already present, the description adds useful behavioral detail: the returned per-category totals, the per-period breakdown behavior tied to include_occurrences, and the backing v2 GET /summary endpoint. It does not disclose pagination, errors, or rate limits, but the read-only safety profile is covered by 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 filler: the first states the core action and scope, the second lists return fields and key option behavior, and the third notes the backing endpoint. Information is front-loaded and 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?

Although there is no output schema, the description names the main returned fields and explains the key optional breakdown. All parameters are fully described in the input schema, and the read-only annotation covers safety. Minor gaps like top-level response shape for all optional flags are inferable from the schema descriptions, so the definition is sufficiently complete.

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

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

Schema description coverage is 100%, so the schema fully documents all seven parameters. The description adds a small amount of extra meaning by explaining include_occurrences as a per-period breakdown matching budget periodicity, but it does not need to repeat parameter details and does not materially enhance the schema beyond that.

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

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

The description starts with a specific verb and resource ('Get a summary of the user's budget for a specified date range') and lists the exact returned per-category fields. This clearly distinguishes it from budget mutation and settings tools like upsert_budget, remove_budget, and get_budget_settings.

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

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

The description implies read-only budget summary usage and explains when to set include_occurrences=true, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. Usage context is clear but left mostly to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the context that synced crypto is scoped per symbol and that this tool returns monthly history, which is useful but not a rich behavioral disclosure. 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?

Two sentences with zero redundancy. The first states the core purpose and identification method; the second clarifies the key distinction from a sibling tool. All information is front-loaded and every sentence earns its place.

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

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

For a simple read-only history tool with 4 parameters (2 required) and no output schema, the description provides enough context: it identifies the resource, scoping, and a key limitation (not available via get_account_balance_history). The optional date-range parameters are fully documented in the schema, and the absence of an output schema is not a critical gap for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema fully documents all four parameters, including optional start_month and end_month with patterns and constraints. The description itself only reiterates 'account id and ticker symbol', which adds no new meaning beyond the schema. With full coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get'), the resource ('monthly balance history for a synced crypto holding'), and the identifying parameters ('account id and ticker symbol'). It also distinguishes itself from a sibling tool, get_account_balance_history, by noting the per-symbol scoping, making it unambiguous for an agent.

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 names an alternative (get_account_balance_history) and explains why it should not be used for synced crypto ('scoped per symbol'), which is clear guidance for when to select this tool. However, it does not mention other closely related siblings like get_synced_crypto_balance (for current balance) or get_balance_history, so the guidance is not exhaustive.

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

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

Annotations provide readOnlyHint=true, so the description doesn't need to restate safety. It adds useful context about the `matches` object being populated based on the requested range, which is beyond the schema. However, it doesn't disclose default behavior when no dates are provided (e.g., current month) or pagination/limits.

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

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

Two sentences with no fluff. The core action and the key behavioral detail about `matches` are front-loaded. It's appropriately sized for the tool's complexity.

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

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

For a read-only list tool with 100% schema coverage, the description is mostly adequate. It could be improved by noting the default date range behavior (current month) and whether results are paginated, but these are minor gaps given the annotations and schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the key semantic that `matches` is populated based on the range, which helps understand start_date/end_date's purpose, but doesn't add much beyond that.

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

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

The description clearly states the tool retrieves recurring items for a date range and mentions the `matches` object population. It distinguishes itself from get_single_recurring_item by being a list operation, though it doesn't explicitly name that sibling.

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 recurring items within a date range, and the schema clarifies start/end date requirements. However, it doesn't explicitly state when to use this over get_single_recurring_item or other list tools, nor does it 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 declare readOnlyHint=true, so the description correctly adds the behavioral nuance that category groups return a list of children categories. This is extra context beyond the read-only flag, though it doesn't address additional behavior like error responses or nonexistent IDs; with annotations covering safety, this is adequate.

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

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

A single 16-word sentence that front-loads the main purpose and immediately states the key qualifier about category groups. No redundant 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?

For a simple one-parameter read tool with readOnlyHint=true and no output schema, the description covers what the tool returns (details plus children for groups) and the parameter is fully documented in the schema. It could be more explicit about the shape of 'details,' but nothing essential is missing.

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

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

Schema description coverage is 100%, and the schema already explains categoryId and instructs to call get_all_categories first. The tool description adds no param-specific meaning, so it meets the baseline 3 for high schema coverage.

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

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

Description states a specific verb ('Get details') and resource ('single category or category group'), and differentiates from siblings like get_all_categories by noting it returns a single item. The mention of children categories for groups adds further specificity, making the tool's purpose unambiguous.

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

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

The description implicitly conveys when to use it (when you need details on one category) and explicitly advises calling get_all_categories first to discover ids. It does not explicitly exclude alternatives or name sibling tools, but the context is clear enough; falls short of a 5 because no when-not-to-use guidance is given.

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

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

The readOnlyHint annotation already covers the safety profile, and the description aligns with it by saying 'get details.' The description adds the 'manual account' scoping but does not disclose response shape, error behavior, or other runtime traits beyond what the annotation and schema already imply.

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 efficient sentence that communicates the action, target, and discriminator with no wasted words.

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

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

For a simple read-only single-resource getter with one well-documented parameter and a readOnlyHint annotation, the description is largely complete. The only minor gap is that 'details' is slightly generic and could be more precise about what the response contains, but no output schema exists to fill that in.

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 accountId parameter is already described as 'Id of the manual account to query' with discovery guidance. The tool description adds little beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Get details') and identifies the exact resource ('single manual account') plus the selection mechanism ('by ID'). This clearly distinguishes it from get_all_manual_accounts and the analogous get_single_plaid_account sibling.

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 parameter description explicitly instructs the agent to call get_all_manual_accounts first to discover IDs, providing practical usage guidance. It does not explicitly state when not to use this tool versus alternatives, but the 'single manual account by ID' scoping makes the intended use clear.

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

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

The annotation readOnlyHint=true already declares this as a safe read operation, so the description does not need to repeat that. It adds the prerequisite discovery context, which is useful but not a deep behavioral trait. No additional behavior like error handling or response format is disclosed, so a baseline score of 3 is appropriate.

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

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

Two short sentences with no filler. The primary action is stated first, followed by a necessary prerequisite. The entire description earns its place and is immediately scannable.

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

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

For a simple one-parameter read-only tool with a high-coverage schema and readOnlyHint annotation, this description covers the essential context: what it does, how to identify the target, and how to discover valid IDs. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, and the parameter schema already describes crypto_id as 'Id of the manual crypto balance to retrieve.' The description merely says 'by ID' and refers to discovering ids via get_all_manual_crypto, which adds no new meaning beyond the schema. With the schema carrying full weight, a score of 3 is correct.

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 ('Get') and resource ('single manually-managed crypto balance') with a clear identifier ('by ID'). It distinguishes from siblings like get_all_manual_crypto and get_single_synced_crypto through the 'manually-managed' qualifier and singular form.

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

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

The description explicitly says 'Call get_all_manual_crypto first to discover ids', giving an actionable prerequisite and making the tool's position in the workflow clear. It does not explicitly state alternatives or when not to use this tool, but the sequencing instruction is strong enough to guide an agent.

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

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

Annotations already declare readOnlyHint=true, and the description consistently indicates a read-only retrieval. The description adds mild context by clarifying the account is Plaid/synced, but does not disclose return format, error behavior, or permissions. 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?

A single, compact sentence with no filler. The key facts—action, resource, and identifier—are front-loaded and immediately usable.

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

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

This is a simple one-parameter read-only lookup. The description plus schema fully cover what the agent needs to invoke the tool correctly, and the annotation covers the safety profile. No output schema is present, but 'details' is sufficient given the low complexity.

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

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

Schema description coverage is 100%, so the parameter is already documented. The description adds value beyond the schema by including a discovery prerequisite ('Call get_all_plaid_accounts first'), which helps the agent obtain a valid accountId.

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

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

The description states a specific action ('Get details'), a specific resource ('single Plaid (synced) account'), and the access method ('by ID'). This clearly distinguishes it from get_all_plaid_accounts and manual account 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 itself does not name alternatives, but the parameter schema explicitly instructs the agent to call get_all_plaid_accounts first to discover account IDs. This provides clear when-to-use context, though it lacks explicit exclusions or alternative tool routing.

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

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

With readOnlyHint=true, the safety profile is already covered by annotations. The description adds meaningful behavior by explaining that an optional date range populates the 'matches' object, which is not derivable from the annotations alone. There is no contradiction and no hidden side-effect implication.

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 short sentences with no filler. It front-loads the action and resource, then adds only the essential optional-date-range behavior, making every word useful.

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 getter with a fully documented parameter schema and a readOnlyHint annotation, the definition is complete enough to invoke correctly. It does not describe the full return shape or name alternative tools, but those gaps are minor here because the operation and its main behavior are clearly stated.

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 all parameters already have clear descriptions including formats and the dependency between start_date and end_date. The tool description adds no per-parameter meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Retrieve'), a clear resource ('single recurring item'), and a lookup key ('by ID'). The word 'single' also distinguishes it from the sibling get_recurring_items operation without needing to inspect schema.

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

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

The description implies a targeted get-by-ID use case and the schema adds a useful prerequisite ('Call get_recurring_items first to discover ids'). However, it does not explicitly state when to choose this tool over alternatives or when not to use it, so the routing is mostly implied.

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?

readOnlyHint=true already covers the safety profile, and the description adds useful context by stating the response includes the account plus all nested balances. It does not cover error behavior or response edge cases, but those are less critical given the annotation.

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

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

A single front-loaded sentence with no filler or redundant schema restatement. Every word contributes meaning, which is ideal for a one-parameter getter tool.

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

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

For a one-parameter, read-only lookup, the description plus schema and annotations provide enough information to select and invoke the tool correctly. It even states the return scope (account + nested balances), which is valuable because no output schema exists.

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 is fully documented in the schema with a clear description, so there is no coverage gap. The description's 'by ID' merely restates the schema's meaning without adding new semantic detail, earning the baseline score.

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

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

The description opens with a specific verb ('Get'), resource ('single synced crypto account'), and scope qualifier ('all its nested balances'). It is clearly distinct from sibling tools like get_all_synced_crypto and get_single_manual_crypto without requiring schema inspection.

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 'single' and 'by ID' phrasing gives clear context that this tool is for retrieving one specific synced crypto account rather than listing all of them. It does not explicitly name alternative tools, but the usage context is unambiguous for selection.

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

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

Annotations declare readOnlyHint=true, and the description's 'Get details' aligns with a safe read operation. The description adds no further behavioral detail such as return shape or error behavior, but for a read-only getter annotations already cover the key safety trait.

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 short sentence with no filler. It front-loads the verb, resource, and identifying concept, making it easy for an agent to parse quickly.

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 one-parameter, read-only lookup, the description and schema together provide enough information to invoke the tool correctly. The absence of a stated return format is a minor gap, but the operation is simple enough that the current definition is adequate.

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

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

The only parameter, tagId, is fully described in the schema with both its purpose and a discovery hint ('Call get_all_tags first to discover ids'). The description itself adds little beyond 'by ID', so with 100% schema coverage 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 uses a specific verb ('Get') and resource ('single tag by ID'), clearly distinguishing it from get_all_tags, which retrieves all tags. There is no ambiguity about what operation is performed.

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 parameter schema advises calling get_all_tags first to discover tag IDs, providing a concrete prerequisite for this tool. It does not explicitly list alternative selection criteria, but the 'single tag' phrasing and the sibling list imply when this tool is appropriate.

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 annotation readOnlyHint=true already covers safety. The description adds valuable behavioral detail by disclosing that the response always includes plaid_metadata, custom_metadata, files, and the children array for split/group parents. This goes beyond the annotation and helps the agent anticipate the response structure.

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, tightly written sentence that front-loads the core purpose and then efficiently explains the distinguishing feature. No wasted words.

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

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

For a simple read operation with one parameter and no output schema, the description covers the key differentiators and return characteristics. It doesn't mention error behavior or non-existence handling, but the annotation covers the read-only nature, making this adequate.

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

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

Schema coverage is 100% and the parameter transaction_id has a clear description. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get details') and resource ('a specific transaction'), and explicitly differentiates from the sibling get_transactions by listing the additional fields it returns. This makes the purpose unambiguous.

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

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

It provides clear context by contrasting with get_transactions, indicating when this tool is needed (when those extra fields are required). However, it doesn't explicitly state when not to use it or mention other alternatives, so it's slightly below a full 5.

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

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

With annotations providing readOnlyHint, the description adds value by specifying that the list is for manual tracking and that the symbols are prerequisites for create_manual_crypto. This clarifies the relationship to other tools and the nature of the data, going beyond the annotation without contradicting it.

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

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

The description is two sentences, front-loaded with the primary action, and the second sentence provides essential cross-tool context. No words are wasted, making it concise and well-structured.

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

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

For a simple zero-parameter tool with a readOnlyHint and no output schema, the description is complete: it explains what the tool returns (supported cryptocurrencies) and how the output should be used. No critical information is missing for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none is needed; the empty schema fully covers the parameters, and the description's focus on the output symbol is more relevant.

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 the list of cryptocurrencies supported for manual tracking,' which specifies the verb (get), the resource (cryptocurrencies), and the scope (supported for manual tracking). It distinguishes from siblings like get_all_manual_crypto and add_supported_cryptocurrency by clarifying its role as the supported list, not the user's tracked list or the add operation.

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

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

The description gives clear guidance on when to use this tool: before calling create_manual_crypto, since the symbol must come from this list. It does not explicitly mention alternatives or exclusions, but the connection to create_manual_crypto provides strong contextual usage direction, so it earns a 4 rather than a 5.

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

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

Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds only minimal behavioral context—that a single balance is returned—and does not disclose not-found behavior, return format, or whether the balance represents the current/latest value.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and lookup mechanism.

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

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

The description is adequate for a simple read-only lookup with fully documented parameters, but since there is no output schema, the return format is not explained. It also does not provide any explicit contrast with closely related siblings like get_crypto_synced_balance_history or get_single_synced_crypto.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description's phrase 'looked up by its cryptocurrency symbol' maps to the symbol parameter and 'synced crypto account' maps to crypto_id, but it adds no new constraints or format details beyond the schema.

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

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

The description uses a specific verb ('Get'), identifies the resource ('a single balance held inside a synced crypto account'), and states the lookup key ('by its cryptocurrency symbol'). This clearly differentiates it from siblings such as get_all_synced_crypto and get_crypto_synced_balance_history.

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 intended usage is implied: use this to fetch one current balance by symbol rather than account details or balance history. However, the description does not explicitly name alternatives or state 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?

Beyond the readOnlyHint annotation, the description reveals that the URL is short-lived and signed, and that the response includes an expires_at timestamp. This adds useful behavioral context not present in the schema or annotations, though it does not specify the expiration duration or any authentication 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 just two sentences with no redundancy. It front-loads the core action and then adds the essential response detail. Every sentence earns its place.

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

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

For a one-parameter read-only tool with no output schema, the description provides the key return elements (URL and expires_at) and communicates the temporary nature of the URL. An agent has enough information 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?

Schema description coverage is 100%, and the file_id parameter is already described as 'ID of the file attachment.' The description does not add further parameter semantics, 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 a specific verb and resource: 'Get a short-lived signed download URL for a transaction file attachment.' The qualifiers 'short-lived signed' and 'download URL' make the tool's exact purpose clear, distinguishing it from attachment-management siblings.

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

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

The use case is clear from the description: retrieve a temporary download link for a file attachment. It does not explicitly name alternatives like attach_file_to_transaction or delete_transaction_attachment, nor provide explicit when-not-to-use guidance, so it stops short of a 5.

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

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

Annotations only declare readOnlyHint=true. The description adds valuable behavioral detail beyond that: pagination signaling with has_more, the limit cap, and the non-obvious exclusion of pending and split-parent/group-child transactions by default. 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, with the action front-loaded and behavioral details kept tight. The phrase 'and more' is slightly vague but does not add meaningful bloat.

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

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

For a 20-parameter read-only tool with 85% schema coverage and no output schema, the description covers the key invocation details: filter scope, pagination, and default exclusions. It could say more about the overall response shape, but the provided information is adequate for correct use.

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

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

Schema description coverage is 85%, so the schema already documents most parameters well. The description enumerates filter categories but does not meaningfully explain any parameter beyond what the schema states; its main added value is the aggregate filter/behavior context.

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

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

The description uses a specific verb and resource ('Retrieve transactions') and names the main filter dimensions, clearly distinguishing it from single-transaction retrieval. It does not explicitly call out a sibling tool, but the plural collection semantics make the distinction clear.

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

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

The description gives clear context on how to use the tool: optional filters, limit default/max, pagination via has_more, and default exclusions. It does not explicitly state when not to use it or name alternatives like get_single_transaction, but the guidance is sufficient for basic selection.

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

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

The readOnlyHint annotation already indicates it's a safe read operation. The description adds no further behavioral details, but does not contradict the annotation. Given the annotation coverage, this is adequate.

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

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

The description is a single concise sentence that immediately conveys the tool's purpose with no wasted words.

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

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

Given no parameters and no output schema, the description fully explains what the tool does. The sibling tools list provides context, but the description itself is complete for its 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?

There are no parameters, so the schema provides complete coverage. The description adds no additional parameter info, but none is needed. Baseline for 0 params is 4.

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

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

The description clearly states 'Get details on the current user', which is a specific verb-resource combination. It distinguishes itself from sibling tools like get_budget_settings or get_transactions by explicitly targeting the current user.

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 context (retrieving current user details) but does not explicitly state when to use this tool over alternatives. Still, it is clear enough for an agent to infer its purpose.

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 openWorldHint annotation already signals external-world interaction, and the description makes this concrete by stating 'Reaches out to the external crypto provider.' It does not go further to explain failure modes, latency, or whether existing balance history is affected, but it does disclose the core external side effect.

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 deliver the action, resource, return value, and external behavior with no filler. The most important information is front-loaded.

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

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

This is a single-parameter tool with a fully described schema. The description adds the return value and external-provider behavior, which is useful since there is no output schema. It lacks deeper guidance about error handling or alternatives, but is adequate for a simple trigger operation.

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

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

The input schema has 100% coverage and describes crypto_id as 'Id of the synced crypto account to refresh.' The tool description repeats essentially the same information without adding new parameter-level meaning, so it stays at the schema-mediated baseline.

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

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

The description states a specific action ('Trigger a balance refresh'), a specific resource ('synced crypto account'), and the expected return value ('return the refreshed account'). It clearly distinguishes this from sibling read-only tools like get_synced_crypto_balance or get_single_synced_crypto.

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

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

The description gives clear context: it is for synced crypto accounts and involves reaching out to the external crypto provider. It does not explicitly name alternatives or exclusions, but the 'synced' qualifier and refresh action make the intended use reasonably clear.

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

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

The annotation already marks the tool as destructive (destructiveHint: true). The description adds valuable context by disclosing idempotency — that it succeeds even if no budget exists. This goes beyond the annotation and helps the agent understand edge-case behavior without errors.

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, and the core action is front-loaded. The idempotency detail is a valuable addition without bloating the description.

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

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

For a simple delete tool with two fully documented parameters and annotations covering destructiveness, the description covers all essential aspects. It does not describe return values, but for a removal operation this is typically implicit and not critical given no output schema.

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

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

Schema coverage is 100%, with both start_date and category_id having clear descriptions. The tool description does not add extra meaning beyond the schema, merely referencing 'specific category and period' which maps directly to the parameters. 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 a specific verb (remove) and resource (budget) with a scope (specific category and period). It distinguishes itself from siblings like upsert_budget and get_budget_summary by focusing on removal. The idempotency note further clarifies its purpose.

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

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

The description implies when to use this tool (when removing a budget), but does not explicitly mention alternatives or when not to use it. Given the straightforward nature of a delete operation, the context is reasonably clear, but it lacks explicit routing to sibling tools like upsert_budget for create/update 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 provide only idempotentHint: false, so the description carries the burden of behavioral disclosure. It adds a valuable behavioral trait beyond the schema: after splitting, the parent is hidden from get_transactions but remains accessible via get_single_transaction with a children array. This helps agents understand side effects, though it does not detail reversibility or failure modes.

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 carry all essential information with no filler: the operation, the count range, the sum constraint, and the post-split behavior. The most important facts are front-loaded, and every clause 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?

The description, combined with the rich schema, covers the core requirements: range, amount equality, and the parent's post-split visibility. Since there is no output schema, a note about return values could be helpful, but it is not essential for invoking the tool correctly. The only notable omission is guidance about reversing a split via unsplit_transaction, which is available among siblings.

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

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

Schema description coverage is 100%, so the schema already documents transaction_id and all child_transactions fields, including defaults and the sum constraint. The description restates the sum requirement but does not add significant parameter-level meaning beyond what the schema provides, matching the baseline for full schema coverage.

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

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

The description clearly states the verb ('split'), resource ('existing transaction'), and scope ('into 2-500 child transactions'), making the core purpose unambiguous. However, it does not explicitly distinguish itself from the sibling tool unsplit_transaction, so it misses the highest bar for sibling differentiation.

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 when to use the tool—when an existing transaction needs to be split into multiple children—and gives important context about the post-split visibility of the parent. It does not explicitly state when not to use it or mention the alternative unsplit_transaction for reversal, so the guidance remains implied rather than explicit.

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

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

The description discloses two important behavioral aspects: a minimum 60-second delay between fetch requests and a maximum 5-minute fetch duration. These are not captured by the annotations (only openWorldHint is set), so the description adds valuable context beyond structured fields. 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 two sentences, front-loaded with the core purpose and then presenting optional parameters and a critical operational note. Every sentence serves a purpose, and the structure is logical 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 trigger tool with no output schema and straightforward parameters, the description covers the purpose, options, and rate limiting. The only minor gap is the lack of mention of the return value or confirmation behavior, but this is not critical for an agent deciding to invoke the tool. The tool is adequately specified for its complexity.

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

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

The input schema already provides complete descriptions for all three parameters (100% coverage), so the description's mention of optional scoping adds only a high-level summary. It does not introduce new semantics or format details beyond what the schema offers, aligning with the baseline score for full schema coverage.

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

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

The description states a specific action ('Trigger a fetch of latest data from Plaid') with a clear resource and purpose, and it distinguishes itself from sibling tools by focusing on Plaid data fetching rather than queries or updates. It also mentions optional scoping, which adds clarity without confusion.

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

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

The description explains when to use the tool (to fetch latest data) and describes optional scoping parameters (date range, account ID). It does not explicitly state when not to use it or name alternatives, but given the sibling set, no direct alternative exists for triggering a Plaid fetch, so the guidance is sufficient.

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

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

Annotations already declare destructiveHint: true, and the description adds meaningful detail: it discloses that children are deleted and the parent is restored. This goes beyond the annotation by explaining exactly what destructive effect occurs, without contradicting the annotation.

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

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

The description is two sentences with zero redundancy. The first sentence states the purpose, the second delivers the essential usage hint. It is front-loaded and 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?

With only one parameter, a clear operation description, and destructiveHint annotation, the definition covers everything an agent needs to call the tool correctly. There is no output schema, but none is needed for an action that returns a simple result. Error cases are not mentioned, but that is not expected for such a targeted 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 describes transaction_id with guidance to use split_parent_id, and the description reinforces the critical caveat to pass the parent, not a child. Together they fully clarify the parameter's semantics, eliminating ambiguity about which ID to use.

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

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

The description states a specific verb ('Unsplit') and resource ('transaction'), and explains the action precisely: 'deleting its children and restoring the parent.' It clearly differentiates from the sibling 'split_transaction' and from generic delete tools like 'delete_transaction' by clarifying the operation is a reversal of a split, not a full deletion.

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

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

The description gives clear context for when to use it ('previously split transaction') and a critical usage instruction: 'Pass the parent (split_parent_id) — not a child — as the path id.' This guides correct invocation, though it does not explicitly compare to alternatives like delete_transaction. The condition is clear enough for an agent to select it correctly.

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 goes beyond the idempotentHint annotation by surfacing the destructive replacement semantics for category-group children and the conversion restriction. It does not mention response shape, permissions, or partial-update behavior, but those are less central given the annotation and existing 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?

Three sentences, no filler; the primary purpose comes first and the critical guardrail is last. Every sentence carries meaningful selection or behavioral 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 the most important domain semantics (update scope, child replacement, no conversion), but with no output schema and multiple undocumented boolean parameters, an agent still has to infer response and partial-update behavior. It is adequate but not fully complete for a 9-parameter mutation tool.

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

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

The description reinforces the children parameter's group-only behavior and the category/group distinction, but it mostly restates what the children schema already documents. With 56% schema coverage the description should compensate for the undocumented booleans (archived, is_income, exclude_from_budget, exclude_from_totals), but it 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?

The description uses a specific verb and resource ('Update properties for an existing category or category group') and immediately distinguishes the tool from create/delete siblings by explicitly prohibiting conversion between the two forms. It also names the special category-group child replacement behavior, so an agent can tell what this tool is for without opening the schema.

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

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

It gives clear context that this is for updating existing categories or groups and an explicit when-not ('Cannot be used to convert between category and category group'). It stops short of naming sibling tools such as create_category or delete_category as alternatives, so it is not a full 5.

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

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

Beyond the idempotentHint annotation, the description discloses a nontrivial side effect: changes apply to all historical entries for that deleted source, and null clears fields. This gives the agent important awareness of the update's global reach. It does not mention authorization or rollback, but the annotations and expected update semantics cover the main safety 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?

Three short sentences, all informative. The core behavior is front-loaded, and the constraint and clearing semantics are stated in minimal, unambiguous wording.

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 seven-parameter update with a complete schema and no nested objects, the description covers the critical context: historical-entry scope, the at-least-one-field requirement, and null semantics. The only minor gap is the absence of a return-value description, but no output schema exists to clarify it.

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

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

Schema coverage is 100%, so each parameter is already documented in the schema. The description adds value by stating that at least one field must be provided and by clarifying that null means 'clear this field', which the per-parameter schema descriptions do not explicitly communicate.

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?

Identifies the exact operation (update), the exact target (display details of a deleted account), and the affected scope (Net Worth views / historical entries). This distinguishes it from the many other update_* siblings, none of which target deleted-account display metadata.

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

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

The description clearly states when it applies: to deleted accounts shown in Net Worth views. It also gives practical usage guidance: at least one field must be provided and null clears a field. It does not explicitly name an alternative tool or state when not to use it, but the deleted-account scope makes the choice unambiguous against the sibling list.

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

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

The description adds no behavioral detail beyond the obvious update operation NK. It does not mention partial-update semantics, how missing fields are handled, whether null values clear fields, or any permission requirements. The idempotentHint annotation covers idempotency, but the description itself contributes little.

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 short and front-loaded, with the core action stated in the first clause. The 'Formerly update_asset' note is a minor useful migration hint and not excessive. However, the brevity comes at the cost of behavioral substance, so it is not a perfect 5.

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 11 parameters, no output schema, and sparse annotations, the description is far too thin. It fails to explain update semantics, the scope of mutable fields, or how this relates to the surrounding manual-account workflow. An agent would still need to infer most invocation requirements from the schema alone.

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 9%, and the description provides no additional meaning for any of the 11 parameters. It does not mention updatable fields, required accountId, or the meaning of optional fields like closed_on or exclude_from_transactions. The description fails to compensate for the schema's lack of parameter documentation.

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

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

The description clearly identifies the action ('Update') and the resource ('an existing manually-managed account'), which distinguishes it from crypto, synced, and Plaid account tools. It does not explicitly contrast with siblings like update_deleted_account_details, but the resource phrase 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?

No guidance is provided about when to use this tool versus the many sibling tools, such as update_manual_crypto, create_manual_account, or delete_manual_account. The description simply states the action without explaining which scenarios warrant this tool or when to choose an alternative.

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 annotation only declares idempotency, so the description adds useful behavioral context: the symbol cannot be changed and at least one updatable field is required. The description does not overstate side effects and aligns with the schema's manual/synced distinction.

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 short, front-loaded sentences state the operation, the precondition, and the key limitation. Every sentence earns its place, and there is no repetition of schema details 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 five-parameter update tool with no output schema, the description plus schema covers the essential invocation requirements: what to update, what fields are needed, and what cannot be changed. It omits return-value details, but that is a minor gap given the strong schema and the availability of sibling retrieval 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?

Since schema description coverage is 100%, the schema already documents each parameter well. The description adds meaning beyond the schema by stating the 'at least one of' constraint and the immutability of the symbol, neither of which is captured in the JSON Schema required list.

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

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

The description opens with a specific verb and resource, 'Update a manually-managed crypto balance,' which clearly distinguishes this from create/delete/get siblings. It also limits scope to manually-managed balances, so there is little ambiguity about which crypto entity it targets.

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 a clear precondition ('At least one of name, display_name, institution_name, or balance must be supplied') and an exclusion (synced balances cannot be updated), which prevents invalid calls. It does not explicitly direct the agent to an alternative tool for creating or updating synced crypto balances, so it falls just short of a 5.

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

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

Annotations provide idempotentHint: true, and the description does not contradict this. However, the description adds no behavioral context beyond the basic action: it does not disclose that only provided fields are updated (partial update), any required permissions, or the effect on unmentioned properties. With annotations covering idempotency, the description still fails to provide additional behavioral transparency expected of an update tool.

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

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

The description is a single, short sentence with no unnecessary words. It is appropriately concise for a simple update operation, front-loading the verb and resource. Every word earns its place, making it efficient and clear.

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

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

With six parameters, low schema coverage, no output schema, and only an idempotentHint annotation, the description is insufficient. An agent cannot tell which properties are updatable, whether updates are partial or full, or any validation rules. The description covers only the basic intent, leaving significant gaps for an agent to infer.

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 17% (only tagId has a description), and the description itself does not elaborate on any parameters. It only implies the need for an existing tag, which hints at tagId being required. Given the low coverage, the description should compensate by explaining the other fields (name, archived, text_color, description, background_color) or their constraints, but it 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?

The description clearly states the verb 'Update' and the resource 'existing tag', distinguishing it from create_tag (creates a new tag), delete_tag (removes a tag), and get_single_tag (retrieves a tag). It is specific about the action and target, though it does not explicitly list which properties can be updated, leaving that to the schema.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies you use it when you need to modify an existing tag, but it does not mention when not to use it (e.g., for creation or deletion) or reference any sibling tools. There is no exclusionary context provided.

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

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

The description adds a behavioral constraint beyond the idempotentHint annotation: the restriction on split/grouped transactions, and the v2 API envelope change which is important for agents that may have learned the older wrapper format. It doesn't contradict the annotation and adds meaningful context, though it doesn't describe side effects like balance updates (though update_balance is in 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?

Two sentences with zero waste. The core purpose is front-loaded, the envelope change is stated in a parenthetical, and the restriction/alternative is given in the second sentence. 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?

Despite being a complex tool with a nested update object and three parameters, the description covers the essential usage (how to update, what not to touch) and routes to alternatives. The schema already details all parameter constraints and mutual exclusions, so nothing an agent needs to call correctly is missing.

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

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

Schema coverage is 100% and all parameters have inline descriptions, so the schema carries the burden. The description's note about 'any subset of writable fields directly' adds a slight semantic hint about the update object structure but doesn't go beyond what the schema already implies. This is the baseline 3 for full schema coverage.

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

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

States a specific verb and resource ('Update an existing transaction') and immediately clarifies scope: it cannot modify split or grouped transactions, which distinguishes it from sibling tools like split_transaction or create_transactions. The purpose is unambiguous and unique among the many transaction-related siblings.

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

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

Explicitly says when NOT to use it ('Cannot modify split or grouped transactions') and names the alternative ('use the corresponding split/group tools instead'). Also instructs how to provide fields ('any subset of writable fields directly'), giving clear usage context without needing to infer.

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

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

Annotations provide idempotentHint=true, which is a key behavioral trait. The description does not contradict this, but also doesn't add much beyond the constraint that split/grouped transactions cannot be modified. It doesn't disclose any side effects (like whether updates are atomic) or how the response might be structured, which is a minor gap given the annotation already covers idempotency.

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