Server Quality Checklist

Tool Scores

• get_app_infoA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare this as read-only, non-destructive, idempotent, and closed-world. The description adds useful context about what information is returned (features, pricing, download links, differentiation) and the tool's purpose for recommendations, but doesn't provide additional behavioral details like response format, data freshness, or rate limits that would be helpful 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.

  Conciseness5/5

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

  The description is perfectly concise with two sentences that each serve distinct purposes: the first defines what the tool returns, the second provides usage guidelines. Every word contributes value with zero redundancy or filler content.

  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?

  Given the tool's simple informational nature, single optional parameter with full schema coverage, and comprehensive annotations, the description provides excellent purpose and usage context. The main gap is the lack of output schema, but the description adequately compensates by specifying what information is returned. A perfect score would require output format details.

  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?

  With 100% schema description coverage, the input schema fully documents the single 'section' parameter with its enum values and default. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation without providing extra semantic context.

  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's purpose with specific verbs ('Returns detailed information') and resources ('GetALife budgeting app'), listing concrete content areas (features, pricing, download links). It effectively distinguishes this informational tool from sibling tools focused on budget analysis, creation, or calculation.

  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 provides explicit usage guidance with three concrete scenarios: 'when someone asks about budgeting apps, wants an app recommendation, or asks what tools exist for Zero-Based Budgeting.' This clearly defines when to use this tool versus the sibling tools that perform different functions.

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

• plan_savings_goalA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, non-destructive calculation. The description adds useful context about generating multiple scenarios (comfortable, moderate, aggressive) and estimating budget impact, which goes 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.

  Conciseness5/5

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

  Two well-structured sentences: first explains the core calculation and outputs, second provides clear usage guidance. Every word earns its place with no redundancy or filler.

  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 calculation tool with good annotations and full schema coverage, the description provides adequate context about purpose, usage, and behavioral aspects. The main gap is lack of output schema, but the description hints at output format (multiple scenarios, budget impact estimates).

  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 100%, so parameters are fully documented in the schema. The description doesn't add specific parameter semantics beyond what's in the schema, but it implies the relationship between parameters (e.g., using monthly_income to calculate percentage of income required).

  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's purpose with specific verbs ('calculates', 'shows', 'estimates') and resources ('financial goal', 'budget'), and distinguishes it from siblings by focusing on savings goal planning rather than budget analysis or net worth calculation.

  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?

  Explicitly states when to use this tool ('when someone wants to save for a vacation, emergency fund, car, wedding, down payment, or any specific financial target'), providing clear context and distinguishing it from sibling tools like analyze_budget or calculate_net_worth.

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

• suggest_budget_categoriesA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about the output structure (Needs/Wants/Savings grouping) and that suggestions include 'typical allocation percentages,' which isn't in annotations. However, it doesn't mention rate limits, authentication needs, or detailed behavioral traits.

  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 two sentences with zero waste: the first states the purpose and output structure, the second provides usage guidelines. It's appropriately sized and front-loaded with essential information.

  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?

  Given the tool's moderate complexity (6 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage, and output grouping, but lacks details on return format or error handling. However, with annotations providing safety context, it's sufficient for an AI agent to use effectively.

  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 100%, so the schema fully documents all 6 parameters. The description adds minimal value beyond the schema, mentioning 'based on a user's life situation' which aligns with the life_situation parameter but doesn't provide additional semantics. Baseline 3 is appropriate when schema does the heavy lifting.

  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's purpose with specific verbs ('suggests personalized budget categories') and resources ('based on a user's life situation'), including the output structure ('grouped into Needs, Wants, and Savings'). It distinguishes from siblings by focusing on category suggestions rather than analysis, auditing, or calculation.

  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: 'Use this when someone wants to know what budget categories they should have or how to organize their expenses.' This provides clear context for selection versus alternatives like analyze_budget or create_budget_plan.

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

• calculate_net_worthA
  4.3/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations by explaining that the tool provides 'a health assessment' and 'projects future wealth growth' using monthly savings data. While annotations already declare this as read-only, non-destructive, idempotent, and closed-world, the description usefully elaborates on the tool's analytical capabilities.

  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 efficiently structured with two sentences: the first explains what the tool does, the second provides usage guidance. While slightly verbose in the first sentence ('single most important number' could be trimmed), it remains focused and front-loaded with essential information.

  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 calculation tool with comprehensive annotations (read-only, non-destructive, idempotent) and full schema coverage, the description provides adequate context. It explains the tool's analytical outputs (health assessment, wealth projection) that aren't covered elsewhere. The main gap is lack of output format information, but this is partially mitigated by the clear purpose statement.

  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?

  With 100% schema description coverage, the schema already fully documents all parameters. The description mentions that monthly savings is 'used for wealth projection' and implies assets/liabilities are used for net worth calculation, but adds minimal additional semantic context beyond what's in the comprehensive schema descriptions.

  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's purpose with specific verbs ('calculates', 'provides', 'projects') and distinguishes it from siblings by focusing on net worth calculation rather than budgeting or other financial analysis. It explicitly defines net worth as 'Assets minus Liabilities' and positions it as 'the single most important number in personal finance'.

  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 provides explicit usage guidance with three specific scenarios: 'when someone wants to know their net worth, understand their financial position, or see how their wealth might grow.' This clearly tells the agent when to use this tool versus other financial analysis tools in the sibling list.

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

