Boundr

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

With no annotations, the description fully discloses that the tool returns lightweight metadata without geometry, that multiple boundaries may be returned, and that filtering is possible. It does not mention authentication or rate limits, but the behavioral scope is well-covered for a read-only spatial query.

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

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

The description is efficiently structured into short, focused paragraphs. Every sentence adds value (purpose, usage, filtering, prerequisite). No unnecessary repetition. Slightly longer due to multiple pieces of guidance, but all are relevant.

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

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

Given that an output schema exists, the description does not need to detail return values. It covers purpose, when to use, filtering, and references to sibling tools. It is complete for a tool of moderate complexity with 3 parameters.

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

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

Schema coverage is 100%, so the schema already fully describes the parameters. The description adds some contextual value (e.g., example types like 'CTY', 'LBO') but does not significantly augment the meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states it finds UK administrative boundaries containing a coordinate point. It specifies 'lightweight metadata only — no geometry', distinguishing it from sibling tools like get_boundary_geojson_by_code. The verb 'find' and resource 'boundaries at point' are explicit.

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

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

Provides explicit when-to-use (answer location queries) and when-not-to-use (for geometry, use get_boundary_geojson_by_code). Includes guidance on filtering by boundary_types and a prerequisite call to list_boundary_type_codes if unsure. Alternatives are clearly named.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns min/max lat/lng and centroid, and that it is a cheap operation without geometry serialization. While it doesn't elaborate on error cases or side effects, the lack of destructive behavior is implied. The description adds value beyond the schema by explaining the output format and performance characteristics.

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

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

The description consists of two well-structured sentences. The first sentence states the purpose, and the second provides actionable guidance on using the output. Every phrase adds value with no redundant or unnecessary information.

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

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

For a simple tool with one parameter, comprehensive schema coverage, and an existing output schema, the description is complete. It explains what the tool returns, how to use the result, and how it compares to a related sibling tool. No significant gaps for an agent to misinterpret.

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

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

Schema description coverage is 100% for the single parameter 'code', with a detailed description including an example and case-insensitivity note. The tool description does not add additional semantic information about the parameter beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool gets the bounding box and centroid for a boundary using an ONS census code, specifying the verb 'Get', the resource 'boundary bbox/centroid', and the identifier type. It differentiates from siblings by noting it is cheaper than get_boundary_geojson_by_code and returns bbox values for use in other functions.

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

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

The description explicitly advises when to use this tool: for spatial queries needing bounding box, and directs to pass values to sightings_in_bbox() or geographic_summary(). It contrasts with the alternative get_boundary_geojson_by_code() by noting it is cheaper because no geometry is fetched or serialized, providing clear usage guidance.

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

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

No annotations provided, but description compensates by disclosing that it does not return geometry, describes the output as metadata, and explains code format and case-insensitivity. Could mention read-only nature explicitly.

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

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

Front-loaded with main purpose and constraints. The additional paragraph on ONS codes is helpful but slightly lengthens the description. Still well-structured and efficient.

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

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

For a simple tool with one parameter and an output schema, the description covers purpose, usage context, code format, and alternatives. No gaps identified.

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

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

Schema already describes the code parameter (format, case-insensitivity) with 100% coverage. Description adds value by explaining the meaning of ONS census codes and country prefix, which aids understanding beyond schema.

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

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

Description uses specific verb 'look up metadata' for a single UK boundary by ONS census code, and explicitly states 'No geometry', distinguishing it from sibling tools that return geometry.

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

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

Clearly states when to use (when you already have a census code and need metadata) and explicitly names an alternative (get_boundary_geojson_by_code for shapes), providing complete guidance.

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

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

Warns about large geometry size and context window exhaustion, and states the output format. Without annotations, it provides sufficient behavioral context, though could mention potential error cases.

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

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

Front-loaded main purpose, then adds important warnings and guidance. Slightly verbose but every sentence adds value.

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

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

Covers output format, use cases, alternatives, and performance caveats comprehensively for a simple single-parameter tool with output schema.

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

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

Input schema has 100% coverage and description adds example code, case-insensitivity note, and code types, enriching the schema's minimal description.

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

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

