2b2t Atlas

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the result is historical geometry rather than live routing, and recordUrl is a permanent 301 alias while interactiveUrl/apiUrl serve different consumption modes.

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 sentence is correctly front-loaded, but the remainder is a grab-bag of URL-field advice (interactiveUrl, recordUrl, apiUrl/JSONL, locationInteractiveUrl/locationRecordUrl) that reads more like return-value documentation than invocation guidance, and the field naming is dense.

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 values need not be re-explained, yet the description usefully covers the output URL aliases and the historical-vs-live distinction. The origin-selection alternatives and 8:1 conversion caveats are left to the schema, which is adequate but means the description alone is not fully self-contained.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including the x/z-or-location_id-or-location_name alternatives. The worked example reinforces the location_name/highway_dimension/limit combination but adds no semantics beyond what the schema states.

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 and resource ('Find nearest points on approved highway polylines') and sharpens scope with 'Historical geometry, not routing or live passability.' It does not name the relevant siblings (search_highways, get_highway), so differentiation is left implicit rather than explicit.

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

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

The description distinguishes itself from routing/live-passability use cases and offers an example call, which implies when it fits. However, it gives no explicit when-to-use guidance versus search_highways, get_highway, or find_locations_near, so tool selection must be inferred.

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 read-only safety profile, but the description adds substantial behavioral context beyond them: year/month-only dates match overlapping ranges and captureDatePrecision disambiguates, and recordUrl carries a permanent HTTP 301 redirect to interactive HTML. These are non-obvious behaviors an agent needs in order to interpret results correctly.

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

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

Front-loaded with the core purpose and the sibling distinction, then proceeds through date semantics and URL guidance with no filler. It is dense and a little long, with the URL-variant sentences reading as secondary to the main selection decision, but every sentence carries usable information.

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

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

For a filtered-list tool with an output schema present, the description needn't explain return values, yet it usefully clarifies the URL fields agents will encounter and the date-matching edge case. Combined with annotations covering safety, nothing needed to call or interpret the tool is 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 100%, so from/to/limit/dimension are already fully documented in the schema. The description adds no syntax or constraint detail for these four parameters (its detail is about output URL fields and date-matching semantics). Baseline 3 is appropriate when the schema does the heavy lifting.

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) plus resource (locations) scoped to 'Archive warp or public render captured within inclusive historical dates', and explicitly names the sibling find_recently_added_or_modified as the tool for a different date concept. An agent can distinguish it from search_locations and find_recently_added_or_modified without opening any schema.

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 routing: 'For when records were added/modified in Atlas use find_recently_added_or_modified', plus a caveat that capture dates are not founding/destruction dates. It also advises which URL variant to prefer for human links vs JSON, giving concrete selection conditions rather than leaving them 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 cover the safety profile (readOnly/non-destructive/not open-world), so the description is freed to add value, which it does: 'filters before limiting' discloses evaluation order, and the interactiveUrl/recordUrl/apiUrl guidance explains link provenance and the 301 redirect behavior. It stops short of describing pagination or result caps beyond the schema's limit field.

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?

Purpose and routing are correctly front-loaded in the first two clauses, and the example is compact. The trailing URL-provenance sentences are useful but dense and slightly tangential to finding locations, making the description longer than strictly necessary.

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 11 fully documented parameters and an output schema present, return values need not be explained, and the description still adds filtering order, alternatives, and an example. Coverage is strong; only edge behaviors like pagination or ambiguity handling beyond 'ambiguous names require an ID' are left to the schema.

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

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

Schema coverage is 100%, so the baseline is 3; the schemas already document mutual exclusion of x/z, location_id, and location_name. The inline example concretizes a realistic call (location_name, radius, limit, exclude_origin) but adds no semantics the schema lacks, so no bump above baseline.

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 clause states a specific verb (find), resource (locations), and the distinguishing mechanism (exact planar distance), which cleanly separates it from search_locations (text-based). It also names two sibling alternatives by name, so an agent can discriminate without opening schemas.

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 routing is given: use search_locations for text discovery and research_area for nearby groups/preservation/highways combined. The implicit 'when' for this tool (exact planar distance from a coordinate or origin location) is clear from the same sentence.

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 a safe read (readOnly, non-destructive), and the description adds substantial behavior beyond them: pagination order (nearest first then ID), page cap of 25, nextOffset continuation with unchanged filters, and the Nether not_captured outcome. This is exactly the extra operational context annotations cannot carry.

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?

Purpose is front-loaded and each sentence adds a rule (semantics, pagination, dimension, workflow). It is dense but earns its length, though a few phrasings ('Roots are not centers, bases or players') are terse enough to require a second read.

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 6-param, paginated, dimension-aware query with an output schema already documenting returns, the description covers behavior, pagination, and dimension caveats well. The main omission is explicit semantics for the required x/z, but otherwise an agent has enough to invoke it 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%, so the description carries the burden and mostly does: it constrains radius (1..8192 blocks), explains dimension behavior, and describes offset/limit through the pagination rules. x and z are only implied as the circle center ('native horizontal circle') and never explicitly defined, leaving a small 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 specific verb and resource ('Page through historical NoCom DBSCAN cluster roots') and immediately disambiguates the entity by excluding centers, bases, and players. Combined with the NoCom-specific naming, an agent can separate it from siblings like find_nocom_portals or find_locations_near without opening the schema.

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 concrete conditions: dimension matters (Overworld/End capture roots, Nether returns not_captured), and workflow guidance such as 'Use footprintJsonUrl for all member chunks' and 'Resolve named locations first.' It stops short of naming a specific alternative tool, so it is clear context without explicit 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 already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real value beyond them: the 16384x16384 rectangle cap, row limits (max 1000, default 100), cursor-consistency rules, and the privacy note that no player identities/visits/ownership are inferred.

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

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

