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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the output modes ('json' default or 'text'), what is returned (all available tools, sources, spatial references, LLM guidance), and the practical implication of being a startup call. For a low-risk read-only tool, this is sufficient transparency without being verbose.

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 well-structured with clear sections (intro, Args, Returns, Tips) and is appropriately sized for a capabilities tool. It is slightly repetitive (e.g., 'complete information' and 'Complete capability listing' both appear), but overall every sentence contributes useful 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?

There is no output schema, so the description appropriately explains the return value ('Complete capability listing with LLM guidance') and provides usage context. For a simple one-parameter meta-tool, this is adequate; it could be slightly more detailed about the structure of the 'text' output, but overall it 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?

The input schema only lists output_mode with a type and default, with 0% schema description coverage. The description fully compensates by stating 'Response format — "json" (default) or "text"', adding the accepted values that the schema does not enumerate. This is strong parameter-level guidance.

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 opens with 'List full server capabilities: sources, tools, and supported queries,' which is a specific verb+resource statement. It clearly distinguishes this meta-tool from the data-query siblings (e.g., her_search_monuments, her_get_monument) by explaining it provides an overview of the server rather than domain-specific lookups.

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 'Tips for LLMs' section explicitly instructs 'Call this once at the start of a session to understand what tools are available and how to use them effectively,' providing clear situational guidance. However, it does not mention when not to use it or explicitly name alternative tools, so it stops short of a 5.

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?

With no annotations, the description carries the full burden and does well: it states the operation is 'fast,' emphasizes 'no geometry returned,' and discloses that output can be 'json' or 'text.' It stops short of detailing error behavior, authorization, or limits, so it is not a perfect 5, but it covers the key behavioral traits an agent needs.

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 well-organized with summary, Returns, Args, and Tips sections, making it scannable. Minor redundancy exists—'Count aerial mapping features' and 'Returns a quick count' say similar things, and 'use before her_search_aerial' appears twice—but each section earns its place overall.

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 count tool with no output schema, the description covers purpose, parameters, return value, and a usage tip, which is largely complete. It lacks edge-case details like behavior with no filters or error responses, but this is a minor gap given the tool's simplicity and the rich parameter documentation.

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?

Though schema coverage is 0%, the description's Args section explains every parameter: bbox format ('xmin,ymin,xmax,ymax' in EPSG:27700), monument_type and period examples, and output_mode choices with default. This fully compensates for the bare schema and adds meaning beyond the parameter names.

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 opens with a specific verb and resource: 'Count aerial mapping features in an area (fast, no geometry returned).' It clearly distinguishes the tool from siblings like her_search_aerial and her_count_features by scoping it to aerial features and clarifying that it returns no 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?

The description explicitly instructs to 'Use before her_search_aerial to gauge result size' and repeats this in the 'Tips for LLMs' section. This gives the agent a clear when-to-use directive and names the alternative tool for fetching full records, satisfying the highest bar for 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?

With no annotations, the description carries the full burden. It discloses that the operation is fast, returns only a count, and supports output modes. It does not explicitly state side effects or auth requirements, but the read-only nature is implied and the behavioral traits are adequately described.

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 well-organized with sections for arguments, returns, and tips. Every sentence adds value, and it is appropriately sized for the tool's simplicity.

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 count tool with no output schema, the description fully explains returns and usage context. It even provides an example of how to use the result. The sibling tool relationship is clearly established, making the description 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 0%, so the description must compensate. It explains each parameter: bbox format with example, query as name filter, lpa as authority filter, and output_mode values. This fully covers the semantics 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 the tool counts conservation areas in an area, noting it is fast and returns no geometry. It explicitly distinguishes itself from the sibling search tool, making its purpose unambiguous.

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 instructs to call this tool before her_search_conservation_areas to gauge result size, and provides a 'Tips for LLMs' section reinforcing the workflow. This is clear when-to-use guidance with a named alternative.

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?

With no annotations, the description carries the full burden. It discloses speed ('fast'), that it avoids fetching full records, and that it returns counts grouped by designation type. It also notes the output can be json or text. While it doesn't cover error conditions, rate limits, or exact data structure, the provided behavioral traits are useful and non-contradictory.

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 well-structured and front-loaded with the purpose in the first sentence. It uses brief sections for Args, Returns, and Tips for LLMs, with every sentence adding value and no 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 is a simple count operation with three optional parameters and no output schema, the description is complete. It covers purpose, parameter formats, return value summary, and practical tips for LLM usage (speed, use case, breakdown). No additional context is necessary for correct invocation.

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 0%, so the description fully compensates by explicitly explaining each parameter in the Args section: designation_type (filter, None for all), bbox (format 'xmin,ymin,xmax,ymax' in BNG), and output_mode (json default, text alternative). This adds meaning well beyond the bare 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 states a specific action: 'Fast count of heritage features in an area.' It clearly defines the resource (heritage features) and scope (area), and distinguishes itself by mentioning it returns counts by designation type without fetching full records, contrasting with sibling search tools.

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?

