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

Beyond what annotations already convey about mutation, the description adds almost no behavioral context. It does not disclose whether duplicates are allowed, whether existing categories are affected, whether the type scopes the categories, or what the response looks like. The phrase 'for transactions' adds little 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 focused sentence with no filler and the action is front-loaded. It is appropriately brief for a simple create tool, though the brevity comes at the cost of missing parameter and behavioral context.

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 the schema supplies the required parameters, so the overall definition is minimally viable. Still, the description leaves clear gaps: it does not mention the required type parameter, duplicate behavior, or output, and it relies entirely on sibling names for routing.

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 needed to explain the parameters, but it only echoes the word 'categories' and completely omits the required type enum. The schema's enum and array constraints are self-evident, but the description does not compensate for the lack of schema-level descriptions.

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

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

The description uses a clear verb ('Create') and resource ('custom categories'), and the 'for transactions' phrasing distinguishes it from category-management siblings like deleteCustomCategories and getCustomCategories. It stops short of 5 because it does not clarify what 'custom' means relative to default categories or how categories are scoped by 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?

Usage context is implied by the create verb and the clear contrast with sibling tools such as deleteCustomCategories and getCustomCategories. However, it never explicitly says when to use this tool versus alternatives, nor does it mention any prerequisites or constraints around the required type field.

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

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

The description adds no behavioral information beyond what annotations already provide. Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false, but the description does not disclose side effects, idempotency, or how the recurring schedule is managed. It offers zero additional 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 one short sentence, but it is essentially a tautology of the tool name. It is concise but not informative; it does not earn its place because it adds no value beyond what the name already conveys.

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 9 parameters, 6 required, multiple enums, and no output schema, the description is woefully incomplete. It does not explain the effect of startDate, the return value, or how this tool differs from createTransaction. An agent has no way to correctly call this tool beyond guessing from parameter names.

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 89%, so most parameters already have descriptions in the schema. The tool description adds no parameter information, but the baseline of 3 applies since the schema carries the burden. The description does not compensate for the 11% gap (e.g., 'description' parameter lacks a schema description).

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

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

The description clearly states the verb 'Create' and the resource 'a recurring transaction', which is unambiguous. However, it does not differentiate from sibling tools like createTransaction or editRecurringTransaction, so it lacks the sibling differentiation needed for a 5.

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. There is no mention of conditions that favor createRecurringTransaction over createTransaction or editRecurringTransaction, leaving the agent to infer usage entirely from context.

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

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

Annotations already indicate this is a non-read-only operation, and the description only repeats the create action. No additional behavioral context is supplied, such as idempotency, duplicate behavior, side effects on custom categories, or the need for transactionId to be absent. It adds nothing beyond the structured annotations.

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

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

The description is concise in length but not in value because it restates the title without adding information. It is not front-loaded with any differentiating detail and could apply to several sibling tools. This is under-specification rather than beneficial 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 7 parameters, 2 enums, and many siblings, yet the description provides no overall context. It does not explain the one-off nature, custom category flow, or distinction from recurring transaction creation. Although the schema covers parameter details, the tool-level context needed for correct invocation is missing.

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

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

Schema description coverage is 100%, with every parameter individually documented, including enums and the unclear transactionId field. Since high schema coverage implies a baseline of 3, this score holds even though the description itself contributes no parameter meaning. The schema carries all semantics.

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

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

The description 'Create new transaction' simply restates the tool title and name. It identifies the verb and resource but provides no differentiation from sibling tools like createRecurringTransaction or editTransaction. This is a tautology rather than a clear singular purpose.

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

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

The description gives no guidance about when to use this tool instead of alternatives. There is no mention of one-off vs recurring transactions, no exclusion of editTransaction, and no conditional rules. An agent must infer usage purely from the name.

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

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

Annotations already carry destructiveHint=true and idempotentHint=false, so the agent knows this is a destructive write. However, the description adds no behavioral context beyond the bare word 'delete' — e.g., whether deleting a category affects existing transactions, whether built-in categories are excluded, or what happens when two of the same category are provided.

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 one short sentence, but this is under-specification rather than conciseness. No content earns its place, so nothing is front-loaded; it is simply the name restated.

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

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