Four dense sentences, front-loaded with purpose, then limits, pagination, and output/privacy notes. Every sentence earns its place, though the packed multi-clause style is slightly heavy.

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, and the description still covers pagination, row caps, the CSV alternative, and privacy boundaries. It is complete enough for correct invocation, missing only explicit sibling routing and per-axis bound semantics.

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 carry all parameter meaning, and it does reasonably well: it explains date as a UTC day, the large number of bound parameters as a rectangle with a size cap, limit's max/default, cursor as nextCursor, and dimension via the export note. Only the exact meaning of individual min_x/min_z/max_x/max_z axes and the dimension enum values are left implicit.

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 and resource ('List observed NoCom chunks and exact counts') scoped precisely to one UTC day and a native-block rectangle. It is easy to distinguish from the many other find_nocom_* tools by its daily/chunk/rectangle framing, though it never names its closest siblings (get_nocom_daily_dataset, get_nocom_daily_hits) 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 explicit operational guidance: follow nextCursor with unchanged date/dimension/bounds for pagination, and use the linked gzip CSV when a complete dimension/day export is needed. This routes the agent to an alternative under a clear condition, though it doesn't state when to prefer this over the sibling daily dataset/hits tools.

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds substantial behavioral detail: grouping method ('face-adjacent observed portal blocks'), the non-equivalence to active portals, radius semantics ('measures representative blocks, not group centers'), result ordering and limit ('Max 25 results, nearest first then stable ID'), pagination, and citation requirements ('Cite canonicalUrl and sourceJsonUrl; never infer ownership'). It also discloses the coverage field for Nether/End. No contradiction with 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?

The description is information-dense but each sentence adds value. It opens with purpose, then covers grouping, dimension restrictions, radius semantics, result limits/order, pagination, and citation requirements. No filler or redundancy. The structure is logical 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 complexity (8 params, output schema present), the description covers purpose, scope, behavioral nuances, result limits, ordering, pagination, and citation obligations. It even warns about not inferring ownership or present-day survival. The output schema handles return structure, so the description is sufficient for an agent to call 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?

With 0% schema description coverage, the description compensates for several key parameters: radius ('Radius 1..8192 horizontal blocks measures representative blocks, not group centers'), limit ('Max 25 results'), and dimension (implied by Overworld-only). It also hints at offset via nextOffset. However, it does not explain x, z, min_y, max_y, or offset in detail, so it is not fully compensating for all 8 parameters.

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 ('Find'), a specific resource ('historical NoCom portal groups'), and a clear scope ('near native Minecraft coordinates'). It also explicitly distinguishes these groups from what they are not ('not simultaneous active portals or verified Nether connections'), which differentiates it from sibling tools like find_nocom_storage or find_preserved_builds.

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: it is Overworld-only ('Only Overworld portal observations exist; Nether/End return coverage=not_captured'), and it explains pagination behavior ('follow nextOffset with unchanged filters'). It does not explicitly name alternative tools for other dimensions or scenarios, but the Overworld restriction and the specific resource make usage conditions 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?