Explicit usage guidance is provided: 'Use this before her_search_designations to estimate result sizes' and 'Use this to decide whether to narrow your search area.' It also mentions being 'much faster than a full search when you just need totals,' giving clear when-to-use versus alternatives.

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 the full burden. It discloses that the operation is 'fast' and returns 'no geometry', indicating a lightweight read. It also specifies the return type (count) and output_mode options. However, it does not mention error handling or behavior when no filters are applied, which prevents a perfect score.

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 and well-structured with a headline, Args section, Returns line, and a Tips for LLMs section. Every sentence adds value, and the tip reinforces usage without redundancy. It is front-loaded with the core purpose and scannable.

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 lack of schema descriptions and output schema, this description is remarkably complete: it covers all parameters, the return value, and usage context. The only minor gap is that it doesn't specify behavior when no filters are provided (e.g., counts all entries), but overall it provides sufficient information for an agent to invoke the tool correctly.

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 0%, so the description fully compensates. It explains bbox format explicitly as 'xmin,ymin,xmax,ymax' in BNG (EPSG:27700), provides an example for heritage_category ('Listed Building'), and notes output_mode default ('json') and alternatives ('text'). This adds crucial meaning beyond the bare 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 opens with 'Count heritage at risk entries in an area (fast, no geometry returned)', which is a specific verb+resource+modifier. It clearly distinguishes from the sibling tool her_search_heritage_at_risk by noting it returns a count without geometry, making the purpose unambiguous.

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 states 'Use before her_search_heritage_at_risk to gauge result size' and repeats in Tips: 'Call this before her_search_heritage_at_risk to check how many entries match before fetching full records.' This names the specific alternative and gives clear when-to-use 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?

Despite having no annotations, the description discloses the core algorithm: it classifies each candidate based on proximity thresholds (match_radius_m, near_radius_m), explains the meaning of match/near/novel, and notes optional inclusion of AIM and Gateway data. It doesn't mention error handling or side effects, but the tool's read-only nature is implied.

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 structured with Args, Returns, and Tips sections. All information is relevant; the tips provide actionable workflow guidance without redundancy. It's longer than some but efficient for a 7-parameter tool.

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?

With no output schema and 7 parameters, the description covers all inputs, defines the output classification, and provides integration context with sibling tools. It gives enough to invoke the tool correctly without further research.

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 0%, but the description thoroughly documents all 7 parameters with types, defaults, and examples (e.g., candidates as JSON array with easting/northing, designation_types as comma-separated values). This fully compensates for the schema gap.

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 uses a specific verb 'Cross-reference' with a clear object 'candidate locations against known heritage assets', and defines the output classification (match/near/novel), distinguishing it from sibling search tools by its proximity-classification behavior.

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 'Tips for LLMs' section explicitly instructs when to use complementary tools: 'Use her_enrich_gateway first', 'Use her_export_for_lidar to get known sites in the same area', and recommends include_aim for LiDAR workflows. This provides clear workflow context and alternatives.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context like color categories and linkage to her_cross_reference, but does not disclose map format or potential response structure, which would enrich transparency.

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?

Two sentences deliver the core purpose, color legend, and relationship to a sibling tool with no fluff. The information is front-loaded and easy to parse.

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 6 parameters and no output schema, the description does not explain parameters or return value. It provides a helpful pointer to her_cross_reference but leaves significant gaps for an agent to invoke the tool correctly.

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 6 parameters with 0% description coverage, and the description provides no explanation of what basemap, candidates, radii, etc. mean. The only hint is 'runs the same analysis as her_cross_reference', which is insufficient for correct parameter usage.

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 'Visualise' with resource 'cross-reference results' and specifies color-coded map categories. It clearly distinguishes from sibling her_cross_reference by noting it runs the same analysis but in map form.

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 implies use for visualising cross-reference results rather than raw analysis, and explicitly names her_cross_reference as the alternative. However, it does not state explicit when-to-use/when-not-to-use conditions, leaving some inference needed.

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?

