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

No annotations are provided, so the description carries the full behavioral burden, but it only states that a new expense is added. It does not disclose side effects, validation rules, ID generation, duplicate handling, or whether recurring expenses update budgets.

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

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

The description is a single short sentence with no filler, which is structurally clean. However, it is so terse that it omits useful context; it is under-specified rather than appropriately concise.

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 8 parameters, no annotations, and a mutation operation, the description is too minimal. It does not mention return behavior, validation constraints, or how this expense interacts with budgets and summaries, leaving an agent without enough context for correct invocation.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no parameter-level meaning, which matches the baseline of 3.

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

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

The description uses a clear verb ('Add') and resource ('a new expense'), making the operation's purpose immediately obvious. It does not explicitly differentiate itself from siblings, but the action is distinct enough from edit/delete/list that an agent can select it correctly.

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 such as edit_expense or search_expenses. The description implies the creation use case but provides no context, prerequisites, 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?

With no annotations, the description carries the full behavioral burden. It clearly signals a destructive operation via 'Delete' and discloses that the deleted record is returned for confirmation. It does not mention permissions or irreversibility, but the verb 'delete' makes the side effects clear enough and the return behavior adds useful detail.

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

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

Two very short sentences front-load the core action and add a compact note on the confirmatory return. No filler, every word serves a purpose.

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

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

For a one-parameter mutation with a full output schema, the description is sufficient. It states the operation and confirms the return payload. It could mention 404 behavior for missing IDs, but the output schema covers error information and the tool is simple enough that this absence does not meaningfully hurt invokability.

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

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

Schema description coverage is 100%, with the expense_id field fully documented as 'ID of the expense to delete.' The description only reiterates 'by its ID' and adds no new meaning beyond the schema.

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

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

The description states the exact operation 'Delete an expense' with the resource identified by its ID, and notes the return value is the deleted record. This clearly differentiates it from sibling tools like get_expense, add_expense, or edit_expense, which perform different actions.

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: call it when you want to delete a specific expense and you have its expense_id. However, it does not explicitly contrast with alternatives (e.g., 'use edit_expense to modify instead') or state when not to delete, so guidance rests at the implied 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, the description carries the behavioral burden, and it does disclose the key non-obvious behavior: only provided fields are updated, so omitted fields remain untouched. It does not mention invalid-ID errors or permissions, but for an edit tool with an output schema the core mutation semantics are communicated.

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

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

Two concise sentences, no filler, and the most important behavioral rule is front-loaded second. Every word earns its place, and it is easy to scan while still being specific.

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

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

Given 9 parameters, 100% schema coverage, and an output schema, the description is sufficiently complete for making a correct call. It could mention what happens if expense_id does not exist, but that is margin error-handling detail rather than a missing usage requirement.

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

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

The schema already documents all 9 parameters, including default sentinel semantics like 'Pass 0 to keep current' and 'Pass None to keep current.' The description adds no new parameter-level detail beyond the partial-update rule, so schema coverage does the heavy lifting and this stays at baseline.

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

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

The description clearly states the tool edits an existing expense, which immediately separates it from add/list/delete/search siblings. The 'existing' qualifier also signals that this is a mutation of an already-created expense, and the sentence is action-first rather than tautological.

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 tells the agent to use this tool when modifying an existing expense, and the partial-update note implicitly says 'do not pass fields you don't want changed.' However, it does not name alternatives or explicitly state when not to use it, so it is clear context but lacks 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?

There are no annotations, so the description carries the full burden. It does disclose the output is CSV text and pasteable into a spreadsheet, which is useful behavioral context. However, it does not mention whether the export is read-only, whether headers are included, or how edge cases like empty results are handled.

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

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

A single, front-loaded sentence that states the core action, scope, and output format. The spreadsheet note adds practical value without padding.

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, has full schema coverage, and an output schema is present, so return values do not need to be detailed. The description covers the essential purpose and output format, though it could briefly mention the optional category filter.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the date-range concept but adds no new meaning beyond the schema, and it does not mention the optional category filter.

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 (export), the resource (expenses), the scope (date range), and the output format (CSV text). This differentiates it from sibling tools like list_expenses or search_expenses, which do not imply a spreadsheet-ready export format.

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

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

The description implies the tool is for exporting data for spreadsheet use, but it does not explicitly state when to choose this over list_expenses, search_expenses, or summarize_expenses. No alternatives or exclusion criteria are mentioned.

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

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

With no annotations provided, the description carries the full burden, and it does disclose that empty month defaults to current month. However, it does not state whether this is read-only, what happens if no budget is set, or what data source the comparison relies on. It adds the default behavior but leaves other behavioral traits implicit.

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 convey the core action and the default handling with zero filler or redundancy. The primary purpose is front-loaded, and every sentence earns its place.

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

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

