Smart Money

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

The description adds meaningful behavioral context beyond the annotations: it states that already-posted periods are never duplicated, making repeated calls safe. This complements the idempotentHint annotation with a concrete explanation of the idempotency mechanism. It also clarifies the save-vs-preview behavior, which is not fully captured by annotations alone.

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

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

Three sentences, each earning its place: the first states the core action and scope, the second explains idempotency safety, and the third routes to the preview alternative. 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-parameter tool with an output schema and annotations covering idempotency and destructiveness, the description is nearly complete. It could mention what the output contains or whether the operation is reversible, but the output schema likely covers return values, and the idempotency statement already addresses the main safety concern.

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 schema provides no parameter semantics to clarify. The description compensates by explaining the scope of the operation ('all deposit and savings accounts up to today'), which is the only semantic an agent needs. Baseline 4 for zero-parameter tools 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 ('Calculates and saves interest'), the resource ('all deposit and savings accounts'), and the temporal scope ('up to today'). It also distinguishes itself from the sibling preview_interest by noting that this tool saves while preview_interest only shows amounts.

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

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

The description explicitly says when to use this tool (to post interest) and names the alternative (preview_interest) for when you want to see amounts without saving. This gives an agent clear 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 declare readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds the context that it accepts 'exactly specified fields', which is more about the input interface than behavioral side effects. It does not disclose whether the operation is idempotent, how it handles validation, or what happens on success/failure. Given the annotations cover the safety profile, a 3 is appropriate for adding limited behavioral context beyond the structured metadata.

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

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

The description is two sentences with no filler. The first sentence front-loads the purpose and the condition for use, and the second sentence provides a crucial pointer for ID sourcing. Every word earns its place, making it both concise and efficiently structured for quick agent comprehension.

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

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

The tool has 9 parameters, 3 required, and an output schema exists. The description covers the purpose and hints at ID sourcing, but it does not elaborate on the interplay of parameters (e.g., toAccountId only for transfers, date defaulting to today). While the schema itself documents some of these, the description could have highlighted the transfer-specific parameter or the validation constraints. For a moderately complex tool, the description is adequate but leaves the agent to infer several usage details from the schema.

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

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

Schema description coverage is 56%, meaning about half the parameters have descriptions in the schema. The description only adds a hint that account/category IDs come from list_accounts and list_categories, which is useful but does not explain the semantics of other parameters like date, note, merchant, tagIds, or toAccountId. With moderate coverage, the description should compensate for the missing parameter documentation, but it does not. It adds marginal value over the schema but does not fully fill the gap.

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

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

The description states a specific verb ('saves') and resource ('transaction'), and immediately clarifies the distinguishing use case ('for cases where phrase parsing does not fit'). This clearly separates it from the sibling quick_add, which likely handles phrase parsing. The mention of account/category IDs from list tools adds concrete context about the input sources, 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 explicitly indicates when to use this tool: when phrase parsing does not fit. This implies an alternative (likely quick_add) without naming it directly. It also gives a practical hint to source IDs from list_accounts and list_categories. However, it does not explicitly state when NOT to use it or mention other alternatives (e.g., update_transaction for edits), so it stops short of a full usage guideline.

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

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

Annotations already declare readOnlyHint=false, indicating a write operation, and destructiveHint=false, so the description does not need to restate mutation. The description adds the list of account types, which is more purpose-related than behavioral. It does not disclose any side effects, permission requirements, or operational constraints (e.g., idempotency, rate limits), so the added behavioral context is thin but not contradictory.

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

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

