Server Quality Checklist

Tool Scores

• update_goal_progressD
  1.1/5.0
  Behavior1/5

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

  The description contradicts itself by first claiming to add a contribution (mutation) and then stating it is read-only and idempotent. This internal inconsistency severely undermines transparency. Also, rate limits and authentication details may not apply to this tool.

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

  Conciseness2/5

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

  The description is overly long with repetitive, boilerplate text that is not tool-specific. It could be much shorter and clearer.

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

  Completeness1/5

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

  Despite having an output schema, the description fails to explain the return value. The tool appears to be a budget tracking tool (based on sibling names) but the description is mismatched, leaving the agent unable to understand the tool's actual behavior.

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

  Parameters1/5

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

  The schema has 0% description coverage. The description only repeats parameter names with generic phrases like 'analyze or process', adding no meaningful information about how goal_id, amount, or api_key should be used in the context of updating progress.

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

  Purpose1/5

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

  The first sentence states 'Add contribution to a savings goal' implying a write operation, but the behavior section repeatedly claims it is read-only and stateless. This contradiction makes the purpose unclear and misleading.

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

  Usage Guidelines1/5

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

  The when-to-use and when-not-to-use sections are generic and copied from an analysis tool, not specific to updating goal progress. They do not help distinguish this tool from siblings or provide actionable guidance.

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

• add_expenseD
  1.4/5.0
  Behavior1/5

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

  The description claims the tool is read-only, stateless, and idempotent, but the tool name 'add_expense' implies a side-effecting write operation. This contradiction is a serious transparency issue. The detailed behavioral claims are likely false, and no annotations exist to clarify.

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

  Conciseness2/5

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

  The description is lengthy and repetitive, with redundant sections (e.g., 'Behavior' and 'Behavioral Transparency'). The contradictory statements waste space and clarity. A concise description would have focused on the actual function of adding an expense.

  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?

  Given the tool has 6 parameters with no schema descriptions and a complex purpose (expense recording), the description is highly incomplete. It omits crucial details like how amounts are processed, date format, and return value structure. An output schema exists but is not described, and the description's misleading nature makes it unreliable.

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

  Parameters1/5

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

  The 'Args' section merely repeats parameter names with the generic suffix 'to analyze or process', adding no meaningful semantics. Schema coverage is 0%, so the description should provide context, but it fails entirely. Parameters like 'budget_month', 'category', and 'amount' are not explained beyond their names.

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

  Purpose1/5

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

  The description begins by saying 'Record an expense transaction' but then immediately states the tool is read-only and stateless, which directly contradicts the name and the first sentence. This fundamentally misrepresents what the tool does, making it misleading for an AI agent.

  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?

  The 'When to use' and 'When NOT to use' sections are generic and do not relate to expense recording. They mention structured analysis and real-time decisions, which are irrelevant to the apparent purpose of adding an expense. No guidance is provided on how to use this tool versus siblings like 'add_income'.

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

• add_incomeD
  1.5/5.0
  Behavior1/5

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

  The description includes a detailed 'Behavioral Transparency' section claiming read-only, stateless, and idempotent behavior, which directly contradicts the tool's implied mutation purpose (add_income). This is a severe internal contradiction.

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

  Conciseness2/5

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

  The description is overly long with repetitive sections (e.g., 'Behavioral Transparency' appears twice). It could be much more concise without losing essential information.

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

  Completeness1/5

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

  Despite having an output schema (context signal), no details are provided about the return value. For a mutation tool, the description fails to explain what happens after recording income, making it incomplete.

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

  Parameters1/5

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

  Each parameter is described as 'the X to analyze or process', which is a boilerplate template adding no semantic value beyond the schema. With 0% schema description coverage, the description fails to explain parameter meanings or formats.

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

  Purpose2/5

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

  The initial sentence 'Record income for a budget period' aligns with the name, but the detailed behavior contradicts this by claiming the tool is read-only and produces analysis output. This confusion undermines purpose clarity.

  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?

  Provides generic guidance for 'structured analysis' rather than context for recording income. Does not differentiate from siblings like add_expense or create_budget.

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

