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

Annotations declare readOnlyHint=true and idempotentHint=true, meaning the tool should not modify state. The description says 'Pin a release for later calls,' which implies a state-changing write operation. This directly contradicts the readOnly 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?

Two sentences, front-loaded with the primary purpose and followed by usage constraints. Every sentence carries useful information 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?

An output schema exists, so return values need not be explained. However, the description claims the tool can 'pin a release' despite having zero input parameters, leaving the pinning mechanism completely unexplained and making the described capability seem impossible to invoke.

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 takes zero parameters and schema description coverage is 100%, so the baseline is 4. The description adds no parameter semantics, but none are 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 a specific verb and resource: 'Discover all six themes/types and available releases.' It also distinguishes itself from search and resolve siblings by saying it 'does not query geographic features or resolve an address.' However, it does not differentiate from other catalog-adjacent siblings like overture_schema or overture_compare_releases.

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 gives explicit when-to-use guidance ('Use before searching') and a when-not boundary ('does not query geographic features or resolve an address'). It does not, however, name the alternative tools to use for those excluded tasks, which would be required for 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: return payload shape (counts plus paginated changes with before/after properties and schema changes), a size cap (<=5000 records per snapshot), and important semantic caveats about added/removed meaning scope-crossing rather than global creation/deletion, plus the ID-stability warning for Addresses/Base/building_part.

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-loads the core comparison purpose in the first sentence, then packs operational caveats into compact clauses. Dense but nearly every sentence carries non-obvious information; minor redundancy around naming the catalog sibling is acceptable.

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 10-parameter tool with a nested Bounds/AttributeFilter schema and an existing output schema, the description covers the critical gaps: scope constraints, result semantics, size limits, and ID reliability. It could do more to explain theme/status/cursor parameters, but for a read-only comparison tool it is largely 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 description clarifies that before/after are snapshot IDs, that filtering happens on the same area/filters, and that fields selection does not limit which properties are compared. With schema description coverage at 0% for the 10 top-level params, however, enums (theme, status) and cursor/limit semantics remain undocumented in both places, leaving a real 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?

States a precise verb ('Compare') and resource ('two available release snapshots by ID') with scoping qualifiers (same area, same filters). This is clearly distinguishable from sibling tools like overture_catalog, which it explicitly names as the place to find releases.

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 (need two release IDs from the same theme/area) and routes the agent to overture_catalog for available releases. It also clarifies the semantic meaning of 'added/removed'. It stops short of an explicit when-to-use-this-vs-alternatives statement, but the routing hint gives usable 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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses genuinely useful behavior: lookup pinning semantics with and without bounds, and the non-obvious caveat that empty scoped results do not establish global nonexistence. It adds context the annotations cannot express, only missing return/pagination behavior (which the output schema covers).

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 purpose is stated up front and each following sentence adds a distinct rule (bounds behavior, requirement conditions, empty-result caveat, fields). It is dense but every sentence earns its place; phrasing is slightly cryptic in the opening clause.

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 an output schema present, return-value explanation is unnecessary, and the annotations cover the safety profile. The description supplies the bounds/pinning and empty-result semantics an agent needs to call it correctly; only a few parameter details (identifier, include_geometry) are missing.

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 carry the burden. It explains bounds, release, fields ('chooses properties; default is all'), and references theme/type, but leaves identifier and include_geometry unexplained, so it only partially compensates for the coverage 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 states a specific verb+resource: 'Get a UUID feature from search' — retrieve a single feature by its identifier. It is understandable on its own and implicitly distinct from list-oriented siblings like overture_search, but it never names an alternative or explicitly contrasts, so it falls short of a 5.

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 gives real conditional guidance: with bounds the lookup is pinned to an area/release; without bounds it uses the GERS registry and requires matching theme/type/current release, and non-GERS/historical releases need bounds. That is clear when-to-use context, though it stops short of naming sibling tools to prefer or avoid.

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?