Annotations already cover safety (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: max 25 rows, the observation-vs-placement date caveat, no replacement/survival verification, no Nether/End coverage, and citation requirements. This is unusually rich disclosure that meaningfully changes how an agent interprets the results.

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?

Dense but front-loaded, leading with scope and the block-vs-structure distinction before constraints and caveats. Nearly every clause carries information, though the citation/ownership reminder is slightly softer than the rest.

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 a dedicated output schema, return-value description is unnecessary, and the definition still references canonicalUrl and sourceJsonUrl for citation. Combined with rich behavioral caveats, coverage is strong; only the undocumented 'dimension' parameter leaves a small gap.

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% across 9 params, so the description must compensate, and it largely does: x/z pairing rule, kind values, Y range 0..255, radius range 1..8192, limit cap of 25, and offset via nextOffset. It does not explain 'dimension' beyond implying Overworld-only, leaving one parameter under-specified.

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 ('Query') and resource ('NoCom rare-block extraction') with concrete scope: 419 Overworld bedrock positions above Y4 and 39 End portal frame positions. It explicitly distinguishes itself from nearby siblings, noting 'these are blocks, not structures or full portals,' which separates it from find_nocom_portals and find_nocom_special_blocks.

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 clear invocation conditions: 'Supply neither x/z to discover all records, or both for a native-coordinate circle of radius 1..8192,' plus optional kind and Y filters. It also explains pagination continuation ('follow nextOffset with unchanged filters'). It does not, however, explicitly name which sibling tool to use for cluster or storage queries instead.

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 only cover readOnly/destructive/openWorld safety. The description adds substantial behavior: reviewed-subset-only semantics, hash-verified preserved WDL at exact NoCom XYZ, endGateway returning zero, Overworld-only coverage, and pagination cap 'max25/page'. This is rich context an agent cannot get 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?

Front-loaded with the two operating modes, then constraints, then citation/usage caveats. Information-dense with little waste, though the dense run-on phrasing slightly hurts scanability.

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 format needn't be described. The description covers scoping, exclusions, citation guidance, and date-handling caveats well; the main gap is missing semantics for limit/offset/dimension given 0% schema coverage.

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 7 params, so the description must carry the load. It explains kind values, x/z pairing, and radius bounds ('radius 1..8192 native blocks'), but leaves limit, offset, and dimension undocumented in both schema and text. 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 specific verbs and resources: 'Find corroborated illegal spawners or inspect End gateway extraction coverage,' then pins the two kind values and what each returns. An agent can distinguish this from siblings like find_nocom_rare_blocks or find_nocom_storage. It stops short of explicitly naming those siblings, keeping it at 4.

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 when/when-not guidance: illegalSpawner is the default and returns only the reviewed subset, with the caveat 'It is not a census of all illegal spawners; ordinary/unverified spawners are excluded.' Also warns 'Do not infer current survival or ownership.' No alternatives are named by name, so not 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?

Beyond the readOnlyHint=true annotation, the description discloses rich behavioral traits: dimension coverage caveat ('other dimensions return coverage=not_captured'), pagination contract ('follow nextOffset with unchanged filters'), a hard page cap ('Max 25 results per page'), sort order ('nearest first then stable ID'), and a citation duty ('Cite canonicalUrl and sourceJsonUrl'). No contradiction with 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?

Seven sentences, each carrying distinct operational value — purpose, prerequisite, exclusions, dimension caveat, radius semantics, sorting/pagination, citation and cap. It is front-loaded with the purpose statement. Dense but not bloated; the only near-redundancy is the radius range restating a schema default range, though the schema lacks an explicit min/max so it is genuinely new information.

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

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

For a 10-parameter tool with output schema present and readOnly/destructive annotations covering the safety profile, the description covers the operational contract well: prerequisite workflow, dimension caveat, pagination, page cap, and citation. Remaining gaps are hide_changed and min_y/max_y semantics, plus fallback behavior when coordinates have no resolved base — minor but non-trivial 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 only 20% (dimension and block_type), so the description must compensate — and largely does: radius semantics and range ('Radius is horizontal blocks, 1..8192'), dimension behavior via the coverage caveat, limit via 'Max 25 results per page', offset via 'follow nextOffset', and block_type values in the first sentence. Residual gaps: hide_changed and min_y/max_y semantics are explained nowhere.

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?

Opens with a specific verb+resource+scope: 'Find historical NoCom chest/shulker/ender-chest block positions near native Minecraft coordinates.' The block-type specificity clearly distinguishes it from siblings like find_nocom_portals (portals) and find_locations_near (named locations), and the exclusion 'Not inventories, ownership or current survival' sharpens the boundary further.

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 prescribes a prerequisite workflow: 'Resolve a named base with get_location/search_locations first and use its native dimension,' and states exclusions ('Not inventories, ownership or current survival'). It stops short of naming an alternative sibling for those excluded concerns or for other block categories (portals/signs), so it lacks full when-not-alternative routing.

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, non-destructive, non-openWorld). The description adds genuinely new behavioral facts: recordUrl is a stable provenance alias with a permanent HTTP 301 redirect, and derivative records use locationInteractiveUrl/locationRecordUrl. That distinguishing detail on URL permanence and aliasing goes beyond what annotations 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-loaded with the core purpose, then the filter set, then URL guidance. Every sentence carries information, though the three-sentence URL block is dense and could be compressed; still, none of it is filler.

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, and the description wisely augments it with URL field semantics that an agent would otherwise have to infer. All six optional parameters are accounted for. The only gap is the absence of any routing guidance versus the many sibling search/find 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?

Schema description coverage is 100%, and the schema already documents every parameter including defaults, ranges (limit 1-100), dimension enum values (0/1/2) and YYYY-MM-DD date format. The description only restates the filter categories at a high level, adding no syntax or semantics beyond the schema, so the baseline 3 applies.

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 ('Find preserved 2b2t builds') and a qualifying scope that sharpens the meaning: builds that have BOTH a public map render AND a downloadable bounded world snapshot. That dual requirement is what separates it from siblings like get_world_downloads or get_group_builds, so an agent can identify the right tool without opening schemas.

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 names the optional filters (group, dimension, capture dates) and gives output-selection guidance ('Prefer interactiveUrl for human links... Use apiUrl or JSONL for JSON'), but never states when to choose this tool over a sibling such as get_group_builds or get_world_downloads, and gives no exclusions. 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.

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description goes beyond them by disclosing result ordering, the incompleteness caveat about render-only changes, and URL provenance behavior (permanent 301 redirect, stable alias). The URL field guidance is partly redundant with the existing output schema, keeping this short of 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?

Purpose, alternative, and the disambiguating caveat are front-loaded in the first three sentences, and the example is compact. The trailing run of URL/apiUrl/derivative guidance is a mild laundry list that could be trimmed, but it is not padded prose.

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 filtered read tool with an output schema and 100% param coverage, this covers the essentials: what it returns, ordering, an explicit alternative for the adjacent use case, and a caveat on completeness. Nothing an agent needs to call it correctly is 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 100% and every parameter (from, to, kind, limit, dimension) is already documented in the schema. The worked example reinforces the from/to/kind usage but adds no syntax or constraint detail beyond what the schema provides, so the baseline 3 applies.

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 resource (location records added/modified in Atlas), the temporal scope (inclusive UTC dates), and the ordering (newest matching timestamp first). It explicitly contrasts itself with the sibling find_locations_by_time_range, so an agent can distinguish it without opening a schema.

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?