For a destructive tool with two required parameters and no output schema, the description is incomplete: it does not describe what gets permanently deleted, whether deletion is scoped by account or category type, or how success/failure of the operation is conveyed. An agent could call it tentatively, but important edge behavior is absent.

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%, yet the description makes no effort to explain the two required parameters. The enum values (expense/income/investment) and the 'categories' array are self-descriptive in the schema, which keeps this from being a 1, but the description itself adds no meaning for the `type` discriminator or the category name strings.

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 'Delete custom categories' verbatim restates the title and the tool's own name, adding no new information. It names a verb and resource, but because it is a pure tautology of the title it does not differentiate or clarify beyond what the agent already sees in the tool name.

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 alternatives. Siblings such as getCustomCategories, getCategoriesByType, and createCustomCategories exist, but the description does not mention them, nor any conditions that should trigger deletion, prerequisites, or consequences.

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

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

The annotations already provide destructiveHint=true and idempotentHint=false, so the safety signal is largely structured. The description adds the irreversibility qualifier 'permanently,' but it does not describe cascading effects, whether linked future transactions are affected, or what response is 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?

The description is five words long, front-loaded with the verb and resource, and contains no filler. 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 one-parameter destructive tool with annotations covering the write behavior, the description is nearly sufficient. Its only notable gap is the lack of explicit routing away from mark/skip and any description of post-delete behavior, but the low complexity makes this a minor omission.

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

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

Schema coverage is 100% and there is only one parameter, transactionId, so the description does not need to restate it. The description adds no parameter-specific meaning and does not resolve the odd schema phrase 'mark as done, skip or delete' that appears in the transactionId field.

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') and a clear resource ('a recurring transaction'), and 'permanently' distinguishes it from sibling tools like markRecurringTransactionDone and skipRecurringTransaction. There is no ambiguity about what action the tool performs.

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

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

The word 'permanently' implies this tool is for irreversible removal rather than marking or skipping a recurring transaction. However, it does not explicitly name alternatives or state when the agent should prefer mark/skip/edit tools, so the guidance is only implied.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is covered. The description adds 'permanently', which usefully conveys irreversibility. It does not contradict the annotations, though it omits potential side effects or details about what happens to associated recurring data.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately sized for a one-parameter deletion tool.

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

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

Despite the tool's apparent simplicity, the conflicting parameter schema and the presence of multiple sibling delete/mark/skip tools leave an agent without enough information to reliably select and invoke this tool. It should clarify that it deletes a regular transaction, not a recurring one, and that the ID is the transaction ID.

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%, but the lone parameter description says 'ID of the recurring transaction to mark as done, skip or delete', which appears copy-pasted from another tool and conflicts with the tool's purpose. The tool description adds no clarification, so an agent could be misled about what ID to provide.

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

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

The description clearly states a verb and resource ('Delete transaction permanently') and is not a tautology. It does not explicitly distinguish between normal transactions and recurring transactions, which is relevant given the sibling deleteRecurringTransaction 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?

There is no guidance on when to use this tool versus alternatives such as deleteRecurringTransaction, markRecurringTransactionDone, or skipRecurringTransaction. The word 'permanently' hints at irreversibility but provides no exclusions or alternative routing.

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

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

Annotations already declare the tool as non-read-only, idempotent, and non-destructive. However, the description adds no behavioral context beyond the word 'Edit', such as what happens to related occurrences, whether updates are partial or full, or any side effects. No additional transparency is provided.

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?

At one sentence, it is extremely concise but at the expense of substance. The description is merely the title restated, which is under-specification rather than efficient engineering. There is no front-loaded key information.

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

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

A 9-parameter tool with 6 required parameters and no output schema requires a richer description to explain behavior around partial updates, validation, or assumptions. The one-sentence description leaves all operational details to inference, making it inadequate for safe and 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 89%, so the input schema already gives strong semantic meaning to each parameter. The description adds no parameter-level information, but the schema bears most of the load; according to the rubric, the baseline for high coverage is 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 'Edit a recurring transaction' is a tautology of the tool name and title, adding no information beyond what the agent already knows. It does not specify which aspects of a recurring transaction can be edited or differentiate this tool from closely related siblings like editTransaction.

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 createRecurringTransaction, deleteRecurringTransaction, or editTransaction. There are no conditions, prerequisites, or exclusions mentioned, leaving agents to infer usage from the schema alone.

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

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