With no annotations provided, the description carries the full burden and does so excellently. It discloses that the tool is slow (1-2 minutes for 100 records), only returns records with valid easting/northing, and explains the mechanism (parsing grid references and/or fetching detail pages). It also mentions default behavior for fetch_details and output_mode.

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 well-structured with a summary paragraph, args list, returns line, and a Tips section. Every sentence provides valuable information—performance guidance, workflow integration, and complementary tools—with no filler. The bullet-point formatting enhances scannability.

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 tool with 6 parameters and no output schema, the description thoroughly covers the purpose, parameters, return value (Gateway records with resolved coordinates), performance behavior, and workflow context. The Tips section addresses practical usage patterns, making it complete for an agent to use the tool effectively.

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 0%, but the description compensates fully by explaining each parameter with examples (what, where, when) and defaults (max_results, fetch_details, output_mode). This goes beyond the schema, providing all necessary semantic detail for an agent to construct correct inputs.

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 fetches Heritage Gateway records with resolved coordinates, distinguishing it from a plain search tool. It also explains the enrichment purpose (resolving BNG coordinates) and mentions its suitability for her_cross_reference, making the tool's purpose unambiguous.

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 Tips for LLMs section provides explicit workflow guidance: use before her_cross_reference, pass output as gateway_sites, and run complementary tools (her_search_monuments, her_search_aerial) in parallel. It also clarifies scope by noting Gateway records are local HER data not in NHLE or AIM, effectively indicating when this tool is appropriate.

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 output behavior: 'Output includes easting/northing in BNG for spatial matching' and 'Each site has id, source, name, type, monument_type, period.' It also explains parameter behavior like include_aim 'when available' and include_nhle 'default true.' It does not explicitly state side effects or whether the operation is read-only, but for an export tool this is largely implied.

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 well-structured with sections for Args, Returns, and Tips, and it front-loads the core purpose. It is slightly longer than necessary due to redundancy (e.g., bbox required mentioned in both Args and Tips), but each section provides useful information and the prose is 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?

Given the lack of output schema, the description compensates by explaining return format ('Known sites in LiDAR cross-reference format') and key fields. It also covers the prerequisite workflow with her_enrich_gateway. It does not mention potential errors or limitations, but for a moderately complex export tool, the provided details are largely sufficient.

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 0%, so the description must compensate. It does so thoroughly by explaining all 5 parameters: bbox format ('xmin,ymin,xmax,ymax' in BNG), gateway_sites as 'JSON array of Gateway records with easting/northing (output of her_enrich_gateway)', and output_mode as 'json' or 'text'. It also clarifies defaults and requiredness, adding significant value 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 the tool's purpose: 'Export heritage assets for LiDAR cross-referencing' and 'Produces a list of known monument centroids with metadata in the format expected by chuk-mcp-lidar spatial matching.' This distinguishes it from siblings like her_export_geojson by specifying the LiDAR-specific output format.

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 clear context and workflow: 'Use her_enrich_gateway first, then pass output as gateway_sites' and 'bbox is required for LiDAR export.' It implies when to use (LiDAR cross-referencing) but does not explicitly state when not to use or name alternatives, so it falls short of a 5.

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?

With no annotations provided, the description carries the transparency burden. It discloses meaningful behavioral details: bbox is expected in BNG, output coordinates are WGS84, max_results has a ceiling of 2000, and output_mode supports json or text. It does not mention errors or rate limits, but the disclosed behavior 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.

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

The description is well-organized with Args, Returns, and Tips sections, and the opening sentence is front-loaded. There is minor redundancy between the first sentence and the second paragraph, but each section earns its place.

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?

With no output schema and no annotations, the description covers parameter meanings, return type (GeoJSON FeatureCollection), coordinate system, and practical tips. It lacks possible values for designation_type and the exact meaning of text output mode, but for a straightforward export tool it is sufficiently 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 0%, but the description documents all five parameters with concrete detail: bbox format ('xmin,ymin,xmax,ymax' in BNG), name partial match, max_results default and maximum, and output_mode default. This fully compensates for the empty 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 first sentence is specific: 'Export heritage assets as GeoJSON FeatureCollection.' This clearly states the verb, resource, and output format, distinguishing it from the search/get/count siblings and even from her_export_for_lidar by naming GeoJSON.

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 provides clear usage context by mentioning suitability for QGIS, Leaflet, or other GIS tools, and includes LLM tips such as using bbox to limit the export area. It does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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?

With no annotations, the description carries the burden; it discloses accepted ID formats (aim:HE_UID or HE_UID), output modes (json/text), and the return content (monument type, period, evidence, location). It does not mention error cases or whether the operation is read-only, but the verb 'Get' strongly implies no side effects.

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 well-structured with clear sections (description, args, returns, tips) and is concise—no redundant content. Every sentence adds value, and the LLM tip is directly actionable.

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 get-by-ID tool with two parameters and no output schema, the description covers the operation, parameter behavior, return value, and integration with search. It is complete enough for an agent to invoke correctly without additional information.

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 schema has no descriptions (0% coverage), but the description fully documents both parameters: record_id with examples, and output_mode with default and allowed values. This adds complete semantics 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 uses specific verbs 'Get' and 'Retrieves' and clearly states the resource: a single aerial mapping feature identified by HE_UID. It distinguishes from siblings by referencing her_search_aerial as the source of record_id, implying this is the follow-up retrieval tool.

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?

