Server Quality Checklist

Tool Scores

• budget_dashboardC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It says 'Browse' (implying read-only) but doesn't disclose whether this is safe, what data scope is covered, whether the chart is static or interactive, or what happens with the limit/month parameters that appear in the schema but are unexplained in the description.

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

  Conciseness4/5

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

  Single sentence, zero waste, front-loaded with the action verb. Efficient though under-specified.

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

  Completeness2/5

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

  No output schema, no annotations, 3 undocumented params, and no differentiation from 11 siblings. The description is far too thin for a tool with this complexity and ambiguity about what 'browse' returns.

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

  Parameters2/5

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

  With 0% schema description coverage, the description must compensate, but it mentions none of the three parameters (type, limit, month). No meaning is added beyond what the schema's raw property names imply, which is minimal for 'type' and 'month'.

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

  Purpose3/5

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

  The description states it browses a budget dashboard with a category breakdown chart and transaction data table, giving a specific verb and resource. However, it doesn't clearly differentiate from siblings like get_transactions or get_summary, which could overlap with the dashboard's data display.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus siblings like get_transactions, get_summary, or spending_trends. It doesn't state what makes the dashboard distinct from querying individual data sources directly.

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

• spending_trendsB
  3.1/5.0
  Behavior2/5

  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 mentions the output includes a line chart and transaction data table, which is some useful transparency about return format, but it doesn't disclose default behaviors like the 500-record limit, the default type='expense' filter, or whether data is read-only. It's a browse tool so non-destructive intent is implied but not stated.

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

  Conciseness4/5

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

  Single sentence, efficient, front-loaded with the verb and purpose. Zero wasted words. Could arguably include more detail, but what's present is tight and well-structured.

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

  Completeness2/5

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

  For a browse tool with 0% schema coverage, 4 undocumented parameters, no output schema, and no annotations, this description is under-specified. It explains the output visuals (line chart, data table) but doesn't explain parameter effects, defaults, date format expectations, or the expense-only default behavior. Given the moderate complexity, more context is warranted.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate for the four parameters (type, limit, end_date, start_date). However, the description only explains the grouping dimension (year-month) and says nothing about what type, limit, or date filters control or their formats. This is a partial compensation at best, leaving the date format and filter semantics unexplained.

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

  Purpose4/5

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

  The description clearly states the tool browses spending trends over time, explicitly grouping by year-month and mentioning a line chart plus transaction data table. It uses a specific verb (browse) and resource (spending trends), and while it doesn't explicitly name sibling alternatives, the focus on 'trends' and 'year-month grouping' distinguishes it from plain get_transactions or get_summary.

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

  Usage Guidelines3/5

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

  The description implies this is for viewing temporal spending trends, which is distinct from listing transactions or getting summaries, but it provides no explicit guidance on when to choose this over get_transactions, get_summary, or budget_dashboard. No exclusions or alternative names are mentioned.

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

• delete_transactionB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It mentions that deletion supports single or multiple IDs, but doesn't reveal what happens on deletion (irreversibility, associated records affected, return shape) or whether this is destructive (which deletion inherently implies). For a mutation tool, the description should explicitly warn about irreversibility.

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

  Conciseness4/5

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

  The description is compact, front-loaded with the core purpose, and uses bulleted parameter clarification. It's efficient with no wasted words. Could arguably be more structured but is appropriately concise.

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

  Completeness3/5

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

  The tool has a mutation behavior with no annotations and no parameter descriptions in the schema. While it has an output schema, the description doesn't state what the deletion returns (e.g., count deleted, success confirmation). For a delete operation with ambiguous dual-parameter design, the description is adequate but lacks detail on result/return behavior and edge cases like nonexistent IDs.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. The description clarifies that transaction_ids accepts either an integer or a list, and that transaction_id is an alias for single-ID deletion. This adds meaningful semantics beyond what the schema's anyOf structure conveys, particularly the alias relationship between the two parameters.

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

  Purpose4/5

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

  Clear verb+resource: 'Delete one or more transactions by ID.' The purpose is specific and the distinction between transaction_ids (list or single) and transaction_id (alias for single) is clarified. It doesn't explicitly differentiate from delete_category sibling, but the resource is clearly transactions.

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

  Usage Guidelines3/5

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

  The description explains the two parameter forms and highlights transaction_id as an alias, giving some usage guidance. However, it doesn't state when one param should be preferred over the other, nor does it disambiguate from sibling delete_category when deleting transactions vs categories. The ambiguity between transaction_id and transaction_ids as alternatives is noted but not resolved with clear guidance.

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

