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

No annotations are provided, so the description carries the full burden. It only says 'Add' and does not disclose side effects, uniqueness constraints, permission requirements, or return behavior. This is minimal for a mutating operation.

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

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

The description is a single, front-loaded sentence with no wasted words. However, it is so brief that it omits useful context, so it does not earn 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?

Despite the simple signature (one required string), the absence of annotations, output schema, and parameter detail leaves gaps in behavior and constraints. The description is enough to identify the tool but not to invoke it confidently in edge cases.

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

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

Schema description coverage is 0%, and the description does not elaborate on the 'name' parameter beyond the schema's field name. It omits details like uniqueness, formatting, or relationship to existing categories.

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 ('Add') and a specific resource ('user-defined spend category'), clearly distinguishing this from sibling category tools like set_txn_category or remove_category. It states exactly 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?

No guidance is provided about when to use this tool versus alternatives such as set_merchant_category or set_txn_category. There are no prerequisites, exclusions, or alternative recommendations.

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 no annotations, the description carries the full transparency burden. It states 'Read-only' and notes a dependency, but omits what happens if the sync hasn't run (error vs. empty result), does not describe the output format or pagination, and provides no detail on authorization or data freshness. The provided traits are minimal.

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 front-loads the purpose, then adds read-only status and a prerequisite. Every word adds value, achieving maximum 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?

The tool has no output schema, no annotations, and a single ambiguous parameter. The description fails to explain the return structure, default behavior for missing month, error scenarios, or any limits. For a tool that apparently queries Amazon purchase data, this is insufficient for an agent to confidently invoke it.

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

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

The schema has one parameter 'month' with zero description coverage. The description mentions 'in a month', implying the parameter is the time period, but does not specify the expected format (e.g., YYYY-MM) or behavior when omitted. It adds limited meaning beyond the raw parameter name.

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: revealing item-level details (titles, quantities, line totals) behind Amazon charges for a month. This distinguishes it from sibling tools like get_category_breakdown, which focuses on categories rather than items. The purpose is specific and immediately understandable.

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 prerequisite ('needs `budget amazon sync` to have run') and implies use for monthly Amazon breakdowns, but it does not explicitly contrast with alternatives like get_category_breakdown or query_transactions. The usage context is clear but lacks explicit when-to-use versus 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?

With no annotations, the description carries the full burden. It explains the meaning of the metric and its interpretation, but does not disclose how the month parameter is applied, what constitutes 'item detail,' whether the operation is read-only, or the output structure. The description is partially transparent but lacks key behavioral details.

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

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

The description is concise, two sentences, and front-loaded with the main metric. The use of an em dash to clarify purpose adds value without redundancy. 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 has one optional parameter and no output schema, so the description should provide clarity on both. It explains the metric's meaning but omits the month parameter behavior and the exact return value (e.g., a single number vs. a breakdown). Given the sibling tool list includes amazon_breakdown, more detail on how this complements it would be useful.

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

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

The input schema includes an optional 'month' parameter with no description, and the tool description never mentions it. With schema description coverage at 0%, the description fails to compensate, leaving the parameter completely unexplained.

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 measures Amazon spend in dollars that has item detail behind it. It also differentiates the tool from siblings like amazon_breakdown by framing it as a prerequisite check ('Check this before trusting an Amazon breakdown').

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

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

The description provides explicit usage guidance: 'Check this before trusting an Amazon breakdown' establishes a clear workflow and when to use this tool. However, it does not explicitly mention alternative tools or when to avoid using it, though the context implies 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?