• create_goalD
  1.6/5.0
  Behavior2/5

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

  The description provides extensive details on rate limits, authentication, error handling, and idempotency, but these are inconsistent with the tool's creation nature (claims read-only, no side effects). This creates confusion rather than clarity.

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

  Conciseness2/5

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

  The description is verbose with repetitive sections (e.g., 'Behavior' and 'Behavioral Transparency' overlap) and includes irrelevant content like rate limits and authentication for a basic creation tool. Not concise.

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

  Completeness1/5

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

  For a tool with 5 parameters and no annotations, the description is misleading and incomplete. It omits crucial context like what a savings goal is, how target_amount and target_date are used, or what structured output is returned. The output schema exists but is not referenced.

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

  Parameters1/5

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

  All parameter descriptions are generic ('The name to analyze or process') and add no value beyond the schema. With 0% schema coverage, the description fails to clarify parameter purpose or format for a savings goal tool.

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

  Purpose2/5

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

  The description begins with 'Create a savings goal' which is clear, but the subsequent text describes a read-only analysis tool, contradicting the creation purpose. The tool name suggests mutation, while the description claims no side effects.

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

  Usage Guidelines1/5

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

  The 'When to use' section recommends structured analysis or classification, which is irrelevant to creating a savings goal. No guidance on when to use this over sibling tools like create_budget or update_goal_progress.

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

• set_budget_alertD
  1.9/5.0
  Behavior2/5

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

  The description includes a detailed 'Behavioral Transparency' section covering side effects, authentication, rate limits, etc. However, it contradicts itself by first saying it sets an alert (implying mutation) and then claiming it is read-only and stateless. This internal inconsistency undermines transparency.

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

  Conciseness2/5

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

  The description is long and repetitive, with a 'Behavior' section followed by a near-duplicate 'Behavioral Transparency' section. The first sentence is contradictory. Important information is not front-loaded; the most critical purpose is muddled.

  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?

  Given 4 parameters and 0% schema coverage, the description should fully explain each parameter's role. It does not. The tool has an output schema but the description does not mention return values. The contradictory nature leaves the agent uncertain about whether this tool mutates state or not.

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

  Parameters1/5

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

  The schema has 0% description coverage, and the description's 'Args' section merely lists parameter names and types with generic descriptions (e.g., 'The month to analyze or process'). It adds no meaning beyond the schema. The tool's parameters like 'threshold_percent' are not explained in context of setting an alert.

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

  Purpose2/5

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

  The description opens with 'Set spending alert threshold for a category' suggesting a write operation, but then the behavior section claims it is read-only and produces analysis output. This contradiction obscures the actual purpose, making it unclear whether the tool modifies state or just analyzes.

  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?

  The 'When to use' and 'When NOT to use' sections are generic and not specific to setting a budget alert. The guidance mentions 'structured analysis or classification' which does not align with the tool name or the parameters (month, category, threshold, api_key). No sibling differentiation is provided.

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

• rollover_unusedC
  2.1/5.0
  Behavior2/5

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

  The description includes a detailed behavioral transparency section covering read-only, idempotency, rate limits, and error handling. However, these details directly contradict the tool's stated purpose of rolling over budget, creating confusion rather than clarity.

  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 structured with clear sections but is overly long and contains redundancy (e.g., Behavioral Transparency repeated in two places). Some sentences could be merged or removed without losing information.

  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?

  Given the tool has 3 parameters, no annotations, and an output schema, the description should explain return values and how the tool differs from siblings. It lacks output description and the core functionality is ambiguously presented, making it incomplete for accurate invocation.

  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?

  Parameter descriptions are generic and uninformative ('The source month to analyze or process'). They add minimal value beyond the schema titles and fail to specify format, constraints, or how each parameter is used in the rollover/analysis context.

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

  Purpose2/5

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

  The description states 'Rollover unused budget to next month' but then claims the tool is read-only and produces analysis output without modifying external systems. This contradiction obscures the actual purpose—whether it performs a rollover action or merely analyzes potential rollovers.

  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?

  The description gives generic guidance ('use for structured analysis') and an exclusion ('not for real-time production decisions'), but fails to differentiate from siblings like get_analytics or get_budget_status. No specific context on when to choose this tool over alternatives.

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