Adds genuinely useful behavior beyond the annotations (which only cover read-only/idempotent safety): stable ordering by distance then ID, zero distance for a containing polygon, geodesic point distances vs azimuthal-equidistant projection for line/polygon edges, and the meaning of an empty result. It stops short of covering pagination/cursor behavior or the limit interplay.

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-loads the purpose in the first clause, then layers the behavioral notes; every sentence adds information and there is no filler. Minor deduction for the multi-line indented formatting, which is slightly awkward for a short description.

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?

An output schema exists, so return-value explanation is rightly omitted, but for a 10-parameter tool with 0% schema coverage the description is too thin: it never explains the required theme/feature_type selection or the cursor/filters/limit mechanics. An agent could call it, but not confidently or efficiently.

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% across 10 parameters, so the description carries the full burden, yet it only clarifies radius_m ('distance in meters') and gestures at center. Theme, feature_type, limit, cursor, fields, filters, release and include_geometry get no explanation in either place, leaving most of the parameter surface undocumented.

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?

States a specific verb ('Find the nearest intersecting features') plus the resource and the scoping constraint (within a maximum radius, distance in meters). The proximity/nearest framing clearly sets it apart from sibling lookup tools like overture_search or overture_get_feature without needing to name them.

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?

Usage is only implied: the radius-based nearest search makes the intended scenario inferable, and the note that an empty result means nothing was within the radius helps interpret outcomes. However, it never states when to prefer this over overture_search or overture_spatial_join, nor any prerequisites or 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds substantial non-obvious behavior: the registry is unversioned, excludes certain themes, and returns one of three states (live feature/verified file, removed metadata, not_in_registry). This is meaningful context the annotations cannot convey.

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-loads the core purpose, then layers return states, exclusions, alternatives, and a caveat. Dense but each sentence carries distinct information; minor verbosity in the multi-clause return-state sentence.

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?

An output schema exists, so return values need not be enumerated, yet the description still maps the three outcome states usefully. It covers registry scope, alternatives, and interpretation caveats; the only residual gap is parameter-level detail for fields.

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% across three parameters, so the description must compensate. It does clarify the default (all properties and geometry), which maps to include_geometry and fields, but never explains the semantics of the fields list itself or identifier format. Partial compensation only.

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?

States a specific verb (resolve) plus resource (a UUID/ID) and names the mechanism (current GERS registry) and the key differentiator: resolution without knowing theme or position. It is immediately distinguishable from overture_get_feature, which it explicitly references.

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 routes the agent: use overture_get_feature with known bounds for excluded IDs (Addresses/Base/building_part) or historical releases. It also warns never to infer global nonexistence from a not_in_registry result, which is exactly the kind of when-not-to-conclude guidance agents need.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful context beyond them: it reads Parquet metadata rather than feature rows, signalling a cheap metadata call rather than a data fetch.

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 short sentences, front-loaded with the purpose and then the pairing hint. Very little waste, though the trailing whitespace/newline formatting is a minor blemish.

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?

An output schema exists so return values need not be described. The key behavioral fact (metadata, not rows) is stated, and usage context is given; only the undocumented release parameter limits 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?

Schema description coverage is 0%, so the description must carry the load. Its 'theme/type' phrasing maps to the two required parameters (theme, feature_type), but the optional release parameter is never mentioned, leaving one of three params undocumented.

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?

States a specific verb+resource: inspect dataset columns for a theme/feature_type. It distinguishes itself from data-reading siblings by scoping to column metadata prior to filtering or grouping. It doesn't explicitly name which sibling it contrasts with, but the scope is clear.

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?

Gives a clear when-to-use: before filtering or grouping, and directs the agent to pair it with overture_catalog. No explicit when-not or alternative is named, so it falls just short of the top band.

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 cover read-only/idempotent/open-world/non-destructive, and the description adds real behavior on top: invalid filters raise errors instead of being silently ignored, confidence is places-only, no user SQL is accepted, distance ordering requires a center, include_metrics returns whole-feature m² / line meters, and geojson returns a paginated FeatureCollection whose provenance should be retained.

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?

Tight, front-loaded, and every line carries information with no filler. The terse fragment style (several dropped subjects) slightly reduces readability, but nothing is wasted.

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?

An output schema exists so return values needn't be spelled out, and pagination/error/metrics behavior is covered. However, for a 19-parameter tool with 0% schema description coverage, the required feature_type and the theme/feature_class vocabularies are never explained, leaving an agent guessing at valid inputs for mandatory fields.

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?