• update_categoryA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so description carries the burden. 'Update' implies mutation but the description doesn't state whether fields not passed are preserved unchanged (partial vs full update semantics), whether updating type could affect existing transactions, or what happens if the category_id_or_name doesn't match. It doesn't describe return values, though an output schema exists.

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

  Conciseness4/5

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

  Compact bulleted parameter list is front-loaded and readable. Every line earns its place. Could be slightly more concise but the structure is clear and efficient.

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

  Completeness3/5

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

  The output schema exists, so return values needn't be explained. But for a mutation tool with no annotations, the description should clarify update semantics (partial vs full replacement, whether null means 'no change'), effects on linked transactions, and what empty optional fields imply. These gaps matter for a category-update operation with 4 parameters.

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

  Parameters4/5

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

  Schema description coverage is 0%, but the description fully documents all four parameters with clear semantics ('Optional new name', 'ID or current name of the category to update', etc.). This compensates well for the complete lack of schema descriptions, though it doesn't add format details or constraints beyond names.

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

  Purpose4/5

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

  Clear verb+resource: 'Update an existing category's name, type, or description.' Distinguishes from siblings since delete_category, add_category, and list_categories exist, and this clearly targets modifying an existing category while specifying the mutable fields.

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

  Usage Guidelines3/5

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

  The description implies usage context (updating existing categories) but provides no explicit when/when-not guidance or exclusions. It doesn't distinguish from update_transaction pitfalls or explain when to prefer this over add/delete category operations, though siblings make the purpose fairly obvious.

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

• delete_categoryA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It does disclose that transactions can be reassigned via reassign_to_category_id, which hints at a destructive-with-mitigation behavior. However, it doesn't explicitly state deletion is irreversible, what occurs if reassignment is omitted when transactions exist, or whether deletion cascades. Adequate but not rich.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the core purpose, then bullet points add parameter detail. Formatting is clean and scannable. Minor redundancy exists (both single and batch params explained), but overall it's efficient.

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

  Completeness3/5

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

  For a destructive tool with zero annotations and 3 undocumented params, the description covers the essential mechanics. An output schema exists, so return-format explanation isn't needed. However, critical behavioral gaps remain: what happens if no reassignment is specified for categories with linked transactions, error handling for nonexistent categories, and precedence between the two deletion parameters.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. It does explain the purpose of each of the 3 parameters (category_ids_or_names, category_id_or_name alias, reassign_to_category_id). This adds meaning beyond the raw schema. However, it doesn't clarify precedence if both category_id_or_name and category_ids_or_names are provided, or the exact accepted types/format rules for IDs vs names.

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

  Purpose5/5

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

  Description uses a specific verb+resource combo ('Delete one or more categories') and explicitly states the scope (from the library). It distinguishes from siblings like add_category/update_category/list_categories by focusing on deletion. The single/batch distinction is also made clear.

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

  Usage Guidelines3/5

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

  The description explains the mechanism for deletion (single vs list, reassignment target). However, there is no explicit 'when to use vs alternatives' guidance, no mention of what happens if a category has linked transactions without reassignment, and no note on irreversible destructive effects. It's implied usage but not clearly scoped.

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