It provides explicit context: use record_id from her_search_aerial results, which tells the agent when to call this tool. It does not explicitly exclude other tools, but the name and reference to search results establish the correct workflow. It also documents output_mode options, giving the agent choice.

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?

With no annotations, the description carries the burden of disclosing behavior. It states the tool 'Retrieves a single conservation area' (read-only) and explains the two accepted input formats for record_id. It also specifies the output_mode behavior. While it doesn't discuss auth or errors, the provided information goes beyond a minimal description.

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 well-structured with clear sections: summary, args, returns, and a tip. Every sentence adds value, and the key purpose is front-loaded in the first line. It is concise without being sparse, earning a perfect score.

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 get tool with two parameters and no output schema, the description covers all essential aspects: what it does, how to specify the ID, response format, return contents, and a practical tip. It is sufficiently complete for an agent to select and invoke the tool correctly.

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 0%, so the description must compensate. It does so thoroughly: record_id is explained with examples ('ca:1234' or '1234'), and output_mode is documented with its default ('json') and alternative ('text'). This adds significant meaning beyond the raw 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 opens with 'Get full details of a specific conservation area,' which is a specific verb+resource combination. It clearly distinguishes from sibling getters by specifying conservation_area and aligns with the naming convention of other get tools.

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 provides a usage tip: 'Use record_id from her_search_conservation_areas results.' This implies the tool should be used after a search and not for listing. However, it lacks explicit exclusions or comparison with sibling getters (e.g., her_get_monument), so it falls short of a 5.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the accepted input formats ('har:LIST_ENTRY' or just the number), output mode options ('json' or 'text'), and return contents (category, risk methodology). It does not mention error handling or side effects, but for a read-only retrieval tool this is adequate, earning a 4.

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 well-structured and appropriately sized, with clear sections (Args, Returns, Tips). It is front-loaded with a one-line summary, and every sentence adds value with no fluff or repetition.

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 no output schema, the description covers the essential aspects: how to pass arguments, what output to expect, and how to obtain the correct ID. The 'Tips for LLMs' section provides practical guidance linking this tool to its sibling, making it complete for a simple get-by-ID operation.

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 schema has no descriptions and 0% coverage, so the description must compensate. It fully explains both parameters: record_id with concrete examples and output_mode with default and possible values. This adds significant meaning beyond the bare schema, justifying a 5.

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's function: 'Get full details of a specific heritage at risk entry' and 'Retrieves a single at-risk entry by its List Entry number.' It uses a specific verb ('Get'/'Retrieves'), names the resource ('heritage at risk entry'), and distinguishes itself from sibling search tools like her_search_heritage_at_risk by emphasizing singular retrieval.

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 provides context on when to use this tool by instructing 'Use record_id from her_search_heritage_at_risk results,' which implies a follow-up after search. However, it does not explicitly state exclusions or when NOT to use this tool versus alternatives, so it falls short of a 5.

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?

With no annotations, the description carries the full burden. It discloses that the tool returns a complete record including name, designation, location, listing dates, and a URL, and explains the output_mode parameter. It does not mention error cases or rate limits, but for a simple read-only get operation this is sufficient.

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 well-structured with sections for args, returns, and tips. It is mostly concise, though 'Returns: Full monument record' repeats the opening sentence and the URL tip is mentioned twice. Minor redundancy prevents a perfect score.

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 2-parameter tool with no annotations or output schema, the description covers purpose, parameters, return value, and usage tips. It is complete enough for an agent to select and invoke the tool correctly.

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 description adds substantial meaning to both parameters. nhle_id is given a concrete example ('1002345'), and output_mode is clarified with allowed values ('json' default or 'text'). This goes well beyond the bare schema, which has zero description coverage.

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 verb ('Get') and resource ('full details for a specific scheduled monument'), distinguishing it from sibling get_* tools that target different heritage asset types (aerial features, heritage at risk, conservation areas, Scotland records).

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 provides clear usage context by specifying the tool handles scheduled monuments and advises using the nhle_id from search results. It does not explicitly exclude alternatives, but the scope is clear enough.

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 the full burden. It discloses that this is a retrieval operation and details the return fields ('site type, form, location, grid reference'). It also explains the output_mode options. It doesn't cover error handling or permissions, but for a read-only get operation this is reasonably transparent.

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 opens with a concise one-sentence summary, then uses clearly labeled Args, Returns, and Tips for LLMs sections. Every sentence adds value, and the structure makes it easy to scan. It is appropriately sized 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?