Given the single optional parameter and the availability of an output schema, the description is almost sufficient for correct invocation. It covers the return-input behavior and default; a slight gap is that it does not orient the agent relative to related budget/summary siblings or mention preconditions, but the output schema fills the return-value gap.

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

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

Schema description coverage is 100%, and the description's 'YYYY-MM' and current-month default duplicate what is already in the input schema. The description adds no extra meaning beyond schema, so the baseline of 3 is appropriate.

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

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

The description states a concrete verb and resource: 'Compare actual spending vs budget for a given month,' which clearly identifies the tool's function. It is distinct from siblings like get_expense, set_budget, and get_monthly_trend because it focuses specifically on budget-versus-actuals status for a month.

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 about the input month and the default current-month behavior, but it does not explicitly tell the agent when to choose this tool over siblings such as summarize_expenses, get_monthly_trend, or get_category_breakdown. The when-not/exclusion guidance is implied rather than stated.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It only states that spending is broken down by subcategory, leaving out details like whether inactive subcategories are included, whether the result is sorted, or whether aggregation is always performed. This is a minimal disclosure for a tool that produces grouped output.

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

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

A single, front-loaded sentence with no redundant phrasing. Every word adds meaning, and the key scope ('single category', 'subcategories') is placed immediately.

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 concise but sufficient given the simple operation, complete parameter schema, and presence of an output schema. It lacks only deeper behavioral specifics, but an agent has enough to invoke the tool correctly for a straightforward aggregation.

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

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

Schema description coverage is 100%, so parameters are already documented ('The category to break down', date formats, inclusive end date). The description does not add parameter-level detail beyond clarifying the category's role, which matches the baseline.

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

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

The description uses a specific verb ('Break down') and names the resource ('spending for a single category by its subcategories'), which immediately distinguishes it from sibling tools like summarize_expenses or list_expenses. The phrase 'single category' clarifies the scope without ambiguity.

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

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

The description makes the use case clear: use it when you need a subcategory-level breakdown of one category's spending. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to route correctly.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Fetch' unambiguously indicates a read-only, non-mutating operation, which is useful. However, it does not disclose error behavior, permission requirements, or what happens when the ID is not found.

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

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

The description is a single front-loaded sentence with no filler. It states the verb, target, and scope immediately and concisely.

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

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

For a one-parameter read operation with an output schema present, the description plus schema are largely sufficient for an agent to select and invoke the tool correctly. Minor gaps remain around not-found behavior and explicit differentiation from list_expenses, but these are not critical at this complexity level.

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

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

The sole parameter is already fully documented in the schema as an integer `expense_id`. The description's 'by its ID' is consistent but adds no new semantic detail beyond the schema, so the high-coverage baseline of 3 applies.

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

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

The description uses a specific verb ('Fetch') and resource ('a single expense') with an explicit ID-based scope. This clearly distinguishes it from sibling tools like list_expenses or search_expenses.

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

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

The phrase 'by its ID' clearly signals when to use this tool: when retrieving one known expense. It implies the tool is not for listing or searching, but it does not explicitly name alternatives or exclusion conditions.

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 itself must convey the operation's behavior; it does indicate this is an aggregated, read-only monthly comparison rather than a transaction-level mutation. It does not clarify edge cases such as whether the current month is included or how month boundaries are calculated.

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 one tightly worded sentence that leads with the action and outcome, with no filler or repetition of the parameter schema. Every word contributes to 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?

For a simple read-only tool with one optional parameter and an output schema, the description plus schema is largely sufficient for invocation. It is missing only explicit sibling differentiation and boundary caveats, which are useful but not essential to calling it correctly.

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

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

Schema coverage is 100% and the months parameter already has a type, default, and description. The description's 'N months' adds little beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Show') and names a concrete resource ('month-over-month spending totals') with a timeframe, so an agent understands what the tool does. It does not explicitly contrast with siblings such as summarize_expenses or get_category_breakdown, so it only partially earns the 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 given about when to prefer this tool over alternatives like summarize_expenses or list_expenses, nor does it state any exclusions. The intended use is implied by the name and description, but not explicitly routed.

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 conveys that the operation is a read-only listing and that the date range is inclusive, which is useful. However, it omits important behavioral traits such as default sort order, pagination behavior, and how filters interact, leaving operational uncertainty.

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 states the action, scope, and existence of optional filters efficiently, earning its place without padding.

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 100% schema coverage, an output schema, and a simple list operation, the description plus schema is sufficient to construct a valid call. However, it is thin on operational context such as default limits, sorting, and how this tool is meant to be used relative to the sibling search_expenses, so it is only minimally viable.

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

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

