Server Quality Checklist

Tool Scores

• lookup_vehicleA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It describes the returned data but does not mention side effects (it appears read-only), rate limits, error conditions, or authorization requirements. This is insufficient for a tool with no annotations.

  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 a single sentence that starts with the purpose but then lists many fields in a dense, unstructured manner. While complete, it could be more readable with bullets or shorter sentences. The essential information is present but not optimally organized.

  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 simple tool (one parameter, no output schema, no annotations), the description provides a comprehensive list of return fields. However, it lacks details on error cases (e.g., missing or invalid registration), performance expectations, or what happens if data is unavailable. This is adequate but not thorough.

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

  Parameters4/5

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

  Schema description coverage is 100% for the single parameter 'registration'. The description adds format guidance with examples ('e.g., AB12 CDE or AB12CDE'), which helps the agent format input correctly. This extra detail raises the score above baseline.

  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 action: 'Look up enriched data for a UK vehicle by registration mark.' It lists specific fields returned, making the purpose unmistakable. Sibling tools are all postcode-related, so this tool is well-differentiated.

  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 implies usage for UK vehicle lookups by registration mark. It does not explicitly state when not to use it or provide alternatives, but the context of siblings (postcode tools) and the single parameter make usage straightforward. An exclusion for non-UK vehicles is implied but not stated.

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

• lookup_postcodeA
  4/5.0
  Behavior3/5

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

  No annotations provided, so the description carries full burden. It implies a read-only lookup by listing returned data, but does not explicitly state it is non-destructive, mention authentication, rate limits, or other behaviors.

  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 paragraph that front-loads the main purpose, but it lists many data categories, making it slightly verbose. Every sentence adds value, but could be more concise.

  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?

  With no output schema, the description compensates by listing all categories of returned data, providing sufficient context for an agent to understand the output. It also notes the unsupported region, making it complete for its complexity.

  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 a description and example for the only parameter 'postcode'. The description adds no new semantic meaning beyond the schema's explanation.

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

  Purpose5/5

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

  The description states 'Look up enriched data for a UK postcode' and lists specific data categories (geographic, risk, property, broadband, deprivation, MP details), clearly distinguishing it from siblings like 'nearest_postcode' and 'postcodes_within'.

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

  Usage Guidelines4/5

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

  The description explicitly states it is for UK postcodes and notes that Northern Ireland (BT prefix) postcodes are not supported, providing a clear when-not-to-use condition. It does not name alternative tools but the sibling names imply different purposes.

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

• nearest_postcodeA
  4/5.0
  Behavior3/5

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

  No annotations exist, so description must cover behavior. It mentions returning 'full enrichment data' and 'risk and demographic signals', which is good. However, it doesn't explain what happens if no postcode is found, radius effects, or coordinate validity. Adequate but has gaps.

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

  Conciseness5/5

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

  Two short sentences, front-loaded with action and purpose. Every word earns its place; no 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?

  Despite no output schema or annotations, the description explains what it does, when to use it, and what it returns (enrichment data). Could mention radius or error states, but overall sufficient for a simple geospatial tool.

  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% (all parameters have descriptions in the schema). The tool description adds no further parameter guidance beyond reinforcing 'latitude/longitude coordinate'. Baseline 3 is appropriate.

  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 finds the nearest UK postcode to given coordinates and returns enrichment data. It distinguishes from siblings: lookup_postcode retrieves by code, postcodes_within returns multiple, while this tool finds the single nearest from a coordinate.

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

  Usage Guidelines4/5

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

  The description provides a clear use case ('when you have coordinates and need the corresponding postcode'). It implies when to use but does not explicitly mention when not to or compare with postcodes_within.

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

• postcodes_withinA
  4.3/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full burden. It discloses ordering (distance ascending), cost (one quota per postcode), requirements (Starter plan), and max radius (5000m). Missing details on error handling or rate limits, but the disclosed info is substantial.

  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 concise, consisting of four sentences that front-load the purpose, then add ordering, cost/requirements, and a size constraint. Every sentence serves a purpose with no redundancy.

  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?

  While the description covers key behaviors, it lacks details about the return format (what 'full enrichment data' contains) and does not mention pagination or limits on the number of postcodes returned. This is a gap for a tool that could return many results.

  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%, but the description adds value by explaining the radius unit, default, and max, and clarifying that results are ordered by distance. It reinforces the coordinate reference (WGS84) and adds behavioral context not in 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 returns all UK postcodes within a radius of a lat/lon coordinate with full enrichment data. It distinguishes from sibling tools like 'nearest_postcode' which likely returns a single nearest postcode, and 'lookup_postcode' for a specific postcode.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool (to get all postcodes within a radius) and includes constraints (Starter plan required, quota cost, max radius). However, it does not explicitly contrast with alternatives or state when not to use it.

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