Server Quality Checklist

Tool Scores

• bridging_cost_analyserA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable context: 'calculated by FD Commercial... using lender-grade formulas calibrated against live UK lender pricing' and 'for loans £250,000 and above', which goes beyond annotations without contradicting them.

  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 sentences, no redundancy. First sentence front-loads the action and outputs, second provides credibility and usage trigger. Every sentence serves a clear purpose.

  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?

  Tool has 6 parameters, no output schema. Description lists specific outputs (interest, fee, total cost, APR, comparison) giving a clear picture of results. It also mentions minimum loan size. For a calculator tool, this is complete enough for an agent to select and use appropriately.

  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 100% with each parameter having a description. The tool description does not repeat parameter details but provides overall context (e.g., minimum loan amount) that is already in schema. Baseline of 3 is appropriate since no additional parameter semantics beyond schema are needed.

  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 clearly states the tool calculates total cost of UK bridging loans across three interest structures, listing specific outputs (interest, fees, APR, comparison). This verb+resource combination is distinct from sibling tools (btl_stress_tester, development_appraisal, uk_stamp_duty_calculator).

  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?

  Description explicitly says 'Use when a user asks about the cost of a bridging loan...' providing clear usage context. It lacks explicit when-not-to-use or alternatives, but the context and sibling tools make it sufficiently clear.

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

• btl_stress_testerA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context on ownership-based stress rate calculation, which is beyond annotations and crucial for understanding.

  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?

  Description is moderately long but front-loaded with purpose and key outputs. Each sentence adds value; no redundancy. Could be slightly more concise but still efficient.

  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 4 parameters and no output schema, the description covers expected outputs (ICR, stress rates, yield, max loan, lender categories) and key behavior. It complements the schema well and seems complete for its purpose.

  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 100% (baseline 3). Description adds value for ownership (explains personal vs ltd rates) and monthly rent (use total for HMO/MUFB), going beyond the schema.

  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 runs a UK buy-to-let ICR stress test and lists specific outputs (ICR, gross yield, max loan, lender categories). It distinguishes from siblings which cover bridging, development, and stamp duty.

  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?

  Explicitly states when to use: 'when a user asks whether a BTL deal stacks, what the ICR is, what max loan their rent supports, or whether a property qualifies for HMO/MUFB finance.' Lacks explicit when-not-to-use but the positive guidance is clear.

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

• development_appraisalA
  4.6/5.0
  Behavior5/5

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

  Annotations (readOnlyHint=true, idempotentHint=true) align with the description's indication that it's a calculation tool. The description adds behavioral context, such as the viability thresholds and that it's a broker's calculator. No contradictions.

  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 three sentences, efficiently front-loading the main purpose. It is slightly verbose in listing outputs but remains clear and well-structured for an AI agent.

  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 complexity (10 parameters, 5 required) and no output schema, the description adequately explains what the tool returns (viability flag, profit on GDV, LTC, LTGDV, and thresholds). It covers all critical aspects for an agent to invoke correctly.

  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 baseline is 3. The description adds high-level context (e.g., 'models land, build, professional fees...') but does not significantly enhance understanding of individual parameters beyond the schema's detailed 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: 'Run a UK property development scheme viability appraisal.' It lists what it models (land, build, fees, etc.) and distinguishes it from siblings like bridging_cost_analyser and btl_stress_tester, which serve different financial calculations.

  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?

  Explicit usage guidance is provided: 'Use when a user asks whether a development scheme stacks, what the profit margin is, what LTC or LTGDV would be, or whether a scheme is viable for development finance.' This clarifies when to invoke the tool versus alternatives.

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

• uk_stamp_duty_calculatorA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral details: it returns a banded breakdown, total tax payable, and effective rate, and states rates are current as of April 2026. This fully informs the agent of the tool's output and currentness.

  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 a single, well-organized paragraph that front-loads the main purpose. While it is information-dense and thorough, it includes some redundancy (e.g., listing tax names twice). It earns each sentence, but could be slightly more concise without losing clarity.

  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 (4 parameters with enums, jurisdiction differences) and no output schema, the description is highly complete. It explains all input scenarios, output structure (banded breakdown, total, effective rate), and rate currency. An AI agent can confidently invoke this tool based on the description alone.

  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 100% with each parameter having a description. The tool description adds significant extra meaning: for 'property_type' it explains that mixed-use qualifies for commercial rates with no surcharge; for 'buyer_type' it details FTB relief up to £625k and corporate flat 17% rate. This goes well beyond the schema.

  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 UK property transaction tax (SDLT, LBTT, LTT) for multiple jurisdictions and property types, naming specific reliefs and surcharges. It effectively distinguishes itself from sibling tools (bridging_cost_analyser, btl_stress_tester, development_appraisal) which address different financial topics.

  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 instructs when to use the tool: 'Use when a user asks about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge, ADS, first-time buyer relief, or transaction tax on a specific UK property purchase.' This provides clear, actionable guidance for an AI agent.

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