The description is a single sentence that front-loads the action ('Creates an account') and then lists the allowed types. It is concise and free of fluff, though the enumeration makes it somewhat long. Still, every word contributes to the purpose, so it is efficient and appropriately sized.

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 nine parameters and many optional fields having specific formats (e.g., last4 regex, maturesOn date, currency ISO code), the description provides no guidance on when each parameter is applicable or required. For instance, it does not explain that 'annualRatePercent' is only for interest-bearing accounts, or what 'last4' refers to. While an output schema exists, the input parameter usage remains unclear, leaving agents to guess about conditional fields and business rules.

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 44%, leaving five parameters (name, last4, maturesOn, institution, and kind's meaning) undocumented in the schema. The description only clarifies the 'kind' parameter via the account type list; it provides no guidance on the purpose or format of 'last4', 'maturesOn', 'institution', or the interplay of fields like 'annualRatePercent' with specific account kinds. Thus, it fails to compensate for the low 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 action (creates) and the resource (account), and enumerates the specific account types (cash, card, bank, deposit, savings, credit, investment, e-wallet) that map directly to the 'kind' enum. This distinguishes it from sibling tools like list_accounts, update_account, and delete_account. The only minor gap is not mentioning 'other' as a kind, but that does not undermine clarity.

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

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

Usage is implied by the name and description—use this when creating an account—but there is no explicit guidance on when not to use it or how it compares to other creation tools like create_budget or create_category. The description does not mention alternatives or exclusions, leaving the agent to infer from the tool name alone.

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

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

Annotations already indicate this is a mutable but non-destructive operation, so the description does not need to repeat that. It adds valuable behavioral detail by explaining that omitting categoryIds makes the budget cover all expenses and that a group category includes its subcategories, which clarifies the effective scope of the budget.

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 short sentences with no filler. The core action and period scope are front-loaded, followed by the categoryIds behavior and the cross-reference to list_categories. Every sentence adds information the schema does not already contain.

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

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

Given the output schema exists and the annotations cover mutability, the description is largely sufficient: it explains the budget scope, the meaning of categoryIds, and the source of category IDs. The only minor gap is that the required name parameter is not semantically described, though it is unlikely to cause invocation errors.

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 40%, but the description compensates for period and categoryIds by explaining the time periods and category scope semantics. It also points to list_categories as the source for valid category IDs. Name is left without semantic explanation, but it is a simple required label and the schema already enforces a non-empty string.

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 concrete verb and resource: "Creates a spending limit for a week, month or year, in the base currency." It clearly identifies the tool as budget creation and differentiates it from sibling tools like create_account, create_category, and update_budget by focusing on spending limits and budget scope.

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 useful context about how categoryIds affect the budget's scope and tells the agent that category IDs come from list_categories, which helps with prerequisites. However, it does not explicitly state when to prefer this tool over alternatives like update_budget or delete_budget, nor does it mention any exclusions or conflicts with other tools.

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

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

Annotations already indicate readOnlyHint=false, and the description simply confirms the create action. It adds only the 'top-level' qualifier, but does not disclose details like whether duplicate names are rejected, whether categories can be deleted, or what the creation response contains.

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

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

A single sentence with no filler, and the most important scoping information ('top-level', 'expense or income') is placed upfront. 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?

The tool is relatively simple and the schema defines required fields and constraints, so an agent can probably invoke it correctly. However, the description omits any usage context or expected behavior beyond creation, and with an output schema present it could have briefly stated what the created category looks like.

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

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

Schema description coverage is only 25%, so the description needs to compensate, but it does not explain the name, icon, or color parameters. It only implicitly maps the 'expense or income' wording to the 'kind' enum, which is a small contribution.

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 ('Creates'), a clear resource ('category'), and a distinguishing scope ('top-level expense or income'). This differentiates it from sibling tools like update_category or delete_category 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 gives no guidance on when to use this tool versus alternatives such as update_category, delete_category, or list_categories. It also does not explain when a top-level category is appropriate or how this relates to other category 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?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description adds meaningful context by revealing the restore behavior: a deleted tag with the same name is restored instead of creating a duplicate. This is useful non-obvious behavior beyond the annotations.

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

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

Two sentences with no filler. The core action and definition are front-loaded, and the important restore behavior is stated second without unnecessary detail.

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

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

For a simple two-parameter creation tool with an output schema and full schema coverage, the description provides enough context. The cross-category semantics and the restore edge case are the main behavioral details an agent needs, and both are present.

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

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

Schema coverage is 100%: both name and color are already documented in the input schema, including the color pattern and palette fallback. The description adds illustrative tag name examples but does not need to compensate for any schema gaps.

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 ('Creates a tag') and defines what a tag is — a label marking transactions across categories — with concrete examples. This effectively distinguishes tags from categories and from sibling tools like update_tag or delete_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 implies when to use this tool by explaining that tags label transactions across categories, but it never explicitly names alternatives or states when not to use them. There is no mention of create_category, even though that sibling is the closest 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?

Annotations already cover destructiveness and idempotency, but the description adds a crucial operational constraint: deletion only succeeds for accounts with no transactions. This goes beyond the annotations by explaining the failure condition and suggesting fallback actions, which is valuable context not captured elsewhere.

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 redundancy: the core action and condition are first, then the alternative path, then the ID source. Every sentence earns its place, and the most critical 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?

The tool is simple (one parameter) and the annotations cover the destructive and idempotent aspects. The description supplies the missing behavioral rule (no transactions) and the sibling alternative. With an output schema present, return values need not be described. Nothing critical is omitted.

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 the single parameter id with 100% coverage and a clear description. The tool description echoes the same ID source ('Account IDs come from list_accounts'), adding minimal new information. Since the schema already documents the parameter, 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 provides a specific verb and resource ('deletes an account') plus a critical precondition ('has no transactions'), which clearly distinguishes this tool from other delete_* siblings. It also references the alternative archiving mechanism, making the purpose unmistakable.

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

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

Explicitly states when to use this tool versus alternatives: 'An account with history cannot be deleted — archive it with update_account (archived: true) or delete its transactions first.' It also specifies the ID source via list_accounts, giving clear prerequisites and exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the valuable side effect that transactions are not affected, which goes beyond the hints. It doesn't elaborate on error handling, but the key behavioral traits are covered.

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, with the primary action and critical side effect front-loaded. 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?

For a simple delete operation with an output schema present, the description covers the core action, the important side effect on transactions, and the ID source. It's adequate, though it could explicitly mention idempotency, but that's already in annotations.

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

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

Schema coverage is 100% and the schema already describes the parameter as 'Budget ID (see list_budgets).' The description echoes this same guidance without adding new format or syntax details, so it adds minimal value beyond the schema.

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

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

The description clearly states the tool deletes a budget, a specific verb and resource. It distinguishes itself from sibling delete tools by explicitly noting that transactions are not affected, making the purpose unambiguous even without naming alternatives.

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

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

It provides a clear prerequisite: 'Budget IDs come from list_budgets,' guiding the agent to fetch IDs from the correct source. It doesn't explicitly state when not to use this tool (e.g., vs. update_budget), but the context is sufficient for typical selection scenarios.

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

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

Annotations already declare destructive behavior and non-read-only intent, so the description only needs to add context, and it does: eligibility preconditions, the system-category restriction, and a pre-migration path. It does not spell out exact error behavior when constraints are violated, but the annotations and output schema cover the core safety profile.

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 carry only necessary information, with the action and primary precondition first followed by the exception and ID source. No filler or redundancy.

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

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

Given a single required parameter, full schema coverage, annotations for safety/idempotence, and an output schema, the description provides the missing operational context: preconditions, system-category exclusion, the transaction-migration alternative, and where IDs come from.

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 the single id parameter at 100% coverage, so the baseline is 3. The description's 'Category IDs come from list_categories' largely repeats the schema's 'see list_categories' and adds no new format or source detail.

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

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

The description uses a specific verb and resource ('Deletes a category') and immediately adds the defining constraints: no transaction use and no subcategories. This clearly distinguishes the operation from other delete tools and from update_transaction.

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

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

The description states when deletion is valid ('no transaction uses', 'no subcategories'), when it is not valid ('System categories cannot be deleted'), and the alternative workflow for moving transactions first with update_transaction. It also directs the agent to list_categories for valid IDs.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description goes beyond them by explaining the actual impact: the tag is no longer selectable yet remains on historical transactions, preserving report integrity. This is valuable context that annotations alone do not convey.

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

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

The description is two sentences with zero waste: it states the action, the key behavioral nuance, and the ID source. The most important information (deletion effect) 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 single-parameter tool with a fully covered schema and an output schema present, the description is complete. It explains the operational effect (soft delete) and the source of the ID, leaving no critical gap for correct invocation.

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

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

Schema description coverage is 100% because the 'id' property is described as 'Tag ID (see list_tags).' The description repeats this ('Tag IDs come from list_tags') but adds no new semantics beyond reinforcement. Per the rubric, baseline 3 is appropriate when the schema already covers parameters.

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

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

The description states a specific verb ('Deletes') and resource ('a tag') and immediately clarifies the behavioral consequence: the tag can no longer be chosen but remains on existing transactions, so past reports are unaffected. This distinguishes it from sibling delete tools (e.g., delete_category, delete_budget) by describing the soft-delete semantics unique to tags.

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 defines when to use the tool (to remove a tag from future choices) and explicitly instructs that 'Tag IDs come from list_tags,' providing a prerequisite step. It does not name alternatives or exclusions, but the context is clear enough for an agent to select it over create_tag or update_tag.

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

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

Annotations already mark the tool as destructive and non-read-only, but the description adds valuable specifics: deletion removes the transaction from balances and reports across all devices. This goes beyond the generic destructiveHint and tells the agent the scope of side effects. No contradiction with annotations exists.

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

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

The description is a single, dense sentence that leads with the primary action und states the most important consequence and ID-source in order. Every phrase contributes practical information without 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 one-parameter, non-nested tool with output schema present, the description covers the core action, the key side effects, and how to source the ID. Combined with the annotations, this gives an agent everything needed to call 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 schema describes the single parameter 'id' as a Transaction ID and references list_transactions, and the description repeats this provenance. Since schema description coverage is 100%, the description adds no new parameter-level 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 uses a specific verb and resource ('Deletes a transaction') and goes beyond the title by stating the effect: 'removing it from balances and reports on all devices.' It clearly identifies this as the delete operation for transactions, which distinguishes it from sibling delete tools for accounts, budgets, categories, and tags.

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 practical usage context by stating that 'Transaction IDs come from list_transactions,' which tells the agent how to obtain the required identifier. It does not explicitly contrast this with siblings like update_transaction, but the resource type and ID-source guidance 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that 'notifications already imported are skipped,' which aligns with and enriches the idempotent hint. It also explains the write action ('saves') without contradicting annotations. No error or permission details, but the annotation coverage is strong enough that a 4 is warranted.

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 filler. The primary action is stated first, followed by key behavioral details (matching and deduplication) and a pointer to the sibling tool. 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?

The tool is moderately complex (parsing, matching, deduplication) but the description covers the essentials. An output schema exists, so return details need not be in the description. It lacks explicit error scenarios or permission requirements, but those are not critical for an agent to call it correctly given the annotations and clear guidance. Slightly incomplete but strong overall.

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

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

Schema coverage is 100% (the messages parameter has a description: 'Notification texts, one per element'). The description adds that it parses text and matches accounts, but does not elaborate on expected text formats or edge cases. Since the schema already documents the parameter type and purpose, the description provides only marginal extra value, keeping it at the baseline 3.

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

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

The description states a specific verb ('Parses', 'saves'), a clear resource (bank push notifications → transactions), and distinguishes itself from sibling preview_notifications by mentioning it explicitly. It also clarifies the account matching logic and deduplication, which separates it from 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?

It provides explicit guidance: 'Use preview_notifications to see the parse without saving.' This tells the agent when to choose the alternative and implies when this tool is appropriate (when saving is desired). The matching and skip behavior further define usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavior beyond that: it discloses that archived accounts are listed separately and that deposits include interest rates, which is useful for output interpretation. No contradiction with annotations.

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

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

Two concise sentences with no fluff. The main purpose and key behaviors are front-loaded, and every word adds value. The structure is clean and easy to parse.

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

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

For a zero-parameter, read-only list tool with an output schema present, the description fully covers what an agent needs to know: what accounts are returned, that archived ones are separate, and that deposits include interest rates. No missing operational 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 tool has zero parameters, so schema coverage is effectively 100%. Per the rubric, a baseline of 4 applies for 0-parameter tools. The description appropriately does not dwell on parameters since there are none.

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

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

The description is specific: it states the tool lists all accounts with balances, including deposits with interest rates, and notes archived accounts are listed separately. This clearly distinguishes it from sibling tools that handle budgets, transactions, or categories.

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

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

The description gives clear context on what the tool does (listing accounts), but it does not explicitly mention when to use it versus other tools like 'summary' or 'list_transactions'. There are no exclusions or alternative routing, but the purpose is obvious enough for an agent to infer appropriate use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by detailing the specific data returned (limits, spent, remaining, projected) and the notion of a 'current period' and 'projected spending by end of period,' which goes beyond the annotation. 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 a single sentence that is clear and front-loaded with the primary purpose. It avoids fluff and effectively conveys the tool's output in a compact form.

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

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

The description is sufficient for a simple list tool with no parameters and an output schema present. It covers the key output fields but does not specify the definition of 'current period' or whether archived/inactive budgets are included. These are minor gaps given the tool's simplicity.

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

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

The tool has zero parameters and the schema is empty, so there is no parameter semantics to cover. Baseline is 4 given no parameters, and the description adds no parameter-related information, which is acceptable.

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

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

The description clearly states the tool's function: showing budgets with limits, spent, remaining, and projected spending. The verb 'Shows' and resource 'budgets' are specific, and the listed fields distinguish it from other list tools like list_accounts or list_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 implies that this tool is for retrieving budget information, but it does not explicitly contrast it with siblings like summary or other list tools. There is no guidance on when to use this versus alternatives, leaving the agent to infer usage from context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds two behavioral details beyond that: it only returns active categories, and it indents grouped categories. This adds useful context without contradicting annotations.

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

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

The description is two sentences, front-loads the core purpose, and has zero filler. Every sentence adds value: the first gives the purpose and usage context, the second clarifies the indentation behavior.

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 output schema exists, so return value details are presumably covered. However, the optional 'kind' parameter is entirely undocumented in both schema and description, which is a notable gap for a tool with an optional filter. The description covers the main use case but misses parameter semantics, so it is not fully complete.

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

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

The schema has one optional 'kind' parameter with an enum, but there is no description for it and the tool description never mentions it. With 0% schema description coverage, the description should compensate, but it does not address filtering by category type at all, leaving agents to guess.

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 ('Lists'), a clear resource ('active categories'), and the output includes IDs and indentation for groups. It distinguishes itself from sibling tools like list_accounts and list_tags by being explicitly about categories and even ties its use to add_transaction and filters.

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 by saying the result is for use in add_transaction and in filters, which implies when to call it. However, it does not explicitly state when not to use it or name alternatives, 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 already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds meaningful behavioral detail beyond that: each tag includes its ID and transaction count, and deleted tags are listed separately. This informs the agent about a non-obvious output 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?

Two sentences carry the full description with no filler. The core action and output are front-loaded, and the secondary detail about deleted tags is placed efficiently at the end.

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, parameterless list tool with a rich output schema available, the description covers the essential information: what is listed, what fields are included, and a notable edge case (deleted tags listed separately). No critical details are missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, and the schema confirms this. With no parameters to document, the description adds all necessary semantic context by explaining what the returned list contains and how it is meant to be used.

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 and resource ('Lists tags'), specifies the returned data (IDs and transaction usage counts), and distinguishes itself from sibling tools like create_tag and delete_tag by focusing on retrieval. The stated purpose for use in add_transaction, update_transaction, and list_transactions filters further clarifies its role.

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 names concrete use cases: supplying tag IDs for transaction-related filters. This provides clear context for when to call the tool versus alternatives like list_transactions or create_tag. It does not explicitly spell out when not to use it, but the stated purpose is sufficiently specific 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context, such as the option to filter and the search scope, but does not disclose pagination defaults, period resolution, or limit behavior, which would be useful beyond the annotations.

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

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

A single, well-structured sentence that front-loads the verb and resource, then lists the optional filters. No wasted words; every phrase contributes to the core purpose.

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

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

Given 9 parameters and an output schema, the description is minimal but functional. It does not mention defaults (period this_month, limit 50) or the relationship between from/to and period, though these are in the schema. The output schema reduces the need to describe return values, but the description could still benefit from a note on result size or pagination.

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 56%, and the description adds meaning by clarifying that 'search' applies to description and merchant, and grouping type/account/category as filters. However, it omits mention of tags, limit, and the period override logic, leaving some parameters under-explained relative to the coverage gap.

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

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

The description clearly states the verb 'Returns' and the resource 'transactions', along with the key filters (type, account, category, text search). It is distinct from siblings like add_transaction or list_accounts by its focus on listing transactions, though it does not explicitly contrast with any 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 transaction data but provides no explicit guidance on when to choose this over alternatives (e.g., summary, quick_add) or when not to use it. The lack of exclusions or alternative references leaves some inference to the agent.

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

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

The description contradicts the annotation readOnlyHint: true by stating that a #tag that does not exist yet would be created. Creation is a write operation, directly conflicting with the read-only hint. The description also fails to explain other side effects or the fact that previewing is non-destructive, but the contradiction is the dominant issue. This is a serious inconsistency that could mislead agents into expecting no modifications when the tool actually creates tags.

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

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

The description is two sentences, front-loaded with the core purpose ('Shows how a natural-language phrase would be recorded by quick_add, without saving anything'). Every sentence earns its place: the first defines the action and safety property, the second specifies input capabilities and the tag-creation caveat. 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 single-parameter preview tool with an output schema, the description covers the main behavior and input format. However, it omits details about what the preview returns (though output schema exists), and more importantly, it presents a conflicting side effect (tag creation) that is not reconciled with the readOnlyHint. This undermines completeness and could lead to incorrect agent assumptions. The description is adequate but not fully reliable due to the contradiction.

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 the sole parameter 'text' with an example, giving 100% coverage. The description adds value by explaining what the text can contain (amounts, dates, account names, #tags, currencies) and language support (English and Russian). This goes beyond the schema's generic example and helps the agent construct appropriate inputs, so a score above the baseline is warranted.

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

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

The description clearly states the tool's purpose: it previews how a natural-language phrase would be recorded by quick_add, without saving. It distinguishes itself from quick_add (which likely saves) and other preview tools by explicitly mentioning 'without saving anything'. The verb 'shows' and resource 'transaction phrase' are specific, and the mention of quick_add differentiates it from 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 description implies when to use this tool: when you want to see how a phrase would be interpreted before actually running quick_add. It names quick_add directly, making the alternative explicit. However, it does not state when not to use it or mention other preview tools (preview_interest, preview_notifications), so it lacks explicit exclusions. The guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint and destructiveHint false; the description adds useful context by stating the operation posts nothing and computes interest 'up to today.' This goes slightly beyond the structured annotations by clarifying time scope and side-effect-free behavior.

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

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

A single sentence conveys the operation, the scope of accounts, the temporal boundary, and the non-persistent nature of the action. There is no redundant or filler content.

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

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

Given zero parameters, read-only annotations, and an existing output schema, the description covers everything an agent needs to invoke the tool correctly. It also addresses the main question of whether this tool mutates state.

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

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

The input schema has zero parameters, so the baseline is 4. The description's mention of 'up to today' explains why no date parameter is needed, and there is nothing else for it to clarify.

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 'Shows the interest accrue_interest would post on deposit and savings accounts up to today, without saving anything,' giving a specific verb, resource, scope, and side-effect distinction. It also differentiates it from the sibling accrue_interest by emphasizing this is a non-posting preview.

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 tells an agent to use this tool when wanting to see what interest would be posted without actually posting it, referencing accrue_interest as the actual posting action. It does not explicitly state exclusions or alternative conditions, but the context is clear enough for selection among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating the key non-destructive behavior ('without saving anything') and providing context about supported banks (Kaspi, Halyk, etc.) and language (Russian), which goes beyond what annotations convey. No contradiction with annotations.

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

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

The description is a single, focused sentence that front-loads the core action (parses notifications), the scope (banks), and the critical distinction (without saving). Every clause carries meaning, and there is no redundancy.

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

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

With an output schema present and annotations covering safety, the description sufficiently covers the purpose, supported banks, language, and the preview nature. It implicitly signals the relationship to import_notifications, though an explicit 'use this before importing' would make it fully complete. Overall, enough for an agent to invoke correctly.

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

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

The input schema has 100% description coverage for the 'messages' parameter ('Notification texts, one per element'). The tool description adds no additional parameter-specific semantics beyond confirming the input type, so it meets the baseline for high schema coverage but does not exceed it.

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

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

The description clearly states the tool's function: it parses bank push notification texts and shows the transactions that import_notifications would create, without saving. This is a specific verb+resource with explicit mention of the sibling tool it contrasts with (import_notifications), making the purpose unambiguous.

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

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

The description implies the usage context: use this tool to preview the effects of import_notifications before actually importing, since it explicitly says 'without saving anything' and references what import_notifications would create. However, it doesn't explicitly state exclusions or alternative conditions, leaving some inference to the agent.

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

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

The description discloses the key side effects beyond annotations: it saves a transaction and, notably, auto-creates any #tag that does not exist yet. It also states that preview_entry can be used to see the parse without saving, giving an accurate picture of mutating behavior.

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

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

Front-loaded with the core function in the first sentence, followed by compact examples and one routing tip. The example list is longer than strictly necessary but earns its place for a natural-language parser.

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 command with an output schema, the description supplies usage patterns, side effects, and a safe preview alternative. Nothing essential for an agent to call 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?

The schema already describes text as 'Phrase describing the transaction' (100% coverage). The description adds real value with concrete examples spanning amount, date, currency, transfer, and tag syntax, plus the tag-creation rule; it stops short of a formal grammar.

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-resource pair: 'Parses a natural-language phrase and saves it as a transaction.' It also distinguishes itself from the sibling preview_entry by explicitly offering it for preview, and the title 'from a phrase' separates it from the structured add_transaction.

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

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

The examples demonstrate the intended input style, and the closing sentence explicitly routes to preview_entry when the agent wants to avoid saving. It does not explicitly address the alternative structured add_transaction, so it is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds what the tool returns, which is useful behavioral context beyond the annotations. It does not mention any limitations, but none are obviously needed for a read-only summary.

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

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

A single, well-structured sentence that lists all key outputs without redundancy or extra fluff. 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?

The output schema exists (per context signals), so return values need not be detailed in the description. The description covers the key contents, and the schema covers parameters. No critical information is missing for an agent to decide whether to invoke this 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?

Both parameters (level and period) are fully described in the input schema with enum names and defaults (schema coverage 100%). The description adds no additional meaning beyond what the schema already documents, 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 clearly lists the outputs: income, expenses, net savings, category breakdown, and merchant frequency for a period. This specifies a distinct resource and differentiates it from transaction-level tools like list_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 purpose implies this tool is for period-level summaries, but there is no explicit guidance on when to use it over alternatives or any exclusions. Usage is inferred from the description rather than stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds valuable behavioral detail beyond annotations: null clears fields, archived hides history, annualRatePercent turns the account interest-bearing, and the currency restriction. 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?

A single, dense paragraph with no filler. The core action is front-loaded, and each clause adds distinct information. It avoids restating schema details, focusing only on behavior.

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 15-parameter schema and low description coverage, the description covers the most critical behaviors (null semantics, archiving, currency constraint, interest terms). The presence of an output schema reduces the need to explain return values. However, it omits behavior for fields like kind and openedOn, which might require inference, but overall it is sufficient for an agent to make correct update calls.

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

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

Schema coverage is low at 40%, so the description carries extra weight. It explains the semantics of null for institution, last4, note, creditLimit, and annualRatePercent, and clarifies the currency change restriction. However, it doesn't address parameters like kind, name, openedOn, includeInNetWorth, leaving some ambiguity, but the description compensates meaningfully for the coverage gap.

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

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

The description opens with 'Changes an existing account' – a specific verb and resource. It then enumerates the mutable fields and clarifies scoping (only passed fields change), which clearly separates it from create_account and delete_account. The mention of list_accounts for IDs further distinguishes the update workflow.

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?

While it doesn't explicitly say 'use this instead of create/delete', it provides a concrete usage rule: currency can only change when no transactions exist, and IDs come from list_accounts. This gives agents actionable constraints. It could be improved by explicitly stating 'for new accounts use create_account', but the context is 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?

Beyond annotations that already mark this as destructive and idempotent, the description discloses the partial-update behavior ('Only the fields passed are changed') and the special categoryIds semantics, including destructive list replacement and the empty-list case. This gives the agent a realistic model of what will happen.

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: the action is first, behavior follows, and the ID source is last. Every sentence adds distinct value with no 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 six-parameter mutation, the description covers the operation, partial-update rule, the tricky categoryIds behavior, and where IDs come from. Annotations carry the safety profile and an output schema exists, so nothing essential is missing for a correct call.

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

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

With only 33% schema description coverage, the description compensates for the least obvious parameter by explaining that categoryIds replaces the list and that an empty list means all expenses. It also points to list_budgets as the source of valid ids. Other parameters are simple or already described in the schema.

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

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

States a specific verb and resource ('Changes an existing budget') and clearly targets existing records, distinguishing it from create_budget and delete_budget among siblings. The wording 'existing' plus the update name leaves no ambiguity about the operation's scope.

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 conveys the usage context: it is for existing budgets and instructs the agent to get IDs from list_budgets. It does not explicitly name create_budget as the alternative for new budgets, but the 'existing' qualifier makes the intended case 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 annotations already declare destructiveHint=true and readOnlyHint=false, indicating mutation. The description adds that icon and color can be cleared with null, which is a behavioral nuance not obvious from the schema alone. It also mentions built-in categories are immutable. However, it does not disclose the exact effects of changing a category (e.g., whether it cascades to existing transactions), which would be valuable. Since annotations already cover the destructive nature, the description adds useful but not exhaustive 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 concise and well-structured, with two sentences. The primary purpose is front-loaded, followed by a key constraint (system categories), and then a pointer to where IDs come from. Every sentence adds value without redundancy. It is a model of efficient, useful 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?

The output schema exists, so no need to explain return values. The description covers the essential usage: what fields can be modified, the null-clearing behavior, the immutability of system categories, and how to obtain IDs. An agent has enough information to call this tool correctly. The idempotentHint suggests repeated calls are safe, which is consistent. The description is complete for this tool's complexity.

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

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

The schema coverage is 50% (only id and icon have descriptions, but name and color are missing). The description compensates by explaining the semantics of icon and color (they can be cleared with null) and provides domain context (category IDs come from list_categories, and system categories can't be changed). This adds meaning beyond the schema for at least the 'name' and 'color' parameters, which otherwise have no textual explanation. The description fully covers the missing schema details.

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

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

The description clearly states it renames a category or changes its icon or color, specifying the exact resource ('category') and the actions. It also highlights the special behavior of clearing icon/color with null, and distinguishes from siblings by noting built-in system categories cannot be changed and that IDs come from list_categories. This is a specific and differentiating 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 it: when you need to edit an existing category, as opposed to creating one (create_category) or deleting it (delete_category). It also notes that system categories like Transfer cannot be changed, which is an explicit exclusion that guides usage. However, it does not explicitly name the alternative tools or state 'use instead of...' but the context is clear enough for a knowledgeable 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 disclose destructive and idempotent behavior, so the bar is lower. The description adds the nuance that color can be cleared with null, which is not in the schema. However, it does not clarify what happens when only id is provided (since name and color are optional) or whether name and color can be updated simultaneously, leaving some ambiguity. No contradiction with annotations.

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

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

The description is two sentences with zero fluff. It front-loads the core purpose (renaming and changing colour) and immediately adds the key nuance (null clearing) and the prerequisite for ID retrieval. Efficient 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?

Given the tool's simplicity, the description covers the main operations and a key edge case (null color). It does not explicitly state that name and color are optional or that both can be updated together, but the output schema exists and annotations cover safety. The only notable gap is the behavior when only id is passed, which is minor. Overall, it is sufficiently complete for an agent to use correctly.

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

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

Schema description coverage is 67%, but the description compensates by clarifying the source of id (list_tags) and the null-clearing behavior for color, which the schema does not describe. It also reinforces that name is for renaming and color for changing colour. This adds meaning beyond the schema, particularly for the color parameter.

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

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

The description clearly states the tool renames a tag or changes its colour, with a specific verb and resource. It distinguishes itself from create_tag and delete_tag by focusing on modification, and the mention of clearing color with null adds specificity.

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

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

The description provides a clear usage hint by stating 'Tag IDs come from list_tags', guiding the agent to first retrieve IDs. It implies usage for editing existing tags but does not explicitly exclude creation or deletion scenarios, nor does it mention alternatives like update_category. Still, the ID source is a practical guideline.

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 flag the tool as non-read-only, destructive, and idempotent. The description adds valuable behavioral detail beyond those annotations: partial-update semantics, null-clearing for categoryId, merchant, and note, tag replacement behavior, and the cross-currency amount requirement. There is no contradiction with the annotations.

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

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

Three short sentences, no filler, and the most important behavioral constraint—'Only the fields passed are changed'—is front-loaded. Every sentence earns its place by conveying information an agent needs to invoke the tool correctly.

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 an 11-parameter mutation tool with a rich output schema and safety annotations, the description covers the non-obvious semantics: partial updates, null clearing, tag replacement, ID source, and cross-currency handling. It does not discuss type-change limitations or explicitly route agents to add/delete siblings, but those are either inferable or visible in the schema.

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

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

With 64% schema description coverage, the description compensates meaningfully by clarifying null semantics for parameters that lack full schema descriptions, such as merchant and note, and by stating the general partial-update contract. It also adds cross-currency context for amount and toAmount. Date and type rely on schema constraints, but those are reasonably self-explanatory.

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: 'Changes an existing transaction.' The qualifier 'existing' clearly separates this tool from add_transaction and delete_transaction, and the title 'Edit a transaction' reinforces the intent. An agent can confidently distinguish this tool without inspecting sibling 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 provides clear context for use: only passed fields are changed, null clears specific fields, tagIds replaces all tags, transaction IDs come from list_transactions, and cross-currency moves require an amount in the destination currency. It does not explicitly name add_transaction or delete_transaction as alternatives, so it stops short of a full when-to-use instruction.

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