The tool has only 2 optional parameters and no output schema or annotations. The description covers the meaning and format of both parameters, the content of the return value, and provides a practical tip on sourcing record_id from her_search_scotland. This is complete for an agent to select and invoke the tool correctly.

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 0% and the schema only lists types and defaults. The description compensates thoroughly: it explains that record_id accepts 'scotland:CANMOREID' or just the ID, and that output_mode can be 'json' (default) or 'text'. Both parameters are fully documented 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 first sentence 'Get full details of a Scottish NRHE record by Canmore ID' uses a specific verb ('Get'), names the resource ('Scottish NRHE record'), and references the Canmore ID. This clearly identifies the tool's purpose and distinguishes it from sibling get_ tools like her_get_monument or her_get_aerial_feature by scope.

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 provides a clear workflow context by advising 'Use record_id from her_search_scotland results.' It also explains accepted input formats. However, it does not explicitly state when not to use this tool or mention alternatives, so it lacks exclusions.

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?

With no annotations provided, the description carries the full burden. It discloses the read-only nature by using 'List' and 'Returns metadata,' and details the output including content (query types, coverage, status) and format options (json/text). While it doesn't mention error conditions or pagination, for a simple listing tool this is adequate transparency.

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 well-structured with a clear one-sentence purpose, followed by a concise return description, then formatted Args/Returns sections, and a final tip. Every section adds value without redundancy. It's appropriately sized for a simple tool.

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 no output schema and no annotations, the description covers all essential aspects: what the tool does, what it returns, the parameter, and when to use it. The return format is described with examples of included metadata (query types, coverage, status), which is sufficient for an agent to understand the tool's behavior.

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 input schema only provides a type string with a default, but the description explains the semantic meaning: 'Response format — "json" (default) or "text"'. It clarifies the allowed values and default, fully compensating for the 0% schema description coverage. Additionally, there are no other parameters to explain.

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 starts with a clear verb+resource statement: 'List all registered heritage data sources and their capabilities.' This immediately distinguishes it from sibling tools like her_search_monuments or her_status, which focus on querying specific data. It also explains the return metadata, making the purpose unambiguous.

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 'Tips for LLMs' section explicitly recommends using this tool 'before running queries' to discover available sources and their capabilities. This provides clear usage context. However, it doesn't mention any exclusions or when not to use it, which would merit a 5.

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?

The readOnlyHint annotation already covers safety. The description adds useful context about the return format ('structured map view with colour-coded layers'), but does not disclose potential pitfalls such as how results are aggregated, what happens with excessive results, or any pagination/limits beyond the schema defaults. It provides moderate additional value beyond the annotation.

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 only two sentences, front-loaded with the primary verb and resource. It wastes no words and efficiently conveys both purpose and output structure. Every sentence contributes valuable 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?

With 8 parameters and no output schema, the description is too sparse. It fails to mention that the tool requires some form of location specification (lat/lon or bbox) and radius, which are central to a map tool. An agent has no idea how to use the tool correctly without further parameter documentation.

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 0%, so the description must compensate. It makes sparse connections to parameters by mentioning 'sources' and 'designation type', but says nothing about lat/lon, bbox, radius_m, max_results, or basemap. The description does not meaningfully clarify the meaning of most input fields beyond their schema types and defaults.

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 uses a specific verb 'Visualise' with a clear resource ('heritage assets from multiple sources') and distinguishes its output ('multi-layer interactive map', 'colour-coded layers by designation type and source') from sibling search/export tools. This makes the tool's unique purpose immediately obvious.

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 clearly implies when to use this tool (for spatial visualization of multiple heritage sources) but does not explicitly mention alternatives or say when not to use it. There is no naming of sibling tools or exclusions, so usage guidance is only implied.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It reveals key constraints (NHLE-only, coordinate system exclusivity), output ordering (sorted by distance), and result fields (distance_m, bearing_deg), which go beyond the basic search semantics.

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 well-structured with clear sections (NOTE, Args, Returns, Tips) and front-loads the primary purpose. Despite its length, every sentence adds value, and the 'Tips for LLMs' section is practical without being redundant.

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?

The tool has no annotations or output schema, so the description must provide complete context. It covers purpose, scope, parameters, output structure, and usage caveats, including recommendations for complementary tools – making it adequately complete for effective tool selection and invocation.

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 schema provides only type and default for each parameter, so the description's Args section is essential. It explains coordinate systems (WGS84, BNG), pairing requirements (lat with lon, easting with northing), and output_mode options, fully compensating for the 0% schema coverage.

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 opens with a concrete verb phrase 'Find NHLE heritage assets near a single point' and then elaborates on scope (England only) and output (sorted by distance). It clearly distinguishes itself from sibling tools by explicitly noting the NHLE-only scope and directing to Scottish and aerial alternatives.

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?