• list_categoriesA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description should carry the behavioral burden. The tool name implies read-only (list), and the description confirms it lists categories. However, it doesn't disclose return format, pagination, or whether it returns both expense and income categories together when no type is given. The description adds some value but leaves return-behavior details unexplained despite an output schema existing.

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

  Conciseness5/5

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

  Three bullet-point-style lines, each earning its place: purpose statement, parameter clarification, and usage guidance. Front-loaded with the primary verb phrase. Zero waste.

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

  Completeness3/5

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

  For a simple 1-parameter tool with an output schema present, the description covers the core purpose and parameter semantics. It's reasonably complete, though it could mention whether listing categories includes custom user-created ones versus only 'established/standard' ones—the word 'established' is ambiguous. Given the simplicity of the tool, this is adequate but not rich.

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

  Parameters3/5

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

  The description adds meaning to the single 'type' parameter by specifying it filters by 'expense' or 'income', which the schema does not document (0% coverage, no enums). However, the values 'expense' and 'income' are given but no format clarification (e.g., exact string casing) is provided. With only 1 parameter, the description compensates reasonably but not fully.

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

  Purpose4/5

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

  The description states a clear verb+resource ('List established categories available for transactions') and distinguishes from sibling tools by relating to categories rather than transactions or summaries. It doesn't explicitly differentiate from add_category/update_category/delete_category, but the read-only nature and the guidance about viewing before creating provides implicit distinction.

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent to use this tool 'to see standard existing categories before creating new ones', which is clear when-to-use guidance. It doesn't mention when NOT to use it or name specific alternatives, but the context of 'before creating new ones' ties it to the add_category sibling, providing useful contextual guidance.

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

• get_summaryA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains what the tool returns (summary of expenses, income, net balance) and mentions 'optional category breakdown,' but it does not disclose aggregation semantics (e.g., whether results are grouped by month, whether date filters are inclusive, what happens with no filters - does it return all-time data?). For a read/query tool with zero annotation coverage, some of this is acceptable, but behavioral details like inclusive date boundaries and default scope are missing.

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

  Conciseness3/5

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

  The description is front-loaded with a clear one-sentence summary, followed by a bulleted parameter list. This is well-structured. However, the parameter documentation is somewhat verbose for a read tool - each parameter gets its own line even though the schema already lists them. Given zero schema coverage, this duplication is justified, but the line-by-line format could be tightened. It earns its place but isn't maximally crisp.

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

  Completeness4/5

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

  The tool has 6 optional parameters with zero schema coverage, making it a fairly complex/ambiguous surface. The description documents every parameter with format and semantics. It has an output schema, so return-value structure needn't be explained. The main gap is not describing the default behavior with no filters (does it summarize all history?) and the aggregation granularity. But given the output schema exists and params are fully documented, the description is reasonably complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions, so the tool description must carry the full load. It does: each of the 6 parameters is explained with format hints (YYYY-MM, YYYY-MM-DD), type hints (integer, boolean), and semantic meaning (filter by month, category from list_categories, transaction type). The by_category flag is explained as including a detailed category breakdown. This fully compensates for the zero schema coverage.

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

  Purpose5/5

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

  The description clearly states what the tool does: 'Get a summary of expenses, income, and net balance with flexible filtering and optional category breakdown.' This is a specific verb (get) + resource (summary) + scope (expenses/income/net balance with filtering). It distinguishes from siblings like get_transactions (which returns itemized records) and spending_trends (which shows patterns over time) by focusing on aggregated summary values.

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

  Usage Guidelines4/5

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

  The description lists all available filters (month, date range, category, type, by_category) which gives clear context for when to use this tool. However, it does not explicitly state when NOT to use it or name alternatives (e.g., when to use get_transactions instead of get_summary, or when to use spending_trends). The sibling tools are discoverable, but no exclusions or alternatives are named.

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