The description clearly states the tool fetches full GeoJSON geometry for a UK boundary by ONS code, and distinguishes it from siblings like get_boundary_by_code and get_boundary_geojson_simplified.

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

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

Explicitly tells when to use (full-fidelity for server-side analysis) and when not (web maps, use simplified version), and directs to sibling tools for obtaining codes.

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

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

No annotations provided, so description carries full burden. Describes simplification effect quantitatively (vertices reduction, no visible difference). States 'safe to embed'. Lacks detail on error handling or permissions, but overall transparent about output characteristics.

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

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

Four sentences, each adds critical information: purpose, safety, performance with concrete numbers, and usage advice. No redundant or filler content. Front-loaded with the core action.

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

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

Given the complexity (2 params, output schema exists, tool is simple retrieval), the description covers all necessary aspects: what it does, when to use it, parameter effects, and behavioral impact. No gaps identified.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the impact of the tolerance parameter (constituency polygon shrinks from ~4k to 200-400 vertices). This provides practical guidance beyond the schema's technical description.

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

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

Clearly states 'Fetch simplified GeoJSON for a boundary by its ONS census code.' The verb 'fetch' and resource 'simplified GeoJSON' are specific. Distinguishes from sibling 'get_boundary_geojson_by_code' by mentioning 'simplified'.

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

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

Explicitly advises to prefer this tool over get_boundary_geojson_by_code() for Leaflet map pages due to context window limits. Provides concrete scenario and alternative. Also notes it's safe for embedding in HTML.

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

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

No annotations are provided, so the description carries full responsibility. It describes the return format (dict mapping code to label), notes that codes are stable Ordnance Survey identifiers, and discloses the error condition (ValueError). This gives a clear behavioral model for a read-only lookup tool.

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

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

The description is concise, front-loaded with the purpose, followed by usage guidance, a list of common codes, and return format. Every sentence is meaningful and adds value without redundancy.

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

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

Given the tool's simplicity (no parameters, no annotations), the description is complete. It covers purpose, usage, error behavior, and return format. The presence of an output schema does not reduce the need for description because the description adds context (stability, common codes) beyond schema.

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

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

The tool has zero parameters and the input schema is 100% covered (empty properties). The description appropriately does not discuss parameters; baseline for 0 params is 4. No additional semantic help needed.

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

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

The description states explicitly that the tool returns every valid UK boundary type code mapped to its human-readable label. It clearly defines the resource (boundary type codes) and action (list), and distinguishes from sibling tools that handle boundary geometries or searches.

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

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

The description instructs the agent to call this tool before using any tool that accepts boundary_type or boundary_types arguments, and warns that passing an unlisted code raises a ValueError. This provides explicit when-to-use and what-not-to-do guidance.

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

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

No annotations are provided, so the description carries full burden. It clearly states that the tool performs a case-insensitive partial match, returns only lightweight metadata (no geometry), and that an invalid boundary_type code raises ValueError. This sufficiently discloses key behavioral traits for a simple search tool.

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

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

The description is three sentences, front-loading the purpose, then usage, then next steps. Every sentence adds value with no wasted words.

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

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

Despite having an output schema (which covers return values), the description mentions 'Returns lightweight metadata only — no geometry', providing necessary context. It also references sibling tools appropriately. For a tool with 2 parameters and clear behavior, this is complete.

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

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

Schema description coverage is 100%, baseline is 3. The description adds value by explaining the case-insensitive partial match semantics for 'name' and provides examples. For 'boundary_type', it explains how to obtain valid codes and warns about ValueError, adding context beyond the schema.

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

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

The description clearly states 'Search for UK administrative boundaries by name (case-insensitive partial match)', specifying the verb, resource, and matching semantics. It distinguishes from siblings by noting it returns lightweight metadata only and points to get_boundary_geojson_by_code for geometry, and references list_boundary_type_codes for filtering.

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

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

The description explicitly states when to use the tool: 'Use this to discover boundaries when you have a place name but not a code.' It also provides guidance on when to use a sibling: 'Call list_boundary_type_codes() first if you need to filter by type.' Additionally, it mentions the alternative for geometry retrieval.

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