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

With no annotations, the description carries the full burden, but it only states that an add operation occurs. It does not disclose side effects such as whether the balance is affected, whether amounts must be positive, whether records can be duplicated, or any permissions required.

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

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

The single sentence is efficient and free of filler, stating the action and the domain ('tracker') in a few words. It is appropriately compact, though the brevity leaves substantive detail to other dimensions.

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 definition is adequate for a trivial add operation but incomplete for an agent: four parameters have 0% schema coverage, no annotations exist, and no guidance is given about parameter semantics or alternatives. An output schema exists, but the description still does not provide enough context 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?

Schema description coverage is 0%, so the description must explain the parameters, but it mentions none by name. 'Money received' hints that amount is an inflow and source is where it came from, yet date format, note semantics, and source behavior remain 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 uses a specific verb ('Add') and resource ('credit') and clarifies that credit means 'money received,' which separates it from add_expense. It does not explicitly name or contrast sibling tools, but the parenthetical makes the core purpose unambiguous.

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

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

The phrase 'money received' implies the tool is for recording incoming funds, so an agent can infer when to use it versus add_expense or list_credits. However, it gives no explicit guidance about when not to use it or which alternative to prefer.

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 clearly indicates the mutating behavior ('Add a new expense') and adds a significant constraint about category/subcategory sourcing. However, it does not mention validation failure behavior, permissions, reversibility, or other side effects beyond the act of adding.

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

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

The description is three sentences with no filler: the first states the action, and the next two deliver the key sourcing constraints. It is front-loaded and every sentence earns its place.

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

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

For a simple create tool with an output schema, the description covers the most non-obvious aspect (category/subcategory sourcing) but omits date and amount expectations and gives no sibling-tool routing. It is adequate but leaves clear gaps an agent must resolve elsewhere.

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 meaningful semantics for category and subcategory, including the empty-subcategory rule, but it provides no guidance on date format, amount constraints, or note semantics, leaving some required parameters underspecified.

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

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

The description opens with 'Add a new expense,' a specific verb-resource pair that clearly identifies the tool's function. It also differentiates it from siblings like add_credit and the expense list/update/delete tools by naming the resource type.

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 useful input-level guidance, especially that category and subcategory must come from data://categories, but it does not explicitly say when to prefer add_expense over alternatives like add_credit, nor does it state exclusions or when not to use the tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses the destructive nature ('Delete') but does not mention irreversibility, cascading effects, authorization requirements, or what happens if the id does not exist. The output schema exists but the description does not clarify the response 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple delete operation.

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

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

For a simple delete tool with one parameter and an output schema, the description is nearly adequate. However, with no annotations, it lacks behavioral context such as irreversibility and error handling, which an agent would benefit from knowing before invoking a destructive operation.

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

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

Schema description coverage is 0%, but the single parameter 'id' is self-explanatory as an integer identifier. The description adds minimal meaning beyond the schema by specifying that deletion is by id, but it does not explain id semantics (e.g., expense id vs. other ids).

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

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

The description states a specific verb ('Delete') and resource ('expense') with a clear identifier ('by id'). It is unambiguous and distinguishes from siblings like add_expense, update_expense, and list_expenses, though it does not explicitly name them.

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. The description implies usage (delete when you have an expense id) but does not state exclusions or mention related tools like update_expense or list_expenses.

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 transparency burden away from structured fields. It communicates that the tool returns three aggregate values and is read-only in nature ('Get'), but it does not disclose the scope of the totals, the exact meaning of 'remaining balance', or whether any side effects exist.

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, 10-word sentence with no filler. It front-loads the verb and resource and packs the key output fields into an efficient list.

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 getter with an output schema, the description is largely complete: it names the returned values and no input is required. It loses one point for not clarifying the aggregation scope and for leaving the distinction from summarize_expenses unstated.

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 fully described, so the baseline is high. The description adds useful context about the computed output but doesn't need to clarify any parameter behavior because there are no 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 uses the specific verb 'Get' and identifies a clear resource, 'balance', listing the exact returned aggregates (credited, spent, remaining). This makes the tool's purpose obvious, though it does not explicitly differentiate it from the sibling summarize_expenses or list_* 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 call this tool instead of list_expenses, list_credits, summarize_expenses, or the mutation tools. The intended context is only implied by the name and description, leaving selection decisions to inference.

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

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