• get_transactionsA
  4/5.0
  Behavior3/5

  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 filtering behavior and the default limit of 50 records, providing some transparency about pagination/result caps. However, it doesn't mention behavioral nuances like whether filters can be combined, the behavior of conflicting filters (e.g., max_amount < min_amount), or any 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.

  Conciseness4/5

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

  The description is front-loaded with the main intent followed by a clean, well-organized bulleted list of all 9 parameters. Each bullet is terse and single-purpose. Slightly verbose given the number of parameters, but every line earns its place since schema coverage is zero.

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

  Completeness4/5

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

  For a 9-parameter filter tool, the description is quite complete — every parameter is documented with format and semantics, and the default limit is stated. An output schema exists, so return-value documentation is unnecessary. Minor gaps include lack of guidance on filter combination behavior and no mention of the tool's relationship to get_uncategorized_transactions, but overall this is solid coverage.

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

  Parameters5/5

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

  Schema description coverage is 0% — the JSON schema provides only types and defaults with no descriptions. The tool description fully compensates by documenting every single parameter with its type, format (YYYY-MM, YYYY-MM-DD), and semantic meaning (e.g., 'transactions on or after', 'amount >= min_amount', 'keyword search matching description or category'). This is comprehensive parameter documentation.

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

  Purpose5/5

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

  The description states a clear verb+resource ('Get transactions') and explicitly defines the scope as filter-based retrieval across 9 criteria. It distinguishes well from siblings like add_transaction, update_transaction, and get_summary since it's clearly a read/list operation with filtering.

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

  Usage Guidelines3/5

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

  The description explains how to use filters (each parameter with format and semantics) but provides no explicit when-to-use guidance versus alternatives. Siblings like get_uncategorized_transactions and spending_trends exist, but no exclusions or alternative suggestions are given. The usage is clearly implied for filtered transaction listing but not differentiated from these siblings.

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

• add_categoryA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It does explain the batching capability and that items can be a list OR dict, but does not disclose return values, uniqueness enforcement behavior, validation nuances, or whether batch partially succeeds on error. As a create/mutation tool with no annotation coverage, more behavioral disclosure would help.

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

  Conciseness4/5

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

  Well organized with a clear lead sentence and bullet-style parameter breakdown. Every line adds value. Slightly verbose in backticks but acceptable for a dual-mode tool that needs to disambiguate the items vs single-param path.

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

  Completeness4/5

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

  For a moderate-complexity creation tool with no annotations and 0% schema coverage, the description covers the two modes, all fields, defaults, and type constraints. The presence of an output schema reduces the need to document return values. Minor gap: no mention of error handling or duplicate-name behavior, but overall adequate.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must document all parameters, and it does thoroughly: name (unique), type (expense/income, defaults to expense), description, and items (list/dict of category dicts with named fields). It adds meaningful defaults, allowed values, and structural context beyond what the raw schema shows.

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

  Purpose5/5

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

  Clear verb+resource: 'Create one or more categories in the category library.' The description distinguishes itself from siblings like update_category and delete_category, and explicitly notes that it differs from add_transaction. It also states the operational modes (single vs batch via items).

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

  Usage Guidelines4/5

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

  The description explains the two invocation modes: single-category params (name/type/description) OR batch via `items`, and how they interact ('name used if items is omitted'). It lacks explicit when-not-to-use guidance or explicit alternatives, but the mode selection clarity is strong enough to guide the agent correctly.

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

• get_uncategorized_transactionsA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden of behavioral disclosure. It discloses the sorting behavior (alphabetical by description) and default limit of 100, which is useful. However, it doesn't cover what the output looks like, whether pagination is supported beyond the limit parameter, or any safety/read-only implications. The read-only nature is implied by the name and purpose but not explicitly stated. It's better than many but leaves some gaps.

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

  Conciseness5/5

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

  The description is well-structured with a clear opening sentence stating the primary behavior, followed by a paragraph explaining the use case, and then a bulleted argument list. Every sentence earns its place — the use-case paragraph adds real value rather than padding. No redundancy or fluff.

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

  Completeness4/5

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

  The tool has an output schema (which covers return values) and only 3 simple optional parameters. The description fully covers the purpose, use case, sorting behavior, and all parameters. It's complete for a straightforward read/list tool. It's slightly short of a 5 because it doesn't explicitly note read-only behavior or describe pagination/limits beyond the default, but given the output schema fills return-value details, this is adequately complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, and there are no enum or format constraints in the schema. The description compensates by explaining each parameter: type filters by transaction type ('income' or 'expense'), search is a keyword filter for description, and limit is max records with a default of 100. However, the description adds some value beyond the bare schema, achieving the baseline 3, but doesn't go further with details like exact matching semantics, wildcard support, or case sensitivity of the search parameter.

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

  Purpose5/5

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

  The description clearly states the tool retrieves uncategorized transactions sorted alphabetically by description, with the specific purpose of systematic categorization after bulk import. This distinguishes it from siblings like get_transactions (general retrieval) and list_categories (category listing). The verb+resource+sorting behavior is specific and well-defined.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool: 'Designed for systematic categorization after bulk import' and specifically 'retrieve transactions imported without categories.' It also explains WHY it's useful (sorting groups similar merchants, enabling fast bulk updates via update_transaction), which requires reading the update_transaction sibling tool. This is strong usage guidance that implicitly contrasts with get_transactions.

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