Annotations already state readOnly=false, idempotent=true, and destructive=false, so there is no contradiction. However, the description adds no behavioral context beyond 'edit' – it does not explain that an existing transaction must be identified, what effects the edit has, or how idempotency applies.

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 no wasted words flags, which is concise. However, it is so terse that it omits useful behavioral and contextual details, making it more under-specified than genuinely efficient for a 7-parameter mutation tool.

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

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

For a 7-parameter mutation tool with no output schemaabbey, the description is too sparse. It does not explain how to identify which transaction to edit, even though transactionId is not marked required in the schema. The presence of createTransaction and editRecurringTransaction siblings makes this ambiguity more consequential.

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

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

Schema description coverage is 100%, and the schema already provides meaningful property descriptions and enums, so the baseline of 3 is appropriate. The description itself adds no parameter-level information, but the schema carries that burden adequately.

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 ('Edit') and a clear resource ('existing transaction'), which distinguishes it from createTransaction and deleteTransaction at a high level. However, it does not disambiguate from editRecurringTransaction or explain the transactionId ambiguity, so it is clear but not fully differentiated.

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 createTransaction or editRecurringTransaction. The phrase 'existing transaction' is the only contextual cue, with no mention of alternatives, prerequisites, or conditions that should route an agent elsewhere.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the period-scoping behavior (retrieving for a specific period) which is beyond the annotations. However, it doesn't disclose how missing endMonth behaves or what the return structure is, so it adds only modest context.

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

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

The description is a single sentence with no filler. It directly states the action and scope. Every word earns its place, and it is appropriately short for a simple read 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?

Given there is no output schema, the description should at least hint at what is returned (e.g., budget total, breakdown, etc.) to help the agent set expectations. It only says 'Retrieve budget' without specifying the return shape or any response fields. The parameter breakDownByCategory implies some breakdown capability, but the description does not mention it. This is a meaningful gap for a read-only tool.

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

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

Schema description coverage is 100%, so all three parameters (startMonth, endMonth, breakDownByCategory) are documented in the schema with formats and defaults. The description adds no additional semantic meaning beyond the generic 'specific period', which does not go beyond what the schema already conveys. Baseline 3 applies given full schema coverage.

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

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

The description states a specific verb ('Retrieve') and resource ('budget') with a scope ('for a specific period'). It is clear enough to distinguish from the sibling 'setBudget' (write operation) though it doesn't name it explicitly. Slight lack of detail on what 'budget' means or what the response contains prevents a 5.

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

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

No explicit guidance on when to use this tool versus alternatives like setBudget or getTransactions. The description only states what it does, not when it is appropriate or when to choose a different tool. The sibling setBudget exists but is not referenced, leaving the agent to infer the read/write distinction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds little behavioral detail beyond the workflow mention of creating a category if none match. No contradiction with annotations.

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

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

Two short sentences with no filler. The main purpose is front-loaded, and the usage guidance is directly actionable.

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

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

For a single-parameter, read-only tool with clear annotations, the description is mostly complete. It covers what the tool does, when to use it, and what to do if no categories exist. The only minor gap is not addressing how this relates to getCustomCategories.

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%: the 'type' parameter already has an enum and description. The description only says 'specific type' without adding meaning beyond the schema, so the baseline score applies.

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

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

The description uses a specific verb and resource: 'Retrieve all categories of a specific type'. This clearly identifies the tool's function and distinguishes it from sibling tools like createCustomCategories and deleteCustomCategories.

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

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

The description explicitly says when to use this tool: 'Always use this tool to get categories before creating a transaction.' It also gives a follow-up action if no categories match. However, it does not contrast this with the sibling getCustomCategories, which could be an alternative in some contexts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only 'current', which is a minor clarification and does not provide additional behavioral context like return format or caching. Given the annotations, this is adequate but not enriching.

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 states exactly what the tool does with no wasted words. It is front-loaded and perfectly scoped for its simplicity.

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 parameterless, read-only getter with annotations covering safety, the description is complete. No output schema exists, but the description sufficiently communicates the purpose. An agent can call this correctly without further information.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). The baseline for 0 params is 4, and the description does not need to add any parameter semantics. It correctly stays silent on 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?