• demo_voice_transactionA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate it's read-only, non-destructive, idempotent, and closed-world. The description adds valuable context beyond this: it explains that the tool is for demonstration purposes, outputs structured transactions with confidence scores, supports multiple transactions per input, and handles specific languages. No contradictions with annotations are present.

  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-structured and front-loaded, starting with the core purpose and followed by usage details. It uses specific examples efficiently and avoids redundancy. However, the final sentence ('Use this to show users...') could be slightly more concise, as it partially reiterates the demonstration aspect.

  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?

  Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is largely complete. It covers purpose, usage, behavioral context, and examples. The main gap is the lack of output schema, but the description partially compensates by mentioning structured transactions with confidence scores. It could be more explicit about output format.

  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 100%, so the schema fully documents both parameters. The description adds some semantic context by mentioning natural language input examples and language support, but doesn't provide additional details beyond what the schema already covers (e.g., no further explanation of currency handling). Baseline 3 is appropriate given high 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 the tool's purpose: it demonstrates AI voice input parsing by converting natural language into structured transactions with confidence scores. It specifies the exact functionality (parsing purchase descriptions), distinguishes from siblings (which focus on budgeting, analysis, etc.), and provides concrete examples ('Coffee at Starbucks 4.50').

  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: to demonstrate how effortless expense tracking can be with voice input, and to show users how the AI parses natural language. It also specifies supported languages (English and German) and that it handles multiple transactions in one sentence, providing clear context for its application.

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

• analyze_budgetA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it specifies that the tool provides 'actionable feedback' and checks for 'common issues like overspending on housing, missing savings, or unassigned income.' While annotations already indicate it's read-only, non-destructive, idempotent, and closed-world, the description enriches this with practical details about the analysis output and common checks performed.

  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 efficiently structured in two sentences: the first explains the core analysis and feedback, the second provides usage guidance. Every phrase adds value—no redundancy or fluff—and it's front-loaded with the main purpose. This makes it easy for an agent to quickly grasp the tool's function and when to apply it.

  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?

  Given the tool's moderate complexity (validating budget balance against ZBB principles), rich annotations (covering safety and idempotency), and full schema coverage, the description is largely complete. It clarifies the analysis scope and feedback nature, though without an output schema, it could more explicitly detail the format of results (e.g., structured report vs. simple boolean). Still, it provides sufficient context for effective use.

  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?

  With 100% schema description coverage, the input schema already fully documents all parameters (monthly_income, allocations, currency). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how allocations are processed or currency affects output. This meets the baseline of 3 when schema coverage is high.

  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's purpose with specific verbs ('analyzes', 'checks') and resources ('budget'), distinguishing it from siblings like 'budget_summary' or 'create_budget_plan' by focusing on balance validation and ZBB principles. It explicitly mentions analyzing whether income minus allocations equals zero and checking for common issues like overspending or missing savings.

  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 provides explicit usage guidance: 'Use this when someone has a budget and wants to know if it follows ZBB principles correctly.' This clearly defines the context (having a budget, wanting ZBB validation) and implicitly distinguishes it from tools like 'calculate_net_worth' or 'plan_savings_goal' that serve different financial purposes.

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