• update_transactionA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It states what fields can be updated and describes the batch capability, which is helpful. However, it doesn't disclose whether updates are destructive to unmentioned fields, whether invalid IDs cause failures, permission requirements, or what the return value looks like. It doesn't mislead, but it adds only moderate behavioral context.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose and includes a clearly separated workflow section. It's a bit verbose with repeated listing of updateable fields, and the Arguments section partially duplicates the input schema (though justified since schema coverage is 0%). Still, the structure with headers and example is well-organized and earns most of its length.

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

  Completeness4/5

  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 annotations and a 0% schema-coverage, the description does substantial work: it explains all parameters, provides a usage workflow, and a concrete batch example. An output schema exists, so return-value explanation is not required. Gaps include missing clarification on error/validation behavior and partial-update semantics, but overall it's reasonably complete for the tool's complexity.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate fully. It does: each parameter is given a brief semantic explanation (transaction_id sets which record, category_id assigns category from list_categories, type constrains to expense/income, date uses YYYY-MM-DD format). This adds real meaning beyond the bare schema. The items-parameter explanation is notably richer, describing its structure and batch purpose. Minor gap: it doesn't clarify whether batch operations are atomic.

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

  Purpose5/5

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

  The description clearly states the verb (update) and resource (existing transactions by ID), and explicitly enumerates the updatable fields (category_id, amount, description, type, or date). It also describes both single and batch modes, which distinguishes it well from sibling mutation tools like delete_transaction and add_transaction.

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

  Usage Guidelines5/5

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

  The description explicitly details when to use the tool, including the batch mode via 'items' and the systematic categorization workflow example. It names list_categories as the source for category_id, providing concrete integration context. It doesn't explicitly state when NOT to use it vs. delete/add siblings, but the batch workflow example provides strong usage guidance.

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

• add_transactionA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It transparently discloses that omitting category_id logs as 'Uncategorized', that type defaults to 'expense', and that items supports batch or single dict insertion. However, it doesn't describe return values or confirm what happens on validation failure despite having an output schema.

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

  Conciseness4/5

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

  The description is well-organized with a clear bulk-import workflow section and a structured Arguments list. It's somewhat lengthy but every section earns its place given the dual single/batch modes. Could trim slightly but structure is logical and scannable.

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

  Completeness5/5

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

  For a tool with 6 parameters, 0% schema coverage, and no annotations, the description is remarkably complete. It documents all parameters, the dual usage modes, the batch import workflow referencing sibling tools, and type/date formats. The only minor gap is not describing the output schema, but that exists separately, so the description doesn't need to explain it.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must fully compensate. It thoroughly documents every parameter: amount, category_id (with source from list_categories), description, type (with enum values and default), date (with format), and items (with the full dict structure). The items parameter structure is particularly well documented given the schema only shows additionalProperties:true.

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

  Purpose5/5

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

  The description clearly states it adds income or expense transactions to the budget, with a specific verb+resource ('add transactions'). It distinguishes from siblings by explicitly covering both single and batch insertion, and the bulk-import workflow differentiates it from update_transaction and delete_transaction.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use it (adding/importing transactions) and explicitly references sibling tools like get_uncategorized_transactions for post-import review and update_transaction for categorization. It doesn't explicitly state when NOT to use it, but the workflow guidance gives strong usage context.

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