Without annotations, the description carries the burden. It discloses the validation behavior (write refused if lines don't sum) and warns about the consequence of wrong allocations ('silently misstates a budget'). However, it omits other behavioral traits like idempotency, permission requirements, or what happens to existing splits, so transparency is partial.

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 concise sentences that are front-loaded with the purpose. Every sentence adds value: the purpose, the critical constraint, and the user confirmation requirement. 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?

Despite its clarity, the description is incomplete for a mutation tool with no annotations and no output schema. It doesn't explain what a successful response looks like, how lines are structured, whether the split replaces existing data, or what 'source' is. These gaps make it inadequate for fully autonomous 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 coverage is 0%, so the description must add meaning. It clarifies that 'lines' are category allocations and must sum to the charge, and implies 'txn_id' identifies the charge. However, it does not describe the internal structure of each line object or the optional 'source' parameter, leaving critical information undocumented.

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 and resource: 'Split one charge across categories.' This identifies the action and target. It is distinct from sibling tools like set_txn_category or propose_split, though it doesn't explicitly name alternatives, so it doesn't perfectly differentiate from every 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 provides important usage constraints: 'Lines MUST sum to the charge exactly or the write is refused' and 'Confirm with the user first.' However, it does not specify when to use this tool over others (e.g., propose_split for planning), so the guidance is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a non-obvious behavior: floor categories like Investments flip the comparison, flagging under-target instead of over-budget. This is valuable context beyond what a simple 'spend vs budget' would imply. However, it doesn't mention other behaviors like what happens if no budget is set or how categories are included.

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

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

The description is a single sentence with a parenthetical, making it concise and front-loaded with the core purpose. It conveys the main function and a key exception without extraneous wording. The parenthetical is dense but necessary for accurate usage. Nearly every word earns its place, though the sentence could be slightly clearer with an explicit 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?

Given there is no output schema and no annotations, the description must explain what the tool returns and how it behaves. It covers the flagging logic and floor category flip, which is useful, but it lacks details about the return structure (e.g., list of categories with spend, budget, status), the month parameter format, and whether it includes all categories or only those with budgets. This is partially complete but leaves gaps.

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

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

The schema has one optional parameter 'month' with no description (0% schema coverage). The description only says 'for a month' but fails to specify the expected format (e.g., YYYY-MM, month name, or date range). This leaves the agent guessing about how to invoke the tool correctly. The description adds minimal semantic value beyond the schema's bare parameter name.

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: showing spend versus budget per category for a month, with over-budget flagging and a special case for floor categories. It distinguishes from siblings like get_category_breakdown (which likely shows spend only) and compare_periods (which compares time periods) by focusing on budget comparison. However, it lacks an explicit verb like 'get' or 'display', though the name 'budget_overview' implies it.

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

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

The description implies when to use the tool: when you need a monthly budget vs. spend comparison per category. However, it does not provide explicit alternatives or exclusions, such as 'use get_category_breakdown for spend-only breakdown' or 'use compare_periods for historical trends'. Since the purpose is clear, usage is implied, but no direct 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?

No annotations are provided, so the description carries the full burden. It states the action but does not disclose potential side effects, idempotency, whether clearing is reversible, or what happens if no limit exists. This is minimal transparency for a mutation 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 concise sentence with no wasted words. It is front-loaded with the action and target, making it easy to scan, though it sacrifices detail for brevity.

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 is a mutation with no annotations and no output schema, the description should provide more context about parameter behavior and edge cases. It lacks guidance on what happens when subcategory is omitted and does not mention return values or side effects, leaving the tool incomplete for reliable invocation.

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

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

With 0% schema coverage, the description must explain parameters. It mentions category and subcategory but does not clarify their relationship, optionality, or how to specify a subcategory versus a category. The phrase '(or subcategory)' is vague and leaves critical semantics uncertain.

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 clears a budget limit for a category or subcategory, using a specific verb and resource. It does not explicitly contrast with set_budget_limit, but the purpose is unambiguous and distinct from sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives like set_budget_limit, nor any mention of prerequisites or conditions. The description is purely functional and leaves usage context unstated.

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

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

No annotations are provided, so the description carries full burden. It discloses the return format including totals, delta, and per-category table sorted by change. However, it does not explicitly state that the operation is read-only or discuss permissions/rate limits, which is a notable gap for a tool without annotation safety hints.

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

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

The description is two sentences, front-loaded with the core action, and provides all key information without waste. 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 two-parameter tool with no output schema or annotations, the description covers the purpose, returned values, and parameter format well. Minor gaps like delta direction and exact spend definition remain, but overall it is sufficient 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?

Both parameters are plain strings with no schema descriptions. The description adds the YYYY-MM format for both, which is helpful. However, it does not clarify which month is the base versus comparison, leaving the delta sign ambiguous.

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 compares spend between two months, with a specific verb and resource. It also distinguishes from sibling tools like get_category_breakdown (single month) and query_transactions (raw data) by focusing on period-over-period spend comparison.

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, or when not to use it. The description explains what the tool does but does not address decision context or 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states the action is deletion, but it does not mention whether the operation is irreversible, what happens if the line index does not exist, or any side effects. This lack of context is a significant gap for 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?

The description is a single, front-loaded sentence that is efficient and grammatically clear. However, given the ambiguity around the 'line' parameter, an additional clarifying sentence would have been justified.

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

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

For a simple delete tool with one parameter and no annotations, the description is incomplete. It does not explain how 'line' corresponds to notes listed by sibling tools like list_user_notes, nor does it mention error behavior or whether the deletion is permanent. The description is minimal and leaves the user guessing.

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 provides no description for the 'line' parameter, and schema coverage is 0%. The description adds that 'line' is an index, but it does not clarify what list or note collection the index refers to, leaving the parameter meaning ambiguous.

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 ('Delete') with a clear resource ('the note') and a precise scope ('at the given line index'). It distinguishes the tool from siblings like save_user_note and list_user_notes by explicitly indicating the deletion 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?

Usage is implied: use this tool when you need to delete a user note identified by a line index. However, there is no explicit guidance on when not to use it or mention of alternatives such as editing via save_user_note or using run_sql for bulk deletion.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the default threshold (2 sd), the ~2-year history window, and the important nuance that detection baselines always use full history even when scoped. It lacks explicit mention of read-only status or return format, but covers key behavioral traits.

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

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

The description is two sentences, front-loads the core definition, and efficiently packs scoping and baseline behavior without redundancy. Every sentence adds value.

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

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

Given the absence of annotations and output schema, the description covers detection logic, default scope, and parameter usage well. However, it does not describe the structure of the returned 'flags' or any additional caveats. This is a minor gap for a moderately complex find tool.

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

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

The input schema provides zero descriptions (0% coverage), so the description must compensate. It explains month (format and scoping), limit (scoping), and implies sd_threshold's role via the default. The exact effect of limit is under-specified, but overall the parameters gain meaningful context.

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

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

The description clearly defines the tool's function with a specific detection criterion (transactions above merchant historical mean by standard deviation). It distinguishes itself from sibling query/breakdown tools by focusing on anomaly detection, and the phrase 'returns flags' provides a concrete action.

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 the default unscoped behavior and explicitly instructs how to scope using month and limit, including the month format. It stops short of naming alternative tools or stating when not to use it, but the 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?

No annotations are provided, so the description carries full behavioral disclosure burden. It does not mention what happens when 'month' is omitted (though the schema says it's optional), nor does it describe return format, pagination, or other behavioral traits. The description's focus on a month without addressing optionality creates an information gap.

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 exceptionally concise, using a single phrase that conveys the tool's core purpose and the required month format. Every word is meaningful, and there is no extraneous information. It is appropriately front-loaded and easy to parse.

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

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

For a simple tool with no annotations and no output schema, the description is too incomplete. It lacks usage guidance, behavioral details (especially the optional month parameter), and any description of the return structure. Given the presence of many sibling tools, more context is needed for correct selection and 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?

The description adds semantic value by specifying the expected format for the 'month' parameter as YYYY-MM, which is not present in the schema. However, it does not clarify that the parameter is optional or explain the behavior when omitted, so it only partially compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's function: retrieving per-category spend totals for a month. It uses a specific verb ('get' implied) and a distinct resource ('category breakdown'), and specifies the month format. However, it does not explicitly distinguish it from sibling tools like 'subcategory_breakdown' or 'query_transactions', so it lacks direct 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 usage: use this tool when you need monthly per-category spend totals. It provides clear context (month in YYYY-MM format). However, it does not explicitly state when not to use it or mention alternative tools, leaving the usage guidance at an implied rather than explicit level.

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 no annotations provided, the description carries the full burden. It discloses the tool's output components and default month behavior. Although it does not explicitly state it is read-only or discuss side effects, the read-only nature is implied by 'Spend summary' and the absence of any warning. This is adequate for a simple lookup 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 two sentences, front-loaded with the tool's identity, followed by output details and a usage hint. Every sentence is informative and 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 tool with no output schema and no annotations, the description provides all essential information: purpose, month parameter format and default, output contents, and a usage scenario. It is complete for the tool's complexity.

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

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

The input schema only defines 'month' as a string with no description. The description adds crucial semantics: 'YYYY-MM' format and 'default current'. This fully compensates for the 0% schema coverage, making the parameter clear and usable.

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 specifies a clear verb and resource: 'Spend summary for a month' and details the contents (spend total, per-category breakdown, income, transfers, unresolved conflicts). This distinguishes it from sibling tools like get_category_breakdown or query_transactions, which likely focus on narrower aspects.

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 this first for "how am I doing this month"', providing a direct usage scenario. However, it does not mention when not to use it or alternative tools, so it 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?

With no annotations, the description must carry the burden of behavioral disclosure. It mentions grouping by source, which implies aggregation, but does not state whether the operation is read-only, how month is interpreted, or what the output structure looks like.

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 phrase with no redundant words, making it easy to parse and front-loaded with the core concept. It is short but not overlong; it sacrifices completeness rather than adding filler.

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

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

The description is too sparse for reliable invocation: it lacks month format, default behavior, return type, and differentiation among many similar sibling reporting tools. The absence of an output schema makes this gap more significant.

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 'month' field with no description (0% coverage). The description mentions 'for a month' but fails to specify the expected date format, whether omitting month returns all data, or any constraints on the value.

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

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

The description clearly states that the tool provides income data grouped by source for a month, which is a specific resource and scope. However, it uses no action verb and does not explicitly distinguish this from sibling tools like income_transactions or get_category_breakdown.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, exclusions, or refer to any sibling tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states what data is returned, but does not clarify whether the operation is read-only, how the optional month is handled (e.g., default to current month), sorting, pagination, or potential errors. This leaves significant ambiguity.

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 that directly communicates the core idea. It is appropriately compact and front-loaded, though it could include additional useful details without becoming verbose.

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

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

Given the lack of annotations, output schema, and parameter descriptions, the description is insufficient for an agent to invoke the tool correctly with confidence. It does not mention return shape, default behavior, edge cases, or error conditions, making it incomplete even for a 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?

The input schema has no parameter descriptions (0% coverage). The description adds minimal meaning by indicating that 'source' is the primary filter and 'month' is optional. However, it does not specify the expected format for 'month' (e.g., YYYY-MM) or valid values for 'source', so it only partially compensates for the schema 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 identifies the resource (income transactions) and filters (source, optional month), making the primary purpose reasonably clear. However, it lacks an explicit verb such as 'list' or 'retrieve', and does not distinguish this from sibling tools like query_transactions, so it does not achieve a top score.

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

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

No guidance is provided about when to use this tool versus alternatives like query_transactions or income_by_source. There is no mention of use cases, exclusions, prerequisites, or any comparison to sibling tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds valuable behavior: determinism, the specific categories considered, and the nuance that floor categories falling short of target are flagged as 'under target' with 'add more, not a cut.' It does not cover output format, errors, or default behavior when month is omitted.

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 with a parenthetical that packs in all key distinctions. It is front-loaded with the core purpose and every clause adds information, though the parenthetical makes it a bit run-on.

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 tool without an output schema or annotations, the description gives enough conceptual coverage: categories and the floor-category rule. It does not explain the return structure, response format, or edge cases such as what happens when month is not provided, leaving some practical gaps.

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

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

The only parameter, 'month', is a bare string with no schema description. The phrase 'for a month' confirms the parameter's role but adds no format, optionality, or default information. Since there is only one simple parameter, this partial compensation is adequate but thin.

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

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

The description clearly identifies the tool as producing deterministic 'ways to save' for a month and enumerates the categories considered (over-budget, biggest discretionary, subscriptions). It is distinct from sibling tools like find_anomalies or budget_overview, but lacks an explicit verb such as 'generates' or 'returns'.

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 month-scoped savings insight and includes special handling for floor categories, but it does not explicitly state when to prefer this tool over siblings, nor does it mention exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. It discloses the tool is a read-only listing of category metadata and implies no side effects by framing it as the vocabulary to consult before writes. It also specifies the exact data dimensions returned.

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. Front-loaded with the core purpose, followed by actionable usage guidance. 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 zero-parameter, read-only list tool with no output schema, the description is complete. It covers what the tool returns and when to use it, fully self-contained.

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 description adds meaning beyond the empty schema by detailing the output contents (name, kind, direction, custom flag). This is a clear baseline 4 plus added value.

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

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

The description clearly states the tool lists the assignable category vocabulary, including exact names, kinds, direction, and custom flag. It distinguishes itself from siblings by positioning itself as the canonical reference required before category writes.

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

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

Explicitly instructs to call before any category write and names the tools requiring an exact name: set_merchant_category, set_txn_category, set_budget_limit. This provides clear when-to-use guidance and alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not mention authentication, response format, pagination, or any other behavioral traits, offering minimal value beyond the tool name.

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, direct sentence with no filler or redundancy. It is front-loaded, immediately conveying the tool's purpose, 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?

For a zero-parameter, read-only tool, the description is minimally sufficient to understand its purpose. However, with no output schema or annotations, the agent receives no information about the return format or content shape, leaving some ambiguity for downstream use.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. According to the rubric, a 0-parameter tool receives a baseline of 4. The description adds no parameter-specific detail but clarifies the entity being listed, which is sufficient.

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

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

The description uses the specific verb 'List' and identifies the resource as 'saved user-preference notes', clearly stating what the tool does. It does not explicitly contrast with sibling tools like save_user_note or delete_user_note, but the action 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?

No guidance is given on when to use this tool versus alternatives. While the tool name implies it is the counterpart to save_user_note and delete_user_note, the description provides no explicit context, exclusions, or alternative references.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It explains the category meaning but does not disclose what 'mark' does operationally (e.g., whether it overwrites, persists, errors on missing categories, or requires any permissions).

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

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

A single sentence that immediately states the action and defines the specialized terminology with an illustrative example. No wasted words.

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

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

The tool is simple (one string parameter, no output schema), and the description covers the core purpose and key semantic distinction. However, it lacks explicit usage/parameter detail and operational behavior, making it minimally viable but incomplete.

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

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

Schema coverage is 0% and the description does not explain the 'name' parameter beyond referring to 'a category'. It omits details like whether the name must match an existing category, case sensitivity, or format expectations.

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

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

The description uses a specific verb ('Mark') and resource ('category'), then defines the key concept ('floor-type', 'MORE spend is good') with a concrete example (Investments). This clearly distinguishes it from the sibling unmark_floor_category and other category 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 a clear semantic condition for use: categories where more spending is beneficial, opposite of all other ceiling-type categories. This implies when to apply versus not, though it does not explicitly name alternative 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose ordering (oldest-first) and a limit (most recent N), which is useful. However, it does not explain the default behavior when 'limit' is omitted, nor does it clarify what 'per month' means (calendar months, rolling 30 days, etc.). It also doesn't mention that this is a read-only operation, though that is implied.

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, compact sentence: 'Spend + income per month (most recent N, oldest-first).' It is front-loaded with the core purpose and includes behavioral details without any fluff. Every word earns its place, making it highly concise and well-structured.

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

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

Given the lack of annotations and output schema, the description is underspecified. It doesn't clarify the default value of 'limit', what the output structure looks like, or how spend and income are combined (e.g., separate series or net amount). The tool appears simple, but the missing details could lead to incorrect usage or interpretation.

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 zero description for the 'limit' parameter, so the tool description must compensate. The phrase 'most recent N' directly connects the parameter to the behavior, indicating that 'limit' controls how many months are returned. However, it doesn't explicitly state the parameter's name or provide details like allowed values or default, leaving some ambiguity.

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

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

The description clearly identifies the resource: spend and income per month, with scope (most recent N, oldest-first). It doesn't include an explicit verb like 'get' or 'list', but the meaning is clear and it distinguishes itself from sibling tools by focusing on monthly trends rather than single-month or category-specific views.

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. It does not mention any exclusions or reference sibling tools like 'get_month_summary' or 'compare_periods', leaving the agent to infer usage solely from the tool's name and vague description.

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 no annotations, the description carries the burden of disclosing behavioral traits. It discloses that the tool is advisory and non-resolving, and that it focuses on unresolved import conflicts. This provides meaningful behavioral context beyond the tool's name, though it doesn't detail what 'open' returns or imply read-only status explicitly.

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 verb and resource, and conveys purpose, scope, and advisory nature with minimal words. Every word contributes value; no fluff or redundancy.

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

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

For a simple zero-parameter tool with no output schema, the description is complete. It tells what the tool does (opens unresolved conflicts), why (to reconcile), and a key constraint (advisory; resolve via CLI). This is sufficient for an agent to decide when and how to invoke it.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. Per the baseline for zero-parameter tools, the description does not need to compensate for missing schema information, and it doesn't.

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: 'Open (unresolved) import conflicts to reconcile.' It uses a specific verb ('open') and resource ('import conflicts'), and adds the qualifier 'unresolved' to define scope. This distinguishes it from sibling tools, none of which handle conflict opening.

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

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

The description provides usage context by noting the action is 'advisory' and that resolution happens 'via the CLI,' effectively telling agents when not to rely on this tool for actual conflict resolution. However, it does not explicitly name alternative sibling tools or state a direct 'when to use' scenario, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' which is crucial safety information, and explains the scaling behavior and the prerequisite that all lines must be categorized before applying the split. This adds useful context beyond the tool name.

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

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

The description is only three sentences, with the core purpose stated first. Every sentence adds value—purpose, read-only safety, and the required workflow—without redundancy or fluff.

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

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

The tool has a single parameter and no output schema, so the description must cover both purpose and usage. It does so by explaining the read-only nature, the scaling, and the next step (apply_split). Minor gaps include no mention of return format or error cases, but for a simple tool this is mostly 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 one parameter, txn_id, with zero description coverage. The description does not mention txn_id or explain how to identify the Amazon charge, leaving parameter semantics entirely to inference. Though the phrase 'behind an Amazon charge' vaguely implies the transaction ID, it is not explicit enough, so the description fails to compensate for the 0% 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 that the tool returns item lines behind an Amazon charge, scaled to the actual charged amount. It also distinguishes itself from apply_split by instructing to call that only after categorizing, giving it a distinct role among the many sibling tools.

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

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

The description provides an explicit workflow: assign a category to every line, show the user, and only then call apply_split. This tells the agent exactly when to use this tool and names the next tool to use, which is strong guidance compared to 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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: 'month wins and days is ignored if both are given', 'most recent first', 'posted transactions', and the substring match on merchant. This goes beyond the schema, though it omits response format and error 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?

Single sentence, front-loaded with the main action and all filters. The parenthetical is dense but precisely conveys the precedence behavior. 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 listing tool with 6 optional parameters and no output schema, the description covers the important behaviors: filtering options, precedence, and ordering. It could mention the limit parameter more explicitly, but the schema covers it. Adequately complete 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?

Schema coverage is 67% (days and category lack descriptions). The description adds meaning to the month/days combination (month wins, days ignored), specifies 'merchant substring', and notes 'min amount' as a filter. It does not repeat limit defaults but compensates for the under-described parameters.

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

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

The description clearly states 'List posted transactions' with a specific verb and resource, and distinguishes from siblings like get_category_breakdown (aggregations) and run_sql (arbitrary SQL). It also specifies the scope 'posted' and the key filtering dimensions.

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 when to use: to list posted transactions with optional filters, including the precedence rule (month wins). It implicitly distinguishes from sibling reporting tools but does not explicitly mention alternatives or exclusions. Clear context with no exclusions matches a 4.

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 detection criteria (near-monthly, stable amount) but does not state whether the tool is read-only, whether it modifies data, or what the output format is. With no annotations, the description carries the full transparency burden and fails to disclose these behavioral traits.

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

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

The description is extremely short and front-loaded with the key noun phrase, but it is a fragment lacking a verb. It is concise but under-specified, making it less useful than a complete but still brief sentence.

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 (0 parameters, no output schema), the description is still incomplete. It does not state what the returned data looks like (e.g., list, count, summary), the time period covered, or how this relates to sibling tools that also deal with subscriptions.

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 information to describe. Per the baseline rule for 0 parameters, this score is 4, as the description need not explain parameters that do not 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 identifies the tool's focus: detecting recurring/subscription charges with specific criteria. However, it lacks an explicit action verb (e.g., 'List' or 'Show') and does not distinguish itself from sibling tools like split_subscriptions.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or why a user would choose this over similar tools such as find_anomalies or split_subscriptions.

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

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

With no annotations provided, the description carries the full transparency burden. It explicitly discloses that the tool re-points transactions/rules/budgets and then hides the category rather than physically deleting it, which is critical behavioral context. It stops short of noting irreversibility or permissions, but for a mutation tool this is a clear and honest disclosure.

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 packed sentence that front-loads the core action and then adds necessary details about the merge behavior and side effects. Every clause earns its place, with no redundant 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 two-parameter tool with no output schema and no annotations, the description covers the action, the parameters, and the behavioral consequences well. It lacks edge-case guidance (e.g., what happens when category doesn't exist, or if merge target is the same), but given the tool's simplicity and the absence of complex schema, it is adequately complete for an AI 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 provides bare parameter names with zero descriptions, so the description compensates by clarifying that 'name' is the category to remove and 'merge_into' is the destination category. This gives operational meaning to both parameters, though it does not explicitly name the parameters or specify constraints like 'must both be existing categories.' The description adds meaningful semantics beyond schema.

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

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

The description immediately states the action ('Remove a spend category') with a specific method ('MERGING it into another'), and clearly distinguishes this from sibling tools like add_custom_category or set_txn_category by emphasizing the merge-and-hide behavior. The scope is precise and actionable.

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

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

The description clearly explains the intended use case: to remove a category while preserving its linked data by merging into another. It does not explicitly state when not to use this tool or name alternative sibling tools, so it misses an exclusion clause, but the context is strong enough to imply 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?

With no annotations provided, the description carries the full burden. It discloses the tool writes a local file, is deterministic, uses a specific path pattern, and requires user confirmation. This is transparent about side effects and safety.

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

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

Three concise sentences: purpose with output path, parameter explanation, and safety warning. Every sentence adds value, and key information is front-loaded.

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

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

For a file-generation tool with no output schema and no annotations, the description covers the action, output contents, file location, parameters, and confirmation requirement. It is sufficiently complete for an agent to select and invoke correctly.

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

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

The schema has no descriptions for 'period' or 'narrative', and the description compensates by explaining period format (YYYY-MM) and narrative placement (short plain-text paragraph under the headline). This adds essential meaning beyond the raw 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 the specific verb 'Render' and identifies the resource as a visual report PDF with components (stat row, spend-vs-budget chart, trend, flags), distinguishing it from sibling data-analysis tools. It also specifies the output path pattern.

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 states when to call (to render the monthly report) and includes a mandatory prerequisite: confirm with the user before calling. It does not explicitly exclude alternatives, but no sibling tool performs report rendering, so 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?

With no annotations, the description must disclose behavior itself, but it only describes the queue's contents, not what the tool does when invoked. It is unclear whether this is a read-only list or if it triggers any side effects, such as marking items as reviewed.

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 with no unnecessary words. It clearly communicates the key content of the queue in a front-loaded manner.

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

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

Given the absence of annotations, output schema, and parameters, the description is too thin. It tells the user what the queue contains but not what the tool does, what it returns, or when to use it, leaving an agent with insufficient detail to invoke it confidently.

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 no parameter explanation is needed. The description adds no parameter-specific information, but this is not a gap since the schema covers everything (empty properties). Baseline 4 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 identifies the resource (categorization review queue) and specifies its contents (uncategorized merchants + individual checks), which distinguishes it from siblings. However, it lacks an explicit verb like 'lists' or 'shows', so it reads more like a definition than an action.

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 open_conflicts or set_merchant_category. There is no mention of context, prerequisites, or what makes this tool the preferred choice.

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 no annotations, the description carries the full burden and does so thoroughly. It discloses read-only behavior ('No writes, no ATTACH'), PII column blocking ('raw_ofx, payee, memo, acct_hash are read-blocked'), and the visibility of all statuses. This provides comprehensive behavioral transparency.

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

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

The description is three concise sentences, each adding valuable information. It front-loads the primary action and resource, then efficiently covers status filtering and restrictions. No unnecessary wording or repetition.

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

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

Given the simple schema (1 parameter), no annotations, and no output schema, the description is remarkably complete. It defines inputs, acceptable queries, unavailable columns, and the status nuance. The column list effectively serves as the output schema, enabling the agent to understand return values without additional documentation.

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 provides no description for the 'query' parameter, but the description compensates by explaining the query type ('SELECT/WITH'), constraints ('No writes, no ATTACH', PII blocked), and the available columns. This adds meaningful semantic context, though it stops short of giving explicit syntax examples or stating 'provide a SQLite query 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 clearly states the tool's function: 'Run a read-only SELECT/WITH query against the transactions table', specifying the exact resource and verb. It also lists the accessible columns, distinguishing it from higher-level sibling tools by emphasizing its SQL nature and read-only 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 provides context about read-only usage and notes 'add WHERE status='posted' to match the spend tools'. However, it does not explicitly name alternatives or state when to prefer this tool over siblings like query_transactions. The usage guidance is 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?

With no annotations provided, the description carries the full burden of disclosing side effects. It specifies the output path and accepted period formats, which is useful, but it does not mention overwrite behavior, validation of inputs, or any return value. For a write operation, this is a moderate level of transparency.

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

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

The description is a single, efficient sentence that is front-loaded with the action and destination. Every word adds value, with no redundancy or filler.

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

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

For a simple 2-parameter tool with no output schema, the description is nearly complete. It provides the destination path and accepted period formats, which covers the core requirements. Minor omissions like overwrite behavior do not significantly hinder understanding for basic 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?

Even though schema description coverage is 0%, the description compensates by explaining both parameters: 'period' is given explicit format options (YYYY-MM, 'all', 'lastN'), and 'markdown' is described as 'composed brief markdown' indicating the content type. This adds meaning beyond the bare schema.

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

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

The description clearly states the verb (Save), the resource (composed brief markdown), and the destination (data/briefings/<period>.md), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like save_user_note by specifying briefs specifically.

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 saving a composed brief) but does not explicitly contrast it with alternatives like save_user_note or provide exclusions. It provides enough context for a straightforward save operation but lacks explicit 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?

With no annotations, the description carries full burden. It discloses that the note is durable and that it is a new (not update) operation, and adds the 'one sentence' constraint. It does not mention return values, error conditions, or overwrite behavior, but for a simple save operation this is minimal yet sufficient.

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

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

The description is two short sentences with no wasted words. It front-loads the core purpose and adds a key exclusion and constraint.

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 save tool with no output schema, the description adequately covers purpose, scope, and a safety note. It omits return behavior, but that is often implicit for save operations. The simplicity of the tool keeps the completeness high.

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 only says 'note' is a required string. The description adds semantic meaning: it should be a one-sentence user preference. This compensates for the 0% schema description coverage by providing format guidance.

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 ('Save'), the object ('a NEW durable user preference'), and explicitly excludes financial data, distinguishing it from the many financial sibling tools. This is a specific verb+resource+scope definition.

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?

'NEW' implies creation rather than listing or deleting, and 'Not financial data' provides an explicit exclusion. However, it does not name alternative tools for listing or deleting notes, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does clarify a key nuance: direction is not set here and comes from the category's floor/ceiling marking. However, it omits other important behaviors such as whether setting a limit overwrites an existing one, validation rules (e.g., non-negative cents), or any side effects. Thus, it adds some transparency but not complete coverage.

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

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

The description is two sentences with no wasted words. The first sentence states the action and units; the second addresses the critical nuance about direction. It is front-loaded and to the point, earning a perfect score.

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 setter tool with no output schema and no annotations, the description is adequate but not fully complete. It covers the core purpose and the direction dependency, but it leaves gaps like overwrite behavior, whether the category must exist, and valid ranges for amount_cents. Given the availability of sibling tools like clear_budget_limit and mark_floor_category, more explicit interaction guidance would strengthen completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that the limit is monthly, in cents, and applies to either a category or a category-subcategory pair. This clarifies the role of 'amount_cents' and the optional nature of 'subcategory' beyond the bare schema. It doesn't detail constraints like minimum values, but the parameter names and this context are sufficient for basic invocation.

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

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

The description clearly states the tool's function: 'Set a monthly budget limit (cents) for a category or (category, subcategory).' It uses a specific verb ('set'), identifies the resource ('budget limit'), specifies units ('cents'), and defines the scope. This distinguishes it from siblings like clear_budget_limit (removal) and mark_floor_category (marking direction).

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

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

The description provides context by noting that direction is handled by mark_floor_category, not this call, which indirectly guides the agent to use that tool for floor/ceiling marking. However, it does not explicitly state when to use this tool versus clear_budget_limit or other alternatives, so it falls short of full differentiation.

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

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

No annotations are provided, so the description carries full burden. It discloses the action (set) but omits side effects such as overwriting existing values, persistence behavior, or validation constraints (e.g., negative amounts). For a mutation tool, this is minimal.

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, front-loaded with the action and resource, with no wasted words. It is appropriately sized for a simple setter tool with one parameter.

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 a mutation with no annotations and no output schema. The description does not explain the return value, side effects, or how this expected income is used. While the parameter set is fully covered, the behavioral context is incomplete for a setter tool.

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

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

Schema coverage is 0%, so the description must compensate. It confirms the 'cents' parameter is the income amount in cents, adding meaning beyond the bare 'integer' schema. However, it does not clarify valid ranges, defaults, or edgetcases, leaving some semantic 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 clearly states the verb 'Set' and the resource 'expected monthly income' with explicit unit (cents). It distinguishes from sibling tools like income_by_source and income_transactions, which are analytical/list tools, not setting tools.

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

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

No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, exclusions, or relation to other tools like set_budget_limit. The description only states what it does, not when to invoke 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It goes beyond the input schema by revealing the side effect: 'adds a rule and recategorizes that merchant's existing transactions.' It also discloses the special requirement for setting category='Random' (confirm_random=true) and discourages that action. This is meaningful behavioral context, though it omits details like reversibility or permission requirements, preventing a perfect score.

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

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

The description is two sentences long, front-loading the primary action ('Pin a merchant...') before the caveat about Random. Every sentence adds value: the first states the core behavior and side effect, the second provides an important usage warning. There is no redundancy or filler, earning the highest score.

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

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

For a tool with 4 parameters, no annotations, and no output schema, the description covers the essential context: what it does, its side effect, and a critical edge case (Random category behavior). It does not explain return values or error conditions, but given the tool's straightforward nature, this is a minor gap. The description is more complete than the average 3, but lacks additional depth like conflict handling or undo options.

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

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

Schema description coverage is 0%, so the description must compensate for the bare parameter list. It does so by explaining merchant_norm as a 'substring' and describing the role of category and optional subcategory. It also clarifies the confirm_random parameter's purpose in the context of the 'Random' category. While it doesn't detail allowed values or formats, it gives functional meaning to all 4 parameters, which is strong given the lack of schema 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 states the tool's function: 'Pin a merchant (merchant_norm substring) to a category (+ optional subcategory)' and explains that it 'adds a rule and recategorizes that merchant's existing transactions.' This specific verb-resource pairing distinguishes it from sibling tools like set_txn_category (which targets a single transaction) and add_custom_category (which creates a new category definition).

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

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

The description provides clear context for when to use the tool: to create a persistent merchant-to-category rule that affects existing transactions. It also gives usage guidance by warning against setting category='Random' and advising to 'pick a real category or leave it in the review queue,' implicitly steering users away from misuse. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls 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?

The description discloses an important behavior: setting category='Random' requires confirm_random=true and is discouraged. However, with no annotations, it doesn't cover other behavioral aspects such as permissions, reversibility, or side effects on existing categories, leaving the description only partially transparent.

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 primary action and scope, the second adds a critical caveat about 'Random.' It is front-loaded, concise, and contains 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?

The tool is a simple mutation with 4 parameters, but the description fails to explain the 'subcategory' parameter or return behavior. It covers the main action and an edge case, but gaps remain, making it adequate but not fully complete.

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

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

The description adds meaning for txn_id (the transaction identifier), category (specifically calling out 'Random'), and confirm_random (required for Random), but it omits any explanation of 'subcategory.' With 0% schema description coverage, the description carries the burden and is incomplete for one 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 uses a specific verb ('Categorize') and resource ('transaction') identified by 'txn_id', and adds '(no rule)' to distinguish from rule-based categorization. It also differs from sibling 'set_merchant_category' by focusing on transactions rather than merchants.

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 the tool handles a SINGLE transaction and provides clear context by discouraging 'Random' category, advising to 'pick a real category or leave it in the review queue.' While it doesn't explicitly name alternative tools, it implies when to use this tool vs leaving uncategorized.

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 no annotations, the description carries the full burden of behavioral disclosure. It only mentions 'give every Subscriptions merchant its own subcategory,' but does not explain side effects, whether it overwrites existing subcategories, if it's idempotent, or what 'blank ones' means. This is insufficient for a mutating bulk operation.

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

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

The description is concise—one sentence—and front-loads the key action. The parenthetical 'blank ones only' is slightly awkward and could be integrated more clearly, but overall it is 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 bulk mutation tool with no parameters, annotations, or output schema, the description is too minimal. It lacks details about the operation's effect on existing data, any return value, and the exact criteria for 'blank ones.' This leaves significant gaps for an agent.

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

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

The tool has zero parameters, so the description is the sole source of semantic meaning. It adds useful scope information ('blank ones only'), indicating which merchants are affected, even though it could be clearer.

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

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

The description clearly states the action (giving each Subscriptions merchant its own subcategory) and the specific target (Subscriptions merchants), which distinguishes it from generic category management tools. However, 'blank ones only' is somewhat ambiguous, slightly obscuring the precise condition.

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?

There is no explicit guidance on when to use this tool versus alternatives like set_merchant_category or propose_split. The description implies a bulk operation for budgeting, but does not state prerequisites, exclusions, or alternative 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?

No annotations are provided, so the description must carry the full burden. It only states the aggregation level and time filter but does not disclose output structure, inclusion of zero-spend subcategories, sorting, or any data caveats, which is a significant gap.

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 front-loads the main intent. No filler or redundant wording is present, making it highly efficient for its length.

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

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

With no output schema and no annotations, the description fails to convey critical context about return values, edge cases, or how this tool fits with related sibling tools. The minimal description leaves the agent under-informed for reliable selection and 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 coverage is 0% and the description merely restates the roles of 'category' and 'month' without adding format constraints, allowed values, or examples. This adds minimal value beyond the property names already in the schema.

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

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

The description clearly states the tool returns spend by subcategory within a category for a month. It uses a specific verb ('Spend by') and identifies the resource and scope, which distinguishes it from sibling tools like get_category_breakdown.

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

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

The description implies usage when a subcategory-level breakdown within a single category and month is needed. However, it provides no explicit guidance on alternatives, exclusions, or when not to use this tool, relying on the name and 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?

With no annotations, the description carries the full burden. It only discloses the month format (YYYY-MM) and gives no information about output structure, default limit behavior, or whether the results are aggregated. This is minimal behavioral disclosure.

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 wasted words. It is concise and directly states the tool's 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?

Despite the tool's simplicity, the description lacks important context: no output schema means the return format should be described, and the optional month parameter leaves ambiguity about default behavior. The description does not explain what the result contains or how limit behaves, making it incomplete for an agent to use effectively.

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 adds value by specifying the month format (YYYY-MM), which is not in the schema. However, it does not explain the limit parameter or any default behavior. Since schema coverage is 0%, the description only partially compensates for the 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 states the tool returns top merchants by spend for a specified month, with the month format given. It is distinguishable from siblings like get_category_breakdown, but lacks an explicit verb and does not mention any differentiation from other reporting tools.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_category_breakdown or insights. The description only states what it does, with no exclusions, alternatives, or context 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?

With no annotations provided, the description must disclose behavioral traits. It does explain the semantics change (ceiling-type, less spend is good), but does not mention side effects, idempotency, error conditions, or whether the category must already be floor-marked. This is adequate but leaves gaps for a mutation 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 concise sentence, front-loaded with the verb 'Revert'. It contains no fluff or redundancy; every word contributes to understanding the tool's 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?

The tool is simple (one required param, no output schema, no annotations), and the description conveys the core action and semantic outcome. However, it omits details about what happens if the category doesn't exist or isn't marked, and there is no mention of return values or errors. These gaps are notable but not fatal given the 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 schema has a single required 'name' parameter with no description (schema coverage 0%). The description refers to 'a category' but does not explicitly state that 'name' is the category name. While the tool name strongly implies this, the description does not formally compensate for the missing 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 uses a specific verb ('Revert') and a specific resource ('a category') while explaining the semantic effect ('to ordinary ceiling-type semantics (less spend is good)'). This clearly distinguishes the tool from its sibling 'mark_floor_category' and makes the action 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 usage (when you want to undo a floor marking) but does not explicitly state when to use it vs alternatives or provide any exclusion criteria. It does not mention that this is the inverse of 'mark_floor_category' or that it should only be used on categories currently marked as floor.

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