The schema already documents all 10 parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond calling some filters 'optional', and the schema already conveys the same information more precisely.

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 ('list') with a clear resource ('expenses') and adds a date-range scope, making the core purpose immediately understandable. It distinguishes itself from single-record tools like get_expense, but it does not differentiate from the sibling search_expenses, whose name suggests overlapping list/search behavior.

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

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

The description gives a basic context (listing by date range with optional filters) but provides no guidance on when to prefer this tool over siblings like search_expenses or summarize_expenses. There are no exclusions, prerequisites, or alternative routing cues, leaving the agent to guess.

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 states the search scope (notes and tags) but does not disclose whether the search is case-insensitive, whether full-text implies partial matches, whether it returns only accessible expenses, or whether it is entirely read-only (though 'search' implies it). The description repeats the schema's parameter semantics without adding behavioral context like pagination, ordering, or potential rate limits.

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

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

A single, upfront, and well-structured sentence that conveys the tool's core function in seven words. Every word earns its place; there is 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?

Given the tool's relative simplicity and the presence of an output schema (which defines the return shape), the description is adequate in scoping the tool, but it omits behavioral details that as a result quality (e.g., whether it matches partial words, case sensitivity) and any note about performance or limits. It also does not link to any alternative of supporting the description is borderline acceptable but has clear gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented with meanings. The description's phrase 'across expense notes and tags' adds nothing beyond the query parameter's description ('Search term to look for in the 'note' and 'tags' fields'), so it does not enhance parameter understanding. Baseline 3 is appropriate.

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

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

The description identifies the specific action (full-text search), resource (expenses), and scope (notes and tags). It clearly distinguishes from sibling tools like list_expenses, which presumably lists all expenses, since search is explicitly full-text. The meaning is unambiguous.

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

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

The tool is clearly meant for full-text searching of expenses, so its use is implied by the description. However, there is no explicit guidance on when to choose it over list_expenses or other expense retrieval tools, and no mention that it's for finding expenses when you don't know the expense ID. The description implies the use case but does not provide boundaries or 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?

With no annotations, the description must carry behavioral transparency. It says 'Set or update' but doesn't disclose that it overwrites an existing budget for the category, what happens if the category doesn't exist, or any side effects (e.g., audit logs, validation rules). The schema mentions category existence but not the tool's behavior, leaving a meaningful 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, direct sentence with no filler. It is appropriately brief for a 2-parameter setter tool and presents the core action and scope immediately.

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 and has an output schema, but since it's a mutation tool with no annotations, the description doesn't explain the actual mutation path (create vs update), error handling when the category is missing, or what the tool returns. It's adequate but incomplete, missing what the agent needs to anticipate a failed or unexpected call.

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

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

The input schema description covers both parameters clearly (category existence, monthly limit in INR) at 100% coverage. The description adds only 'monthly budget' rephrasing, but no new meaning or caveats beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific action ('Set or update'), a resource ('monthly budget'), and its scope ('for a category'). It distinguishes itself from sibling tools that operate on expenses or retrieve budget status, though it doesn't name an alternative explicitly.

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 siblings like get_budget_status or edit_expense. The description simply states the action without defining the conditions or pre-requisites, such as needing an existing category or how this differs from editing expense records.

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 burden. It clearly states the aggregation behavior and grouping options, but doesn't disclose whether the result includes totals, counts, or both, or whether the output is a flat list or nested structure. The output schema exists and may cover this, but the description itself doesn't add behavioral context beyond the grouping dimensions.

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

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

Two sentences with no filler. The core action and the key options are front-loaded. Every word earns its place.

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

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

For an aggregation tool with a 100% schema-covered parameter set and an output schema present, the description is largely complete. It could mention whether the aggregation includes all categories by default or requires explicit selection, but the schema's default for group_by and the optional category parameter cover most of that. The output schema likely explains the return shape.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the grouping dimension context ('Group by category, subcategory, month, or day') which reinforces the group_by parameter, but doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Aggregate') and resource ('spending over a date range'), and explicitly lists grouping dimensions. It clearly distinguishes this from sibling tools like list_expenses (which would list individual expenses) and get_category_breakdown (which is category-specific).

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

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

The description implies when to use this tool: when you need aggregated spending totals over a date range, rather than individual expense records. It doesn't explicitly name alternatives or exclusions, but the grouping options and aggregation language make the use case clear. Sibling names like list_expenses and get_category_breakdown provide additional context.

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