It directly states when to use this tool and when not, with a dedicated NOTE listing alternative tools for Scotland and aerial features. The Tips section even recommends combining this with other searches for comprehensive results, giving clear context.

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 present, so the description carries the full transparency burden. It discloses the data source, feature scope, the exclusion of NHLE entries, and the available output modes. It does not detail potential pagination behavior, rate limits, or explicit read-only guarantees, but the search context plus parameter descriptions provide solid transparency.

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?

Though long, the description is organized into Args, Returns, and Tips for LLMs, and each section adds value. The first sentence is a clear summary, and the Tips section provides vocabulary, workflow, and sibling-tool coordination 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?

With 9 parameters, no output schema, and no annotations, this description is unusually complete. It explains every parameter, describes return content, provides query vocabulary, and outlines a multi-tool workflow for comprehensive surveys. It lacks deep error semantics but is sufficient for correct tool selection and invocation.

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 input schema provides no descriptions (0% coverage), so the description's Args section is essential. It compensates fully by giving formats ('xmin,ymin,xmax,ymax' in EPSG:27700), dependencies (radius_m requires lat/lon), defaults (max_results default 50, output_mode default 'json'), and value ranges (1-2000).

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 uses a clear verb ('Search') and names a specific resource ('Historic England AIM data' for aerial investigation mapping). It lists concrete feature types (cropmarks, earthworks, enclosures, ring ditches, saltern mounds) and explicitly distinguishes itself from sibling tools by noting these features are NOT in the NHLE.

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 provides explicit usage guidance: use uppercase AIM vocabulary, recognized monument types and periods, and run all three HER sources together for comprehensive surveys. It names alternatives (her_search_monuments, her_search_heritage_gateway) and recommends her_map for visualizing combined results.

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, but the description uses 'Search' and 'Queries' to clearly convey read-only behavior. It adds useful context about the dataset source and return fields, and notes that radius_m requires lat/lon. This is sufficient for a search tool, though it does not explicitly state 'read-only' or mention rate limits.

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 well-structured with intro, Args, Returns, and Tips sections. Each parameter is given a single concise line, and the tips are actionable. No redundant or unnecessary content is present.

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 9-parameter search tool with no output schema, the description covers all parameters, return fields, and usage tips, including a pointer to the counting tool. It is comprehensive enough for an agent to select and invoke the tool correctly.

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 input schema has 0% description coverage, so the description carries the full burden. It explains every parameter with formats (e.g., bbox as 'xmin,ymin,xmax,ymax' in BNG), defaults (max_results 1-2000 default 50), and dependencies (radius_m requires lat/lon), adding substantial value beyond the bare 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 conservation areas across England' and identifies the specific dataset (Historic England's Conservation Areas) and subject (areas of special architectural or historic interest). This distinguishes it from sibling search tools like her_search_monuments or her_search_listed_buildings.

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 provides a 'Tips for LLMs' section recommending the use of lpa, bbox, or lat/lon filters, and explicitly suggests using her_count_conservation_areas first to gauge result size. This is clear practical guidance, though it does not explicitly discuss when not to use this tool versus fetching a single conservation area.

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 the full burden. It discloses search behavior, parameter formats (BNG vs WGS84), and that results include designation_type. However, it omits details like rate limits, error conditions, or how bbox and radius modes interact.

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 well-structured with a clear intro, parameter list, return info, and LLM-specific tips. Each section serves a purpose; the formatting makes it easy to scan despite its length.

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?

The description covers all parameters and offers practical usage tips, which is strong for a 10-parameter tool with no output schema. However, it lacks a description of the response structure beyond the designation_type field; a sample or field list would increase completeness.

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?

All 10 parameters are described with types, formats, defaults, and allowed values (e.g., bbox format in BNG, designation_type options). The schema has 0% description coverage, so this detailed documentation is essential and fully compensates.

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 opens with a specific verb and resource ('Search across all designation types in the NHLE') and enumerates the covered types, clearly distinguishing it from specialized sibling searches like her_search_listed_buildings and her_search_monuments.

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 'Tips for LLMs' section gives explicit guidance on using this tool for all types, suggests her_count_features for quick totals, and notes that results include designation_type. It implies this is the cross-type search alternative but does not explicitly state when to prefer a sibling tool.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool queries a register, what parameters do, and what it returns ('Matching heritage at risk entries with category, risk methodology'). It implies a read-only search operation but does not explicitly state side effects, rate limits, or authentication needs. Still, for a search tool, it provides above-baseline transparency.

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 well-structured with clear sections (Args, Returns, Tips for LLMs). It is detailed yet every sentence adds value. The front-loaded purpose statement immediately tells the agent what the tool does, and the structured parameter list is easy to scan.

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 complexity (9 parameters, no output schema, no annotations), the description is largely complete: it covers all parameters, provides spatial query guidance, and notes overlap with NHLE. However, the return description is minimal ('Matching heritage at risk entries with category, risk methodology'), and without an output schema, more detail about the response structure would improve completeness.

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 input schema has 0% description coverage, so the description must fully compensate. It does: each parameter is explained with examples, constraints (e.g., 'radius_m requires lat/lon', max_results range 1-2000), and enumerated values for heritage_category. This far exceeds what the bare schema provides.

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 opens with a specific verb and resource: 'Search the Heritage at Risk Register for endangered heritage assets.' This clearly distinguishes it from sibling tools like her_get_heritage_at_risk (single record retrieval) and her_count_heritage_at_risk (counting). The resource is unambiguous.

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 provides clear context: it queries Historic England's annual register of assets at risk. It also offers usage tips ('Use heritage_category to filter by asset type', 'Combine with bbox or lat/lon for spatial queries'). However, it does not explicitly state when to use this tool instead of other search tools, nor does it mention exclusions or alternatives beyond a note about NHLE overlap.

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 the description carries the full burden. It discloses best-effort web scraping, graceful empty results, and temporary unavailability, adding meaningful behavioral context beyond a simple search description. Could mention response format details but is otherwise strong.

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?