Names the alternative tool with the exact condition that selects it ('For historical capture dates use find_locations_by_time_range'), and adds a when-not caveat ('Not a complete change log; render-only changes may not update a location'). It even guides which URL field to use for human links vs. JSON, leaving little 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 readOnlyHint=true and destructiveHint=false, so the tool is safe to invoke. The description adds useful context by stating the data is public and counts are current, and by signaling that the output is machine-readable, which helps the agent set expectations.

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 a single, front-loaded sentence with no filler. Every word adds meaning: it names the action, the output type, the audience (machine-readable), the scope (public), and the target dataset.

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 no-parameter, read-only tool with an output schema present, the description covers all essential context. An agent knows what the tool returns, that it targets the public 2b2t Atlas dataset, and that invocation has no side effects.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter burden for the description to carry. Baseline 4 is appropriate because no additional parameter meaning is 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 uses a specific verb ('Return') and a clearly bounded resource ('current counts and machine-readable discovery links for the public 2b2t Atlas dataset'). It clearly differentiates this from the sibling find/search/location tools by focusing on dataset-level statistics.

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 gives a clear context for use: call when you need current counts or machine-readable discovery links for the public Atlas dataset. It does not explicitly name alternatives or when-not-to-use cases, but the no-argument, dataset-level scope makes that omission minor.

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 safety (readOnly, non-destructive, closed-world), but the description adds real behavioral context they cannot: the result is capped at the first 20 builds, pagination lives in a sibling tool, and the various URL fields have distinct semantics (interactiveUrl for human citations, recordUrl as a stable provenance alias with a permanent 301, apiUrl/JSONL for JSON). That is substantive disclosure beyond the structured fields.

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?

Purpose and its distinguishing scope are front-loaded in the first sentence, and every following sentence carries routing or field-semantics information. It is dense rather than padded, though the URL-alias sentences are tightly packed and could read more cleanly.

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 documentation is not required, yet the description still calls out the 20-build truncation and the meaning of each URL field, which are the details most likely to trip up an agent. Combined with explicit sibling routing, nothing needed to call it correctly is 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?

Only one parameter and schema description coverage is 100% ('Persistent numeric Atlas group ID'), so the schema already carries the semantics. The description mentions 'known group ID' but adds no format, range, or lookup guidance beyond the schema. Baseline 3 applies.

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 and resource ('Get a known group ID') and enumerates what comes back: history, links, total build count, and the first 20 builds. The phrase 'known group ID' plus the explicit routing to search_groups makes it clearly distinguishable from the search sibling.

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 explicit when-to-use routing: search_groups to discover the ID, get_group_builds with offset for more builds, get_location for full location details. Each alternative is named with the condition that selects it, leaving nothing 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond that: stable pagination semantics, the 301 redirect behavior of recordUrl, and which URL fields suit which consumers (human links vs. JSON/JSONL).

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?

Five short sentences, each carrying distinct information, with the core purpose and paging rule front-loaded. The trailing sentence on derivatives is slightly dense but still earns its place as routing 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?

An output schema exists, so return-value explanation is not required, yet the description still clarifies URL field semantics that an agent needs to pick the right link type. Coverage is strong across purpose, paging, and alternatives, with only minor redundancy against the output schema.

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

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