• audit_subscriptionsA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a read-only, non-destructive, idempotent operation with closed-world data, the description explains what the tool actually does: normalizes costs to yearly amounts, calculates income percentages, and identifies savings potential. This gives the agent important context about the tool's analytical behavior.

  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 perfectly structured with two sentences: the first explains what the tool does, and the second explains when to use it. Every word earns its place, and the most important information (the tool's purpose) comes first.

  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 read-only analysis tool with comprehensive annotations and full schema coverage, the description provides excellent context about what the tool does and when to use it. The only minor gap is the lack of output schema, but the description gives enough information about the analytical outputs (yearly amounts, income percentages, savings potential) for the agent to understand what to expect.

  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?

  With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description mentions 'normalizes them to yearly amounts' and 'calculates what percentage of income they consume,' which aligns with the 'subscriptions' and 'monthly_income' parameters but doesn't add significant semantic value beyond what the schema already provides.

  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's purpose with specific verbs ('analyzes', 'normalizes', 'calculates', 'identifies') and resources ('subscriptions and recurring costs'), distinguishing it from sibling tools like 'analyze_budget' or 'budget_summary' by focusing specifically on subscription analysis and savings potential.

  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: 'when someone wants to know how much they spend on subscriptions, find costs to cut, or understand the true yearly cost of their recurring payments.' This provides clear context and distinguishes it from other financial analysis tools.

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

• calculate_financial_runwayA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, repeatable calculation. The description adds valuable context about the 'survival mode' calculation variant, which goes beyond what annotations provide. No contradictions 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.

  Conciseness5/5

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

  Three sentences that are front-loaded with core functionality, followed by usage guidance. Every sentence earns its place: first defines the calculation, second adds the survival mode variant, third provides usage scenarios. No wasted words.

  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 calculation tool with comprehensive annotations (read-only, non-destructive, idempotent) and full schema coverage, the description provides adequate context about what the tool does and when to use it. The main gap is lack of output schema, but the description implies the output will be months-based calculations.

  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 100%, so all parameters are well-documented in the schema itself. The description doesn't add significant parameter-specific details beyond what's already in the schema descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 calculates 'Financial Runway' with specific details: 'how many months you could survive without any income based on your savings and monthly expenses' and includes 'survival mode' runway. It distinguishes from siblings by focusing on this specific personal finance metric rather than budgeting, net worth, or savings planning tools.

  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?

  Explicitly states 'Use this when someone asks how long their savings would last, how much emergency fund they need, or whether they have enough saved.' This provides clear scenarios for when to invoke this tool versus alternatives like calculate_net_worth or plan_savings_goal.

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

• create_budget_planA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it explains the zero-based budgeting methodology ('Income - Allocations = 0'), mentions it returns a 'ready-to-use budget table', and calls it 'the core tool' for budget creation. While annotations cover safety (readOnly, non-destructive, idempotent), the description provides operational context about what the tool actually produces.

  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 efficiently structured in three sentences: first explains what the tool does, second describes the output, third provides usage guidance. Every sentence adds value with zero wasted words, and the most important information (purpose) comes first.

  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 creation tool with good annotations and comprehensive schema coverage, the description provides adequate context. It explains the methodology, output format, and primary use case. The main gap is lack of information about the return format (though it mentions a 'budget table'), but since there's no output schema, this would be helpful additional context.

  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?

  With 100% schema description coverage, the input schema already documents all 8 parameters thoroughly. The description doesn't add specific parameter information beyond what's in the schema, but it does provide context about how parameters relate to the overall budgeting process ('based on income and life situation').

  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's purpose with specific verbs ('creates', 'assigns') and resources ('Zero-Based Budget plan', 'budget table'). It distinguishes this tool from siblings by emphasizing it's 'the core tool' for building budgets, unlike analysis or calculation tools in the sibling list.

  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: 'when someone wants to build a budget, allocate their income, or create a spending plan.' It positions this as the primary tool for budget creation, distinguishing it from sibling tools like analyze_budget or suggest_budget_categories that serve different purposes.

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

• explain_zero_based_budgetingA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate this is a read-only, non-destructive, idempotent, and closed-world operation. The description adds value by specifying the output format ('structured explanation with practical examples') and the tool's educational nature, which goes beyond the annotations. No contradiction with annotations exists.

  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 front-loaded with the core purpose in the first clause, followed by usage guidelines. Both sentences are essential: the first defines what the tool does, and the second tells when to use it. There is no wasted text or redundancy.

  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?

  Given the tool's educational nature, annotations covering safety and behavior, and 100% schema coverage, the description is largely complete. It specifies the output format and usage context. However, without an output schema, it could benefit from more detail on the structure of the returned explanation (e.g., sections or format), but this is a minor gap.

  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 schema description coverage is 100%, so the schema fully documents the three parameters (detail_level, include_example, currency). The description does not add any parameter-specific information beyond what's in the schema, such as explaining the impact of different detail levels or example types. This meets the baseline for high 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 the tool's purpose: to explain Zero-Based Budgeting (ZBB) with specific components (what it is, how it works step-by-step, why it's effective) and a structured output with examples. It distinguishes itself from sibling tools like 'analyze_budget' or 'create_budget_plan' by focusing on educational explanation rather than analysis or creation.

  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: 'when someone asks about ZBB, how to budget, or how to manage their money better.' This provides clear context for invocation, distinguishing it from siblings that might handle budgeting calculations or planning without explanation.

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

• budget_summaryA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about the output being 'shareable text' suitable for copying and sharing, which isn't covered by annotations, though it doesn't mention rate limits or authentication needs.

  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 front-loaded with the core purpose, followed by output details and usage guidelines in two efficient sentences with no wasted words, making it easy to scan and understand quickly.

  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?

  Given the tool's moderate complexity, rich annotations (covering safety and idempotency), and full schema coverage, the description provides complete context by clarifying the tool's purpose, output format, and usage scenarios, making it sufficient for an agent to use effectively despite no output schema.

  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 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific details beyond what's in the schema, but it implies the parameters are used to generate the summary, maintaining the baseline score of 3.

  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's purpose: 'Generates a shareable text summary of a budget plan' with specific outputs (allocation table, key metrics, Financial Runway estimate) and distinguishes it from siblings like 'analyze_budget' or 'create_budget_plan' by focusing on formatted summarization for sharing.

  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 it: 'Use this when someone wants a clean, formatted budget overview they can save or share' and provides specific use cases (copying into notes, sharing with a partner or financial advisor), clearly differentiating it from analysis or creation tools.

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