With no annotations, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, and the date-range note adds some behavior context, but the description does not disclose whether unfiltered calls return all credits, how results are ordered, or any response characteristics beyond what the output schema already provides.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the optional date-range behavior is stated immediately after the core purpose.

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

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

For a simple two-parameter list tool with an output schema, the description covers the essential call shape. It is incomplete in that it lacks usage guidance and behavior details, but the low complexity and presence of an output schema reduce the burden on the description.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the date format (YYYY-MM-DD) and clarifies that filtering is optional, which helps interpret start_date and end_date. However, it does not explain the exact meaning of each parameter, such as whether the range is inclusive or what an empty default represents.

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

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

The description states a clear verb-resource pair: 'List credits' with an optional date range. It is specific enough to distinguish from the sibling tools at a basic level, though it does not explicitly differentiate itself from related list tools like list_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 description gives no guidance on when to use this tool versus alternatives such as list_expenses, add_credit, or summarize_expenses. It mentions the optional date filter but does not explain in what scenarios filtering would be appropriate or how it relates to other credit/expense 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that filtering by category and/or date range is optional and specifies the date format YYYY-MM-DD. However, it does not mention default behavior when no filters are supplied, ordering, pagination, or whether date bounds are inclusive. This is adequate for a simple read operation but leaves some behavioral gaps.

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 wasted words. The primary action is front-loaded, and the optional filtering and date format are presented clearly and compactly.

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

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

For a simple read-only list tool with three optional parameters and an output schema present, the description is mostly complete. It explains the filtering capabilities and date format, and the output schema presumably covers return values. It lacks only a note about default results when no filters are applied, which is a minor gap given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions category and date range, which maps to the three parameters, and adds the date format YYYY-MM-DD. Still, it does not individually define each parameter or clarify whether start_date and end_date are both required for a range, though their semantics are reasonably inferable from their names.

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 begins with a specific verb and resource: 'List expenses'. It also states the optional filters (category and date range) and the date format, making the tool's purpose immediately clear. It is distinguishable from siblings like list_credits and summarize_expenses because it targets expenses specifically and is a list operation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as summarize_expenses for aggregation or get_balance for balances. It does not mention exclusions, prerequisites, or cases where a sibling should be preferred. The usage context is only implied by the verb 'List'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only query, what the summary output contains, or how empty or unfiltered results behave.

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, front-loaded with the action and resource, with no filler or repetition of the tool name.

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 core purpose is clear and the output schema covers return-value structure, but the lack of usage routing and behavioral transparency leaves meaningful gaps for a tool with no annotations. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully identifies the two parameters as an optional date range and specifies the YYYY-MM-DD format. It stops short of explaining endpoint edge cases like inclusivity or whether both dates must be provided together.

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

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

The description states a specific verb and resource: 'Summarize expenses by category'. This makes the aggregation intent clear and separates it from the itemized expense/credit sibling tools, though it does not explicitly name an alternative tool.

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 use this tool versus list_expenses or get_balance. The optional date-range note describes how to filter, but does not provide tool-selection context, exclusions, 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 carries the full burden. It does disclose that only provided fields are changed (partial update), which is valuable. However, it doesn't mention side effects, like whether the update is idempotent or if missing fields are reset to defaults, which the schema defaults might imply. It also doesn't describe error behavior or authentication needs, but that may be out of scope.

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 fluff. It front-loads the main purpose and immediately clarifies the partial update behavior and the constraint. 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 6 parameters and an output schema, but no annotations. The description covers the partial update and one constraint, but lacks details on the effect of default values when fields are omitted (e.g., does omitting 'date' reset it to empty string?), which is crucial for correct usage. It also doesn't mention the output format, but the output schema exists, so that's covered. The main gap is parameter behavior nuances.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions the category/subcategory constraint. It doesn't explain the id parameter beyond being required, nor the semantics of date, note, amount, or the null allowed for amount. However, the schema itself provides type and default information, which helps. The description adds a critical constraint for category/subcategory, giving some 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 it updates an existing expense, which is a specific verb and resource. It partially distinguishes from siblings like add_expense and delete_expense, but not explicitly. The mention of partial update (only provided fields) adds important behavioral nuance.

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 doesn't explicitly say when to use this tool versus alternatives, but the description implies it is for modifying existing expenses, which differentiates from adding or deleting. The constraint on category and subcategory from data://categories is useful but not a full usage guideline. It lacks exclusions or conditions for when not to use it.

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