States a clear verb ('Get') and a specific resource ('current currency preference'). It unambiguously distinguishes from the sibling setCurrency, which is the corresponding write operation. An agent can immediately tell this is a read-only retrieval of the user's currency setting.

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

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

The purpose implies usage: read the current currency preference. The sibling setCurrency provides the contrast for write operations, though the description does not explicitly state 'use this to read, setCurrency to write'. Still, the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no extra behavioral context such as pagination, return format, or the fact that results are filtered by the 'type' parameter. It does not contradict annotations, but provides minimal added value beyond them.

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

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

The description is a single concise sentence with no unnecessary words. It is appropriately short for a simple retrieval tool, though it could have added a note about the filtering requirement without losing 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 is simple with one required parameter, and the schema covers the parameter well. However, there is no output schema and the description does not clarify the return structure or the fact that 'all' is constrained by the 'type' filter. This leaves some ambiguity 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 input schema has 100% description coverage for the only parameter, 'type', with an enum and a clear description. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states the verb 'Retrieve' and the resource 'all custom categories' with a user scope, making the core purpose clear. However, it does not differentiate this from the sibling getCategoriesByType, and the phrase 'all' is slightly inconsistent with the required 'type' parameter that filters by transaction 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?

No guidance is provided on when to use this tool versus getCategoriesByType or other sibling tools. The description does not mention any exclusion conditions or alternatives, leaving the agent to infer which tool fits the 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description is consistent with them but adds no new behavioral information. It does not disclose the date-filtering semantics, return shape, ordering, or pagination, so the description contributes little beyond the annotations.

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

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

A single sentence with no filler; the action and resource are front-loaded. It is appropriately sized for the tool's low complexity, even though it is terse.

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 low-complexity read-only tool, the optional date filters are documented and annotations cover safety. However, there is no output schema and the description does not clarify what a returned recurring transaction contains or how results are structured, leaving some completeness 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?

Both parameters are fully documented in the input schema with descriptions, so the schema carries the semantic burden. The tool description adds no parameter-level details, which is acceptable given the 100% 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 uses a clear action verb ('retrieve') and a specific resource ('recurring transactions'), which distinguishes it from the recurring-transaction mutation siblings and from getTransactions. It does not add scope details such as listing or date-filtering, so it is clear but not maximally informative.

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

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

The intended use is only implied by the verb and resource name; there is no explicit guidance about when to use this tool instead of getTransactions or the recurring-transaction mutation tools. No exclusions or alternative-selection conditions are provided.

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

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

Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only that the result is a list, but it does not disclose behavioral details such as date-range limits, default date handling, or whether recurring transactions are included or excluded.

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, but it is so terse that it borders on restating the tool title. It is adequately structured yet lacks substantive detail.

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

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

With no output schema and no description of return format, ordering, pagination, or how this relates to recurring transactions, the description leaves important context to inference. An agent can call it from the schema but would lack guidance on expected output and alternatives.

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 five parameters, their types, and constraints like the one-year endDate limit. The description adds no parameter-level meaning beyond what the schema provides.

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

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

The description clearly states a verb ('retrieve'), a resource ('transactions'), and a result shape ('a list'). However, it does not distinguish this tool from sibling read tools like getRecurringTransactions, so it stops short of full 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?

No guidance is given about when to use this tool versus alternatives such as getRecurringTransactions, createTransaction, or editTransaction. The description also does not mention any default behavior or recommended filter usage.

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

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

Annotations already indicate a non-read-only mutation, and the description adds the useful 'current period' scoping. However, it does not disclose what happens if the transaction is already done, whether the action can be reversed, or how 'done' differs behaviorally from 'skip'.

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 no filler. The verb, object, and temporal scope are all front-loaded, and every word contributes to understanding the tool's action.

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

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

Given the tool has only one parameter and a straightforward action, the description is minimally usable. But it does not clarify the relationship to skipRecurringTransaction, nor what the practical effect of 'done' is, leaving some important context for the agent to infer.

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

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