• get_goalsC
  2.3/5.0
  Behavior3/5

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

  The description provides extensive behavioral details (read-only, idempotent, rate limits, auth) but these are generic and may not accurately reflect the tool's behavior. Without annotations, this adds some context but is potentially misleading.

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

  Conciseness2/5

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

  The description is verbose and includes a template-like 'Behavioral Transparency' section that is not tailored to this tool. The first sentence is effective, but the rest is bloated and irrelevant.

  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?

  Despite having an output schema, the description does not explain what the tool returns (e.g., list of goals with progress). The generic text does not match the savings goal domain, leaving the agent underinformed.

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

  Parameters1/5

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

  Parameter descriptions like 'The status to analyze or process' are generic and do not add meaning beyond the schema. With 0% schema description coverage, the description fails to compensate.

  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 first sentence clearly states 'Get all savings goals with progress,' but the subsequent description contradicts this by discussing 'structured analysis or classification of inputs against established frameworks.' This ambiguity reduces clarity.

  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?

  The 'When to use' and 'When NOT to use' sections are generic and not specific to savings goals. No mention of when to use this tool over siblings like 'create_goal' or 'update_goal_progress'.

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

• transfer_fundsC
  2.3/5.0
  Behavior4/5

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

  Extensively covers side effects, authentication, rate limits, error handling, idempotency, and data privacy. However, the core claim of read-only conflicts with the tool name 'transfer_funds', which is a significant contradiction.

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

  Conciseness2/5

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

  The description is verbose with redundant sections (Behavior and Behavioral Transparency repeat the same information). It lacks conciseness and could be streamlined to 2-3 clear sentences.

  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?

  Despite extensive behavioral details, the description fails to explain the actual function of transferring funds, provides poor parameter documentation, and does not describe the output schema. The tool's core purpose remains ambiguous.

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

  Parameters1/5

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

  Schema coverage is 0%, so description must explain parameters. The 'Args' section provides generic phrases like 'The month to analyze or process' for each parameter, adding no meaningful semantic value beyond the schema field names.

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

  Purpose2/5

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

  The description initially says 'Transfer between budget categories', implying a mutation, but then claims it is read-only and produces analysis output, creating a contradiction that severely undermines clarity.

  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?

  Provides generic 'When to use' and 'When NOT to use' sections about structured analysis and human review, but lacks specific guidance on when to use this tool vs siblings like add_expense or add_income, and the guidance does not align with the tool's name.

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

• get_budget_statusC
  2.9/5.0
  Behavior4/5

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

  The description includes a thorough 'Behavioral Transparency' section covering side effects, authentication, rate limits, error handling, idempotency, and data privacy. However, there is redundancy with the 'Behavior' section and a minor inconsistency about authentication requirements (basic vs. pro/enterprise). Overall, it adds significant value beyond what annotations would provide.

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

  Conciseness2/5

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

  The description is overly long and repetitive, with duplicate information in the 'Behavior' and 'Behavioral Transparency' sections. The structure is somewhat organized but would benefit from consolidation and removal of redundant content.

  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?

  The description does not explain what 'budget status' means or provide any context about the output structure. While an output schema exists, the description should still offer a brief idea of the results. The generic 'structured analysis' framing is misleading for a budget-specific tool.

  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?

  The parameter descriptions in the 'Args' section are generic and uninformative. For 'month', the format is unspecified; for 'api_key', it merely repeats the parameter name. This adds little meaning beyond the schema, especially given 0% schema description coverage.

  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 first sentence clearly states the verb and resource: 'Get budget status for a month'. However, the subsequent generic text about 'structured analysis or classification' dilutes the specificity and may confuse an AI agent about the tool's exact purpose.

  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?

  The 'When to use' and 'When NOT to use' sections are generic and not tailored to budget status. They fail to differentiate this tool from siblings like get_analytics or get_category_spending, and provide no contextual advice about when to choose this tool over alternatives.

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

• get_transactionsB
  3.3/5.0
  Behavior5/5

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

  No annotations exist, so the description fully addresses this. It provides a dedicated 'Behavioral Transparency' section covering read-only, idempotency, authentication, rate limits, error handling, and data privacy, all specific and actionable.

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

  Conciseness2/5

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

  The description is overly long and repetitive, especially with the 'Behavior' and 'Behavioral Transparency' sections covering the same points. The 'Args' section is also unnecessarily redundant. It could be significantly streamlined.

  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?

  Despite the thorough behavioral transparency, the description lacks essential parameter usage details (format, examples, required vs optional) for the 6 parameters, leaving the agent underinformed for correct invocation.

  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?

  The 'Args' section simply repeats parameter names with the vague phrase 'to analyze or process', adding no meaningful details beyond the schema's titles and defaults. With 0% schema coverage, the description should compensate but fails to do so.

  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 first line 'List transactions with optional filters' clearly states the action (list) and resource (transactions), but the 'When to use' section introduces generic language about 'structured analysis or classification' that doesn't specifically align with listing transactions, slightly diluting clarity.

  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 includes 'When to use' and 'When NOT to use' sections, providing some guidance. However, it lacks explicit differentiation from sibling tools like get_analytics or get_budget_status, and the use case described is too generic.

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