Structured with intro, Args, Returns, and Tips sections. It is slightly repetitive ('may be empty' appears twice) but remains focused and scannable for an LLM.

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 tool with no output schema and no annotations, the description covers purpose, usage, params, behavior, and cross-tool guidance. It could detail the return record structure but is otherwise 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 has 0% parameter descriptions, but the description's Args section defines all five parameters with types and examples, fully compensating for the schema gap.

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 opens with a specific verb+resource ('Search local Historic Environment Records via Heritage Gateway') and elaborates that it covers undesignated sites across 60+ local HERs, distinguishing it from sibling NHLE/AIM search tools.

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 states when to use it ('best source for undesignated sites and local HER data') and instructs to ALSO run her_search_monuments and her_search_aerial for comprehensive coverage. Also suggests her_enrich_gateway for spatial filtering.

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?

With no annotations, the description carries the transparency burden. It discloses the external data source (NHLE), partial-match case-insensitive name matching, coordinate systems (BNG, WGS84), radius units, max result limits, and response formats. It doesn't cover empty-result behavior or pagination details beyond the offset parameter, but the provided behavioral context 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.

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

The description is well-structured into purpose, args, returns, and tips for LLMs, with no filler. The Tips section adds relevant domain knowledge (grade hierarchy, area-limiting advice) rather than repetition. Each sentence contributes practical 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?

Given the tool's complexity (9 parameters, no output schema, no annotations), the description covers the full contract: what is searched, all parameter semantics, and the return value ('Matching listed buildings with grade and location'). It is complete enough for an agent to invoke correctly and interpret basic results.

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 input schema has 0% description coverage, but the description fully documents all 9 parameters, including formats ('bbox as xmin,ymin,xmax,ymax in BNG'), units ('radius_m in metres'), ranges and defaults ('max_results: Maximum results (1-2000, default 50)'), and allowed values ('grade: Listing grade filter: "I", "II*", or "II"'). This richly compensates for the schema's lack of explanations.

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 opens with 'Search listed buildings by location, name, or grade' and clarifies 'Queries the NHLE for listed buildings,' naming a specific resource and search dimensions. This clearly distinguishes it from sibling search tools like her_search_monuments and her_search_conservation_areas.

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?

It provides clear contextual guidance: the tool is for searching listed buildings with optional name, grade, and location filters, and the Tips section advises using bbox or lat/lon to limit by area. It does not explicitly name alternatives or state when not to use the tool, preventing a 5.

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?

With no annotations, the description carries full burden. It discloses that NHLE only contains designated assets and advises additional searches for undesignated sites. It also mentions pagination (offset), result limits, and output modes, though it stops short of describing rate limits or exact response shape.

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 organized into an opening summary, Args list, Returns line, and a 'Tips for LLMs' section. Each section adds distinct value, and the text is front-loaded with the primary purpose before moving to parameters and guidance.

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 no output schema or annotations, the description covers the core query capabilities, parameter semantics, default behaviors, and important coverage limitations. It also points to follow-up tool usage, making it self-sufficient for an agent to select and invoke this tool.

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?