Schema description coverage is 100% for the single parameter, and the parameter itself is adequately described there. The tool description adds no additional meaning about transactionId, so it sits at the baseline for fully covered schemas.

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 ('recurring transaction'), and adds the scope 'for the current period', which distinguishes it from delete or skip operations. It is clear but does not explicitly differentiate itself from the closely related sibling skipRecurringTransaction.

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 skipRecurringTransaction or deleteRecurringTransaction. The sibling list makes these alternatives obvious, but the description never states the condition that should select this one over them.

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

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

The annotations are all false, providing no hints, so the description must carry the burden. It only states a mutation action ('set') without disclosing side effects, idempotency, permissions, or return behavior. This is insufficient for an agent to safely invoke the tool.

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

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

The description is a single short sentence with no fluff, which is concise and front-loaded. However, it is so terse that it omits necessary details, so while it is concise, it is not fully effective. The structure is acceptable but minimal.

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 that the tool has no parameters, no output schema, and no useful annotations, the description is extremely incomplete. It does not explain what inputs are needed (even though there are none), what the tool returns, or any side effects. An agent would not know how to use this tool effectively or what to expect.

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

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

There are zero parameters in the schema, and the description adds no parameter information. According to the rubric, with 0 parameters the baseline is 4, and since there is nothing to explain, this dimension is adequately covered. However, the tool's functionality is questionable without 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 'Set budget for categories' clearly identifies the action (set) and the resource (budget for categories), and it is distinct from the sibling getBudget. However, it lacks specificity about which categories or budget amounts, and the empty schema suggests the tool cannot actually perform its stated purpose. Overall, it conveys the basic purpose but is minimal.

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 like getBudget or createCustomCategories. It does not mention any conditions or prerequisites, leaving the agent to infer when a budget should be set. This is a significant gap for a tool that likely requires 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?

The annotations already indicate this is a non-read-only mutation, and the description simply restates that via 'set'. It does not disclose what happens when currency is null, whether the preference is persisted globally or per user, or whether an invalid or unset value resets the preference. With no output schema, the response behavior is also undisclosed.

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 four words, front-loaded, and free of filler. It is appropriately sized for a simple setter, though the brevity comes at the cost of missing behavioral and usage context.

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

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

For a mutation tool with one optional nullable parameter and no output schema, the description is too thin. It does not explain null semantics, the effect on existing preferences, or what a successful invocation returns. The enum supplies valid values, but an agent cannot fully predict the tool's behavior from this definition.

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 adds no parameter-level detail beyond the word 'currency'. The enum in the schema provides valid values, but the description does not explain the meaning of the currency field, the null option, or how it is applied. The description fails to compensate for the missing property descriptions.

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

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

The description 'Set currency preference' uses a specific verb and resource, clearly identifying this as a write operation on a currency preference. It is implicitly distinguished from the sibling getCurrency, though it does not specify whose preference is affected or any broader context.

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, what conditions lead to it, or how it relates to getCurrency. There is no mention of using getCurrency to read the current preference, nor any prerequisites or side effects. The usage is only implied by the name and 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?

All annotations are false, so they provide no safety or behavioral hints. The description does not disclose side effects, such as whether skipping removes the occurrence from the schedule, marks it as done, or is reversible. It also does not describe the resulting state change. This is not a contradiction, but the mutation's consequences are largely undisclosed.

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 short sentence with no filler. It front-loads the action and scope efficiently, which is appropriate for a simple one-parameter tool.

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

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

For a single-parameter mutation with no output schema, the description conveys the essential action and scope. However, sibling tools include markRecurringTransactionDone and deleteRecurringTransaction, and the description does not clarify how 'skip' differs from them or what consequences follow. 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 100%, and the single transactionId parameter is already described in the schema. The tool description itself adds no additional parameter semantics, so it remains at the baseline without enhancing understanding beyond the schema.

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

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

The description uses a clear imperative verb ('Skip') with a specific resource ('a recurring transaction') and a temporal scope ('for the current period'). This identifies the core action well, but it does not explicitly differentiate from the closely related sibling 'markRecurringTransactionDone', leaving a small amount of 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?

There is no explicit guidance on when to use this tool versus alternatives like markRecurringTransactionDone, deleteRecurringTransaction, or editRecurringTransaction. The phrase 'for the current period' provides some implied context, but no conditions, exclusions, or alternative tool references are given.

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