• create_budgetA
  3.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully covers side effects (read-only, idempotent), authentication, rate limits, error handling, and data privacy. This exceeds the minimum needed and provides comprehensive transparency.

  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 long with multiple redundant sections (e.g., 'Behavior' and 'Behavioral Transparency' overlap). While structured, it could be more concise without losing key information.

  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?

  Given the complexity (4 parameters, nested objects, output schema exists), the description covers behavioral aspects well but lacks parameter details. The output schema likely compensates for return value information, but incomplete parameter semantics reduce completeness.

  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?

  Schema description coverage is 0%, yet the description's 'Args' section merely repeats parameter names and types with generic phrases like 'the month to analyze or process.' No examples, formats, or constraints are given for the nested 'categories' dictionary or the expected income value.

  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 'Create a monthly budget with category allocations' and explains that it generates structured output without modifying systems. This distinguishes it from mutating siblings like add_expense, though no explicit differentiation is given.

  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?

  There are 'When to use' and 'When NOT to use' sections, but the guidance is somewhat vague ('structured analysis or classification') and does not contrast with sibling tools like create_goal or get_budget_status. Rate limits are included but are more about behavioral transparency.

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

• get_analyticsA
  3.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels: it details side effects (read-only, stateless), authentication, rate limits (10/day free, unlimited pro), error handling (structured errors), idempotency, and data privacy. This is exemplary transparency.

  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 well-structured with clear sections but is verbose and contains redundancy (e.g., 'Behavior' and 'Behavioral Transparency' overlap). It could be more concise without losing information.

  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 description covers behavioral aspects thoroughly but lacks detailed parameter guidance and doesn't fully clarify the analytics scope (e.g., what frameworks or standards?). With an output schema present, return values are assumed covered, but overall completeness is moderate.

  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?

  The input schema has 0% description coverage, and the description's 'Args' section provides only minimal one-liners (e.g., 'The month to analyze or process'). No format, examples, or constraints are given, failing to compensate for the schema gap.

  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 'Get spending analytics' and explains it provides structured analysis/classification. However, it does not explicitly distinguish it from similar sibling tools like get_category_spending, leaving some ambiguity.

  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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear context for appropriate invocation. It correctly notes it is not for real-time production decisions, but lacks comparison to alternative sibling tools.

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

• get_category_spendingA
  3.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and delivers comprehensively. It details side effects (read-only, stateless), authentication (none for basic, API key for pro), rate limits (10/day free, unlimited pro), error handling (structured errors), idempotency (fully idempotent), and data privacy (no storage or transmission).

  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 well-structured with labeled sections but is wordy, including generic 'When to use/not use' sections that apply broadly. It could be more concise by focusing on tool-specific details, though the organization aids scanning.

  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?

  Despite having an output schema, the description lacks specifics on what 'spending by category' entails (e.g., aggregation of expenses, time range). Parameter details are insufficient. However, behavioral aspects like rate limits and idempotency are well-covered. Overall, it meets minimum viability but has gaps.

  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?

  Schema description coverage is 0%, so description must compensate. The 'Args:' section merely repeats parameter names with generic meanings ('The month to analyze or process') without adding format, valid values, or optionality. The api_key description is confusing given the authentication statement. No enums or concrete examples are provided.

  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 title 'get_category_spending' and description 'Get detailed spending by category' clearly state the verb 'get' and resource 'detailed spending by category'. This distinguishes it from sibling tools like 'get_analytics' or 'get_transactions', which serve different purposes.

  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 includes a 'When to use' and 'When NOT to use' section, but these are generic statements about structured analysis and real-time production use, not specific to this tool. It does not explicitly compare to siblings or exclude alternatives, so guidance is implied but not precise.

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