Even though the JSON schema's property descriptions are absent, the description's Args section gives every parameter meaning: bbox format with example, radius_m requires lat/lon, max_results bounds (1-2000, default 50), offset for pagination, and output_mode choices. This fully compensates for the 0% schema coverage.

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 opens with a specific verb and resource: 'Search scheduled monuments by location, name, or description.' It also names the exact data source (NHLE) and distinguishes from sibling search tools by focusing on scheduled monuments.

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 guidance: bbox for area searches, lat/lon+radius for point searches, name for text searches. It also names alternatives and complements, including her_get_monument for follow-up and her_search_heritage_gateway/her_search_aerial for undesignated coverage.

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 the full burden. It discloses key behavioral details: the dataset size (320,000+ records), the MapServer limit (1,000 records per request), return format options (json/text), and the requirement that radius_m needs lat/lon. This is strong transparency for a search tool, though it doesn't explicitly state how errors or empty results are handled, which prevents a 5.

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 appropriately structured with a front-loaded summary, an Args block, a Returns line, and Tips for LLMs. While it is longer than usual, every section provides necessary information for a tool with 10 parameters and no annotations. No redundant sentences are present, though the tips section could be seen as slightly verbose; however, it contains only actionable advice.

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 complexity (10 optional parameters, no output schema) and the absence of annotations, the description is remarkably complete. It covers what the tool does, what data it searches, parameter semantics, result format, limitations, and alternatives. The only minor omission is a detailed breakdown of the return record structure, but the Returns line gives sufficient context for a search tool.

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?

With 0% schema coverage, the description must fully explain parameters, and it does. The Args section details each of the 10 parameters, including format ('bbox as "xmin,ymin,xmax,ymax" in BNG (EPSG:27700)'), constraints ('radius_m requires lat/lon'), defaults ('max_results default 50'), and available options ('output_mode: json or text'). This goes beyond minimal descriptions and directly compensates for the incomplete 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 the tool's purpose: 'Search Scottish NRHE records' and specifies the resource (Canmore, 320,000+ sites). It distinguishes from siblings by noting this covers ALL known Scottish heritage sites versus her_search_scotland_designations for designated assets only, and her_search_monuments for English sites. The verb 'search' plus the resource and scope makes the tool's function unambiguous.

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 'Tips for LLMs' section provides explicit guidance on when to use this tool versus alternatives: 'For designated assets only, use her_search_scotland_designations' and 'For cross-border queries near England/Scotland border, also run her_search_monuments (NHLE) and her_search_aerial (AIM) for English sites'. It also includes practical usage tips like recommended site_type keywords and the maximum result limit.

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 fully bears the transparency burden. It says the tool 'Queries HES Designations' (implying read-only), lists the output fields (type, category, location), and discloses parameter constraints (radius_m requires lat/lon). It lacks explicit mention of authentication or rate limits, but for a search tool, the core behavioral context is well covered.

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 organized with clear 'Args', 'Returns', and 'Tips for LLMs' sections, each sentence providing distinct value. It avoids redundancy and front-loads the core purpose before details, making it appropriately sized for the tool's complexity.

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 a complex 8-parameter tool with no annotations and no output schema, this description is highly complete. It specifies the query types, parameter formats, return contents, and relationships to sibling tools, leaving no major ambiguity for an agent to select and invoke the tool correctly.

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 input schema has 8 parameters with zero descriptions, and the description compensates by detailing every parameter: allowed values for designation_type, partial/case-insensitive behavior for name, coordinate system for bbox (BNG EPSG:27700), lat/lon and radius dependency, and defaults for max_results and output_mode. This goes far beyond the bare 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 names the specific verb 'Search' and the resource 'Scottish designated heritage assets', then enumerates the designation types queried (listed buildings, scheduled monuments, gardens, battlefields, world heritage sites, conservation areas, historic marine protected areas). This clearly differentiates it from sibling tools like her_search_designations (English) and her_search_scotland (all Scottish sites).

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 'Tips for LLMs' section explicitly instructs to use this tool for formally designated Scottish assets, and points to her_search_scotland for non-designated sites and to her_search_designations for English NHLE sources. This is explicit when-to-use and alternative guidance, covering both exclusive and inclusive cases.

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?

With no annotations provided, the description carries the full burden. It discloses the function's read-only nature implicitly, details the output contents, and documents the output_mode parameter. It does not mention errors or rate limits, but for a simple health check the behavior is clearly communicated.

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 well-structured with clear sections (Args, Returns, Tips). It is mostly concise, though the second 'Returns' statement partially repeats the opening sentence. Overall it is efficient and front-loaded.

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, one optional parameter, and no output schema, the description is complete. It explains what is returned, the parameter's behavior, and even provides strategic usage guidance relative to sibling tools.

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 schema provides only type and default for output_mode, with no description. The description adds concrete semantics: 'Response format — "json" (default) or "text"', which fully explains the parameter's meaning and allowed values.

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 uses a specific verb ('Check') and resource ('server health and data source availability'), and clearly states return contents (server version, source statuses, tool count). This distinguishes it from sibling data-access tools, making the purpose unmistakable.

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 'Tips for LLMs' section explicitly says 'Call this first to check which sources are available', giving clear when-to-use guidance. It does not exclude any alternatives, but for a status-check tool the context is sufficient.

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