Schema coverage is 100%, so the schema already documents limit, offset, and group_id, which sets a baseline of 3. The description adds real meaning to offset by describing the intended paging loop (start at 0, advance by returned count), which the schema's bare 'zero-based result offset' does not.

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 and resource ('Page through a group's builds') plus the ordering guarantee ('stable name/ID order'). It distinguishes itself from the sibling get_group by specifying that get_group only returns the total count and first 20 builds, so an agent can route between them without opening schemas.

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 concrete invocation guidance ('Pass offset=0 initially, then advance by the returned count until a short page') and names the alternative (get_group) with the condition that selects it. It lacks an explicit 'when not to use' statement, but the context and alternative are clear.

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 (readOnlyHint, destructiveHint=false, openWorldHint=false), so the description adds genuinely new behavioral context: preserve original source links, prefer interactiveUrl for citations, recordUrl is a stable alias with a 301 redirect, and derivatives use location-prefixed URLs. This is meaningful guidance beyond the annotations, though it leans into output-format territory that the output schema partly 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?

Purpose and routing are front-loaded in the first two sentences, which is good. The trailing URL-guidance block (interactiveUrl/recordUrl/apiUrl/JSONL/derivatives) is dense and somewhat longer than strictly necessary, slightly diluting the structure.

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 not required. The description supplies the routing alternatives and link-handling semantics an agent needs to call and cite correctly, making it complete for this read-only single-param 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?

Schema description coverage is 100% and the single required 'id' param is documented in-schema as a persistent numeric Atlas highway ID. The description does not add syntax or format detail for the parameter, so the baseline 3 applies.

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 ('Get') and resource ('known public highway or canal ID') and enumerates the payload (geometry, metadata, credited groups, evidence notes, attachments, source links). It explicitly names the siblings search_highways and find_highways_near_location, so an agent can distinguish it without opening a schema.

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 explicit routing conditions: use search_highways to discover the ID, use find_highways_near_location for proximity. When-to-use and alternatives are fully specified rather than inferred.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral context about output URL forms: interactiveUrl for human links, recordUrl as a permanent 301 provenance alias, apiUrl/JSONL for JSON, and derivative URL fields. It does not discuss authentication or rate limits, but for this read-only retrieval tool the added URL semantics are substantive.

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 purpose is front-loaded in the first sentence, followed by alternative-tool routing and URL guidance. The URL details are dense and largely earn their place, though several sentences about URL aliases could arguably be trimmed since an output schema exists.

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 the retrieval scope, sibling alternatives, and output URL selection. With an output schema present and annotations covering safety, nothing essential for an agent to call this tool correctly is 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 coverage is 100% and the single parameter is already documented as 'Persistent numeric Atlas location ID.' The description says retrieval is 'by ID' but adds no syntax, format, or constraint beyond the schema, so the baseline 3 applies.

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 and resource ('Get one canonical location by ID') and enumerates the returned data classes. It also distinguishes itself from sibling tools search_locations and research_location, so an agent can identify its role without opening other schemas.

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 names the alternatives for non-ID use cases: 'For name discovery use search_locations; for name resolution with nearby context use research_location.' This gives a clear when-to-use and when-to-use-otherwise boundary.

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/non-destructive/closed-world, so the safety profile is covered. The description adds meaningful semantic context beyond that: all released server-1 hits are included, legacy timestamps are retained, and the crucial caveat that 'counts are observations, not unique players, visits or ownership' — preventing a common misreading of the data.

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?

Three tight sentences, front-loaded with the core action, then differentiation, then the data caveat. Nothing is padded and each sentence 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 an output schema present, the description need not explain return values, and it correctly focuses on purpose, contrast, and caveats. A zero-param discovery tool is adequately covered, though naming the follow-up hit-retrieval sibling would make routing fully 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 and resource ('Discover complete raw-source NoCom daily hit coverage') and enumerates the contents an agent gets back (checksums, query routes, map tiles, CSV manifest). It distinguishes daily from 'World Pulse monthly summaries', though it does not directly differentiate itself from the sibling get_nocom_dataset.

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 an explicit usage directive: 'Discover coverage before choosing dates,' which tells the agent this is a reconnaissance step preceding date selection. It contrasts with monthly summaries but never names the natural follow-up sibling (e.g. get_nocom_daily_hits) as the alternative for retrieving hits.

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 establish readOnly/non-destructive, and the description goes well beyond them: rectangle semantics (intersecting 16x16 chunks, not precise player positions), the caveat that missing hits do not imply inactivity, and a query-budget failure mode. These are non-obvious behavioral traits that materially change how results should be interpreted.

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

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

Front-loaded with the core action and scope, and each subsequent sentence carries distinct, non-redundant information. It is dense and runs long, but nothing reads as filler.

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 7-parameter read tool with an output schema, this covers the essentials: range limits, coordinate grouping rule, chunk-level approximation caveat, alternative tool, and failure mitigation. Return-value detail is correctly left to the output schema.

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

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

Schema coverage is 0%, so the description carries the full burden and does most of it: it defines from/to as an inclusive UTC range and states that all four min/max coordinates must be supplied together for a rectangle. The dimension parameter (default 'overworld') is never explained, which is the one remaining 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+resource ('Get exact daily NoCom hit counts') plus the scope ('over inclusive UTC date range'), which distinguishes it immediately from the monthly sibling get_nocom_periods and from find_nocom_daily_chunks. An agent can route to it without opening a schema.

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 gives prerequisites ('Resolve named locations with get_location first'), the alternative to avoid ('Keep monthly get_nocom_periods distinct'), and a fallback action when the limit is hit ('Reduce area/date range if query budget is exceeded'). It also spells out the two range regimes: 366 days globally vs 31 days for a rectangle.

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 establish readOnly/destructive=false, so the bar is lower. The description still adds real behavioral context: source links expose full sign histories, portal blocks and cluster footprints, daily raw-source coverage includes legacy dates, and observations are historical rather than players/inventories/ownership. These are meaningful data-semantics caveats beyond the 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?

Information-dense but written as a run-on with three separate sentence groups, the longest being a bare list of sibling tool names. Front-loading is weak (the purpose sentence is the vaguest one) and the sibling enumeration could be tightened, though little is outright filler.

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 detail is not required, and the description covers sibling routing and data semantics well enough for a no-arg discovery tool. The main remaining gap is an explicit statement of what the primary dataset returns.

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, so there is nothing for the description to clarify and schema coverage is moot; baseline 4 applies.

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 resource (NoCom dataset with complete-source manifests, checksums, native dimensions, map links) and distinguishes itself from get_nocom_daily_dataset, get_nocom_periods, and research_nocom_area. However, the opening phrase 'Discover NoCom World Pulse and Find data' is muddled and never states plainly what this dataset actually contains, so the core purpose stays slightly blurry.

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 explicitly routes the agent: use get_nocom_daily_dataset/get_nocom_daily_hits for exact UTC days, get_nocom_periods for fixed 30-day buckets, research_nocom_area for bounded synthesis, and the find_*/search_* tools for details. That is strong alternative-naming, though it never states when this tool itself is the right first choice versus those siblings.

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 readOnlyHint and destructiveHint annotations, the description discloses meaningful behavioral constraints: maximum row counts, the fact that counts reflect scanner bias rather than unique players/trips, and that the End has no released data. These directly affect result interpretation and are not available 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?

Three compact sentences, each carrying distinct useful information: purpose, row limits, bias caveat, and coverage caveat. No filler or redundant restatement of the schema.

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 and annotations covering safety, the description still adds essential caveats about row limits, scanner bias, and missing End data. An agent has enough to invoke the tool correctly and interpret results responsibly.

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

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

Schema description coverage is 100% for both parameters, so the baseline applies; the schema already documents dimension and direction values. The description adds context about bucketization and the End exclusion but does not need to repeat parameter syntax.

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 ('Get') and resource ('released historical Nocom highway observation counts') and clarifies the aggregation axes: compass direction and fixed 30-day buckets. This is distinctive enough to separate it from siblings like get_nocom_dataset, get_nocom_periods, or get_highway without inspecting schemas.

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 a narrow read-only lookup role but does not explicitly name alternatives or state when to prefer this tool over closely related siblings. The 'End has no released highway series' note gives one exclusion, but general selection guidance 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: the 39-item cap, fixed 30-day UTC bucketing, whole-bucket date selection, and the exclusion of exact-day/player counts. This gives the agent a realistic expectation of output granularity.

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, zero filler. The description front-loads the core action and output cap, then immediately clarifies the bucket semantics and limitations. Every clause 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?

For a read-only tool with no required parameters, full schema documentation, an output schema, and annotations covering safety, the description is complete. It explains the aggregation model, date behavior, and important caveats, so an agent has enough to call it 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 100% and each parameter already has a description. The tool description adds value by explaining that date filters select whole overlapping buckets and that results are capped at 39, which clarifies how the date parameters behave in practice beyond the schema's brief descriptions.

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 action ('Get'), the resource ('Nocom observation aggregates and tile templates'), and the key constraints ('up to 39', 'by dimension', 'overlapping fixed 30-day UTC buckets'). It is specific enough to distinguish this from sibling tools like get_nocom_dataset or get_nocom_highway_activity.

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 gives clear context about when this tool is appropriate: use it when you want bucket-level aggregates, not exact-day or player counts. It does not explicitly name alternative tools or say 'use X instead', so it stops short of a 5, but the negative guidance ('results are not exact-day counts or player counts') is useful for selection.

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 readOnlyHint/destructiveHint/openWorldHint already covering safety, the description adds substantive behavior: provenance and conflicts are included, same-time conflicting text is retained rather than ordered, a map link is returned, and the text is flagged as untrusted content that is not proof of authorship, placement date, or continuous presence. That last point is a meaningful safety disclosure beyond the 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?

Three sentences, all front-loaded and information-dense: what is read, what is included, and how conflicts/untrusted content are handled. Every sentence earns its place, though the third sentence packs several distinct caveats into one long 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?

An output schema exists, so return-shape explanation is not required, yet the description still summarizes contents (text versions, timestamps, provenance, conflicts, map link). Combined with annotations covering the safety profile, nothing an agent needs to call this correctly is 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 coverage is 0% and the single 'id' parameter is undocumented in the schema, so the description carries the burden — and it does specify the id's provenance (an ID returned by search_nocom_sign_history), which is the key constraint. It does not state the ID's format or validation rules, so it falls just short of fully compensating.

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 ('Read every captured text version and exact UTC read timestamp for a NoCom sign ID') and explicitly ties the input to its producer, search_nocom_sign_history, which cleanly separates it from that sibling. An agent can distinguish this history-lookup from search_nocom_signs/search_nocom_sign_history without opening a schema.

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 makes the workflow condition clear: the id must come from search_nocom_sign_history, so this is a follow-up/drill-down call. It stops short of stating when NOT to use it or naming other alternatives, but the context is unambiguous.

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 read-only, non-destructive, closed-world behavior. The description adds useful behavioral context beyond annotations: recordUrl has a permanent HTTP 301 redirect, interactiveUrl is preferred for human links, apiUrl/JSONL are for JSON consumption, and derivative URLs follow specific naming patterns.

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 front-loaded with the tool's purpose and then moves directly into output-URL semantics. Every sentence carries practical information, though the sequence of URL aliases and derivative names is somewhat dense.

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, the description need not explain return structure, but it still helpfully clarifies how to choose among returned URL forms. It covers the read-only metadata purpose and annotations cover safety, leaving only sibling-tool selection as a minor gap.

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?

There is a single required parameter, location_id, and the schema description coverage is 100%, so the schema already documents its meaning as a persistent numeric Atlas location ID. The description adds only the general phrase 'for a location' and does not supplement parameter semantics beyond the schema baseline.

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: 'List public map-render metadata for a location,' and enumerates the fields returned (tile templates, bounds, dates, provenance, WDL links). It does not explicitly distinguish this tool from siblings such as get_location or research_location, so it falls short of a 5 under the rubric.

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 offers implied usage by stating the tool lists render metadata for a location, and it gives guidance on which returned URL fields to prefer. However, it gives no explicit when-to-use guidance or alternatives against the many sibling tools that also retrieve location data.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful return-field context, including landing coordinates, capture date, checksum, WDL links, and URL stability/redirect behavior, though it does not cover permissions, rate limits, or pagination.

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 front-loaded in the first sentence, and the subsequent sentences provide output-field and URL guidance. It is somewhat dense with URL variant details, but most content earns its place for an agent consuming the results.

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

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

Given that an output schema exists and annotations cover the safety profile, the description is largely complete for calling the tool. It adds useful output semantics but does not address pagination or usage boundaries, which are minor gaps.

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

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

Schema description coverage is 100%, and the single location_id parameter is fully documented in the schema. The description does not add any further meaning for location_id, so the baseline score of 3 is appropriate.

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

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

States a specific verb and resource: 'List every Archive warp linked to a location.' This clearly identifies the operation and scope, though it does not explicitly contrast itself with sibling tools such as get_location or search_locations.

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 gives guidance on which URL fields to prefer, but does not say when to use get_warps versus alternatives, nor does it name any sibling tool or exclusion condition. Usage is only implied by the resource scope.

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 substantial context beyond the readOnly/non-destructive annotations: returns metadata and HTTPS ZIP URLs but never binary bytes, WDLs are bounded historical captures rather than complete copies, and recordUrl carries a permanent 301 redirect. These are exactly the behavioral facts 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?

Purpose is front-loaded in the first sentence, and every clause (no binary bytes, bounded captures, URL semantics) carries real decision value. It is slightly verbose in the field-by-field URL enumeration that overlaps the output schema.

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, the return shape need not be re-explained, yet the description still disambiguates the URL fields and their intended uses. Safety is covered by annotations, so nothing critical is missing 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 coverage is 100%, so the single location_id parameter is already fully documented in the schema. The description only implies location scoping ('for a location') and adds no syntax or format detail beyond that.

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 and resource ('List publicly downloadable world snapshots') scoped to a location. No sibling tool in the list performs this function, so the agent can distinguish it immediately.

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 explicit field-selection guidance: 'Prefer interactiveUrl for human links and citations', 'Use apiUrl or JSONL for JSON'. This is clear contextual direction, but it does not name when to call this tool instead of alternatives or any 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 already establish read-only, non-destructive, non-open-world behavior, so the safety bar is met without the description. The description adds genuine non-structured context: URL alias semantics ('recordUrl is a stable provenance alias with a permanent HTTP 301 redirect'), which field to prefer for human citations versus JSON consumption, and the derivative field naming convention. It does not mention pagination or result-volume behavior, keeping it short of 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?

Purpose and sibling routing are front-loaded, then an example, then output-field guidance — a sensible ordering. The closing block of four URL-related sentences is slightly dense for what is essentially output-field selection, but each sentence carries distinct instructions.

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 values need not be re-explained, yet the description usefully clarifies how to choose among the returned URL fields. Combined with the example and the sibling routing rules, an agent has enough to invoke this 9-parameter, zero-required tool correctly; only edge behavior (what happens with ambiguous names beyond 'requires an ID') is left implicit.

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

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

Schema description coverage is 100%, so every parameter (x/z, location_id, location_name, radius, dimension, group, limit, preserved_only) is already documented at the source. The inline example {'location_name':..., 'radius':25000, 'preserved_only':true} shows a valid combination but adds no meaning beyond what the schema states. Baseline 3 is appropriate.

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

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

The verb 'Bundle' is soft, but the resource set is enumerated concretely (nearby locations, credited groups, preservation and native-dimension highways), and the description explicitly distinguishes this composite tool from find_locations_near, research_location, and research_nocom_area. An agent can pick this over its nearest siblings without opening the schema.

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?

Three explicit routing rules are given with the condition that selects each alternative: 'For only nearby locations use find_locations_near; for one named place use research_location. Use research_nocom_area for recorded NoCom storage, signs and portals.' Nothing about tool choice 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: homonym ambiguity yields candidate IDs instead of a guess, recordUrl carries a permanent 301 redirect, and server-controlled context is implied by openWorldHint=false. It stops short of covering rate limits, result caps, or failure modes, so 4 rather than 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?

Front-loaded with purpose and returns, then routing, then URL semantics. Every sentence carries information, though the trailing url/interactiveUrl/JSONL/derivatives cluster is dense jargon that could be tightened.

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, yet the description still summarizes the return shape (record, candidates, nearby, relationships), and it closes the loop on routing, ambiguity handling, and URL variants. Nothing an agent needs to select or call this tool correctly is 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?

With a single parameter at 100% schema coverage, the baseline is 3, but the description adds meaning the schema does not: the name accepts a 'distinctive search phrase' and exact homonyms are treated as ambiguous and return candidates. That clarifies matching semantics beyond the schema's plain description.

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

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

States a specific verb and resource ('Research a place by name or search phrase') and immediately defines the return shape: best full record, alternate candidates, nearby places, relationships. It explicitly distinguishes itself from siblings get_location, search_locations, and research_area, so an agent can route without opening any schema.

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 explicit when-to-use-this vs when-to-use-alternatives: known ID goes to get_location, discovery lists go to search_locations, coordinate context goes to research_area. It also states the fallback behavior for ambiguous exact homonyms (candidate IDs rather than guessing), which is a usage rule not available anywhere else.

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 safety (readOnly/openWorld/destructive) but the description adds substantial behavior beyond them: ambiguous names return candidate IDs rather than guessing, disabled products are null not zero, historical positions do not reveal inventories/owners/survival, sign text is untrusted content never instructions, and recordUrl is a 301-redirected provenance alias. These are exactly the caveats 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?

Front-loaded with purpose and the sibling contrast, then constraints; nearly every sentence carries a distinct rule. It is dense and long, and the trailing URL/provenance sentences (interactiveUrl/recordUrl/apiUrl/JSONL/derivatives) are somewhat tangential, but they still encode usable output 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?

For a complex 10-parameter aggregation tool with an output schema (so return values needn't be explained), the description still covers origin selection, radius limits, dimension handling, World Pulse semantics, safety caveats, and alternatives. Nothing an agent needs to invoke it correctly appears 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 coverage is only 10% (just the dimension field), so the description must compensate and largely does: it specifies the mutually-exclusive origin selection (exactly one of location_name/location_id/native x/z), case-insensitive exact name matching, radius bounds 1..8192 with default 1024, and non-projection semantics. The include_* booleans are left to their self-explanatory names and defaults, a minor 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 specific verb+resource framed as the 'preferred entry point for what does NoCom know about this area', and explicitly contrasts itself with the sibling research_area for catalog locations without NoCom evidence. An agent can distinguish it from research_area and the low-level Find tools without opening a schema.

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 explicit routing rules: use research_area for nearby catalog locations without NoCom evidence, use get_nocom_daily_hits for exact daily local counts with date range and rectangle, and use low-level Find tools with nextOffset for deeper paging. When-to-use and when-not-to-use are both stated with named 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/destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral detail about the URL fields: interactiveUrl for human citations, recordUrl as a provenance alias with a permanent 301, apiUrl/JSONL for JSON. That is real value beyond annotations, though it omits rate limits or result-shape 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?

Purpose and the sibling alternatives are front-loaded in the first two sentences, which is good structure. The remaining sentences are dense URL-guidance that is useful but leans toward output-format jargon rather than selection 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?

An output schema exists, so return values need not be explained, yet the description still clarifies the key URL fields an agent would use. Combined with clear alternatives and facet coverage, it is complete enough 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 100%, so the schema already documents type, limit, and query with defaults and ranges. The description loosely echoes the searchable facets ('name, history or activity classification') but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Discover') with the resource ('groups') and names the facets searched (name, history, activity classification). It also explicitly differentiates itself from the siblings get_group and get_group_builds, so an agent can route without opening schemas.

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 states when to use this tool and names the alternatives with their selecting conditions: get_group for a known group ID, get_group_builds for paging builds. This is explicit when-to-use and when-not-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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: scope is limited to public/approved highways, recordUrl permanently 301-redirects to interactive HTML, and derivatives use the location* URL variants — useful for interpreting results and picking URLs.

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

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

Front-loaded with purpose and routing in the first sentence, then URL guidance. Dense but each clause earns its place; the final sentence about location* URL derivatives is slightly esoteric but still functional.

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 documentation isn't required, and the description instead covers scope, sibling routing, and URL selection semantics. For a read-only search tool with four fully documented optional parameters, nothing an agent needs to call it correctly is 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 coverage is 100%, so the schema already documents query, group, dimension and limit with defaults and ranges. The description echoes the search facets (name, history, dimension, group) but adds no syntax, format, or interaction detail beyond what the schema provides, leaving the baseline of 3 appropriate.

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

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

States a specific verb and resource ('Discover public, approved highways and canals') plus the searchable facets (name, history, dimension, group), and explicitly distinguishes itself from two siblings (get_highway for known IDs, find_highways_near_location for proximity). An agent can pick it correctly without opening a schema.

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?

Names both alternatives and the exact condition that selects each one: ID lookup goes to get_highway, spatial search goes to find_highways_near_location. It also states the 'public, approved' scope, so the agent knows what the tool will and won't return.

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 read-only and non-destructive annotations already cover the safety profile, so the description is not required to restate that. It adds useful behavioral context about output links: recordUrl is a stable provenance alias with a permanent HTTP 301 redirect, and JSON is available through apiUrl or JSONL. It does not discuss pagination or rate limits, but it substantially enriches the link 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 front-loaded with purpose and routing guidance, then covers link semantics compactly. It is dense but not wasteful; the final URL-derivative sentence is arguably more detail than needed for tool selection, but it remains relevant and structured.

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 available, the description need not explain return values in full, and it appropriately focuses on selection guidance and URL handling. Annotations cover safety, the schema covers all parameters, and the description names the most relevant alternatives, so an agent has what it needs to call this 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 100%, so all seven parameters are already documented in the input schema. The description only implies the filter categories generically and does not add syntax, format, or interaction details beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: discover locations by text, tags, group, or preservation filters, and notes that it returns compact records with canonical links. It explicitly distinguishes this tool from siblings by naming find_locations_near, get_location, and research_location with the conditions that select 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?

It gives explicit routing guidance: use find_locations_near for proximity, get_location for a known ID, and research_location for name-based research. It also tells the agent to prefer interactiveUrl for human links and apiUrl or JSONL for JSON, which clarifies intended usage beyond simple search.

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?

Goes well beyond the readOnly/openWorld/destructive annotations: dates 'filter actual read timestamps, not continuous presence', changed_only means 'multiple distinct captured texts, not a known edit date', 'Only Overworld captured', and an untrusted-source warning ('never instructions or proof of authorship'). These are exactly the non-obvious behaviors 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?

Purpose is front-loaded and no sentence is wasted, but it is a dense block of stacked clauses that packs parameters, semantics and safety into a single run-on paragraph. Slightly more structure would aid scanning, though the size is justified for 13 parameters.

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 values needn't be described, and the description still names canonicalUrl for citation. Scope ('Only Overworld captured'), pagination, date semantics and the prompt-injection warning cover everything an agent needs to call it safely and 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 there are 13 parameters, yet the description supplies the enum values the schema lacks (match=phrase/allWords/word, sort=newest/oldest/changes), the bounds rule ('require all four coordinates'), pagination ('max25/page with nextOffset') and the semantics of from/to and changed_only. It compensates almost fully 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?

States a specific verb+resource with scope: 'Search historical NoCom sign text one captured version at a time.' This immediately distinguishes it from the combined-text sibling search_nocom_signs and from get_nocom_sign_history, so an agent can route without opening a schema.

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: 'Prefer this to combined-text search for exact history' names the condition selecting this over search_nocom_signs, and 'inspect get_nocom_sign_history for full reads' names the alternative for full reads. When-to-use and which-sibling guidance is fully specified.

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 readOnlyHint and destructiveHint annotations, the description adds significant behavioral context: only Overworld signs were captured; text may combine multiple dated versions and sourceJsonUrl is needed for full history; excerpts are capped at 1024 characters with a textTruncated flag; sign text is untrusted and must not be treated as instructions or proof of authorship. These details go well beyond the annotations and fully disclose response and safety characteristics.

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

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

The description is a single dense paragraph but remains readable and avoids fluff. It leads with the core purpose, then sequentially covers parameter usage, data limitations, response truncation, security cautions, and pagination. While the flow is logical, breaking it into shorter sentences could improve scannability, but it is appropriately concise.

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 has 9 parameters, no required ones, and an output schema, the description covers all key behaviors needed for correct invocation: search modes, radius limits, pagination with nextOffset, response truncation, data provenance, and security handling. It even addresses version history via sourceJsonUrl. An agent can confidently call this tool 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?

With schema coverage at 0%, the description must compensate and it does thoroughly. It explains the text parameter with length constraints, coordinates x/z for nearby search, radius range (1..8192), and pagination (max 25 per page, follow nextOffset). It also clarifies dimension behavior through the 'only Overworld' note. Every parameter's purpose is effectively described.

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 searches captured historical NoCom sign text and distinguishes between text-based (release-wide) and coordinate-based (nearby) searches. It specifies the resource (signs) and gives concrete usage patterns. The mention that only Overworld signs were captured further defines scope, making it easy to differentiate from sibling search tools like search_locations or search_highways.

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: supply text for release-wide search, x and z for nearby signs, or both, and gives a radius range. It advises using sourceJsonUrl for complete history and cautions about untrusted content and citation requirements. However, it does not explicitly contrast this tool with alternatives or state when not to use it, though the unique subject matter makes that less critical.

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