At 0% schema coverage the description carries the burden and handles the hard parameters well: name as literal case-insensitive substring, category as exact taxonomy.primary, cursor/release pagination coupling, the three geometry input modes, the filters grammar (up to 20 typed AND conditions, nested/list paths like sources[].dataset), sort_by='distance' needing center, and include_metrics units. It does not explain required feature_type or theme/feature_class values, which keeps it from 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?

Clear verb+resource+scope: 'Search intersecting features in a bounded WGS84 area across any of the six themes.' Specific enough that an agent can tell it apart from retrieval-by-id or nearest-search siblings by the bounded-area framing, though no sibling is named explicitly.

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?

Gives operational rules (pass next_cursor unchanged with the same release/filters; distance order needs center; choose bounds, center/radius_m, or polygon; invalid filters error rather than being ignored), which implies when and how to use it. But it never says when to prefer a sibling like overture_nearest or overture_spatial_join, so alternative selection is left to inference.

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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses a hard candidate cap ('<=5000 candidates each or fail without partial analysis'), pagination behavior, that group_left includes zero-match left IDs, and that within_distance uses a local projected minimum geometry distance in meters. These are non-obvious operational traits that materially affect calling behavior.

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 core concept is front-loaded in the first sentence, and the following sentences each add distinct semantics (direction, candidate limit, mode outputs, distance units). It is dense but nearly every clause earns its place, with only minor terseness in the pagination sentence.

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 an output schema present, return-value detail is optional, yet the description helpfully characterizes what pairs/count/group_left produce. Combined with the candidate-cap and distance-metric disclosures, an agent has enough to invoke correctly, though per-parameter specifics remain thin.

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 carries the burden, and it does explain relation direction, the mode semantics, and distance_m units. However, left/right Dataset structure (theme, feature_type, fields, filters), bounds, limit, cursor, and release are left to the schema, so compensation is only partial.

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 verb and resource: 'Relate features across themes/types in one release and bounded area,' which distinguishes it as a spatial-join tool from siblings like overture_nearest or overture_search. It is clear but does not explicitly name a sibling alternative, so it stops short of a 5.

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?

Usage is implied through the relation and mode explanations (e.g., 'places within division_area, or areas containing places') and the note that 'within_distance needs distance_m,' but there is no explicit when-to-use guidance or exclusion against alternatives such as overture_nearest for proximity work. Guidance exists but is left to inference.

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 readOnly/idempotent/non-destructive, so the safety bar is low, and the description adds genuinely non-obvious behavior: group results are truncated to the top 50 with an other_count bucket, counts/aggregates are over whole intersecting records rather than prorated, and circles are clipped with a 128-segment polygon. These are exactly the traits an agent cannot infer from annotations.

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?

Six short sentences, front-loaded with the core purpose before the eligibility rules and aggregation details. Dense but every sentence carries information; the phrasing is terse to the point of clipped, which slightly hurts readability but not economy.

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?

An output schema exists, so return values need no prose, and the description covers grouping/aggregation behavior well. However, for a 15-parameter tool with zero schema descriptions, the omission of most scalar filters (theme, feature_type, release, category, min_confidence on top of the two required ones) leaves an agent guessing at key inputs.

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% across 15 parameters, so the description carries real burden and does explain group_by (up to 3 scalar property paths), aggregations (the op set plus special @area_m2/@length_m/@distance_m fields requiring center), and clip_geometry's default scope. It says nothing about theme, feature_type, name, release, category, feature_class, min_confidence, or radius_m units/limits, so the compensation is only partial.

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 opening sentence gives a specific verb and resource: counting dataset features intersecting a bounded area, with optional grouping. It implicitly separates itself from overture_search (which returns records, not counts), though it never names the sibling outright. Clear enough that an agent knows this is an aggregation 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?

"Accepts exactly the same area/attribute conditions as search" establishes a relationship to a sibling and implies this is the counting/aggregating counterpart, but it never states when to pick this over overture_search, overture_nearest, or overture_spatial_join. Usage is implied rather than directed.

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