2b2t Atlas

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

Annotations already declare this a safe read (readOnlyHint true, destructiveHint false), so the bar is lower; the description still adds substantive context — the data is historical rather than live passability, and recordUrl is a permanent 301 redirect to the interactive HTML while apiUrl/JSONL serve JSON. It omits result ordering/tie-breaking and how nearest-point distance is computed.

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 historical-geometry caveat, then the example, then output-format notes. The URL field enumeration (interactiveUrl, recordUrl, apiUrl, JSONL, locationInteractiveUrl/locationRecordUrl) is dense and partly overlaps the output schema, but each sentence still conveys 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 7-parameter proximity search with a full output schema, the description plus schema cover coordinate vs. location_id vs. name origins, dimension inference and 8:1 conversion, and the historical-data caveat. 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 carries parameter meaning and baseline 3 applies. The description goes beyond it by showing a worked parameter combination (location_name + highway_dimension + limit) that demonstrates how the origin selector and highway dimension are used together.

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 immediately bounds the scope with 'Historical geometry, not routing or live passability', which separates it from routing-style tools and from get_highway/search_highways that operate on highway entities rather than proximity search.

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 concrete invocation example and steers output-format choice ('Prefer interactiveUrl for human links', 'Use apiUrl or JSONL for JSON'), but never says when to call this tool instead of siblings like find_locations_near or search_highways. Usage is implied by the example rather than stated.

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 declare a safe read, but the description goes well beyond: it clarifies partial-date matching behavior, the presence of captureDatePrecision, and the output URL contract (interactiveUrl for humans, recordUrl as a permanent 301 provenance alias, apiUrl/JSONL for JSON, and the location-prefixed derivative fields). That is substantive behavior an agent could not infer from 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?

The purpose and criterion are front-loaded in the opening sentence, followed by the exclusion and then field-level guidance. It is dense but every sentence carries information; the URL-routing sentences are slightly more reference material than selection guidance, which keeps it from a 5.

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 four simple parameters and an output schema present, nothing essential is missing: the date semantics, the alternative tool, and the field-name conventions for links are all covered. The description does not waste space re-explaining return structure the output schema already defines.

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 already 100%, so the schema carries the baseline. The description still adds meaning the schema lacks: that partial year/month dates match any overlapping range and that captureDatePrecision disambiguates them, plus that the range is inclusive and historical. Dimension and limit values are left entirely to the schema.

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

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

The first sentence names a specific verb and resource (find locations) and a precise selection criterion (an Archive warp or public render captured within inclusive historical dates). It also explicitly distinguishes itself from the sibling find_recently_added_or_modified by scope, so an agent can route between them without opening either 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?

It names the alternative tool for a different date concept and states the semantic trap directly ('Capture dates are not founding/destruction dates'), which is real usage guidance. It does not, however, distinguish this from the broader search_locations or geographic siblings like find_locations_near, so the routing picture is incomplete.

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 one genuine behavioral trait, "filters before limiting" (limit applies post-filter), plus URL-alias semantics, but these concern output artifacts already covered by the output schema. It doesn't disclose cost, performance characteristics of a 30M-block radius scan, or ambiguity handling for origins beyond what the schema states.

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, differentiation, and example are front-loaded in that order, which is the right priority. The trailing sentences on interactiveUrl/recordUrl/apiUrl/JSONL/derivative aliases are denser and slightly off-purpose for a spatial query tool, though each carries real information.

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

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

With 11 fully documented parameters and an output schema present, the description correctly avoids restating schema detail and focuses on routing and result-URL semantics. Remaining gap is behavioral: what happens with an ambiguous or unresolvable origin, and how expensive a maximum-radius query is.

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 description still adds value by demonstrating a valid parameter combination in the example and by sharpening semantics that the schema states loosely: "exact planar distance" for radius and "filters before limiting" for limit ordering.

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 locations") plus the distinguishing mechanism ("exact planar distance"), and immediately contrasts itself with search_locations and research_area. An agent can tell from the description alone that this is a spatial-radius query, not a text lookup.

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 to alternatives by condition: text discovery goes to search_locations, and grouped queries covering preservation/highways go to research_area. The inline example with a concrete radius/limit/exclude_origin combination further anchors correct invocation.

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, closed-world), so the description's real contribution is output semantics: recordUrl is a stable alias with a permanent 301 to the interactive HTML, apiUrl/JSONL serve JSON, and derivatives use location-prefixed fields. That is genuinely useful behavioral context an agent cannot get from annotations. Missing only operational details like pagination or rate limits.

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

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

The core definition and its render+snapshot constraint are front-loaded in the first sentence; the remaining sentences are dense field-selection guidance with little waste. It runs slightly long for a listing tool, but each URL sentence carries distinct information.

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

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

With an output schema present, the description does not need to enumerate return values, and it instead covers the two things the schema cannot: the inclusion invariant (render AND snapshot) and which URL field to use for human citations versus JSON consumers. An agent can call this correctly from the description plus schema alone.

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 all six parameters including formats (YYYY-MM-DD dates, dimension 0/1/2) are already documented in the schema. The description restates the filter categories without adding syntax or edge-case meaning, so 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 ('Find preserved 2b2t builds') and adds a distinguishing scope constraint: results must have both a public map render and a downloadable bounded world snapshot. That is more specific than any sibling name suggests, though it never explicitly contrasts with get_group_builds or search_world_find, so an agent must infer the boundary.

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 'optionally filtered by group, dimension, or capture dates' clause implies when the filters apply, and the URL guidance tells the agent which field to pick for which purpose. But there is no explicit when-to-use-this-vs-sibling statement and no note about when the render+snapshot invariant would exclude otherwise relevant results.

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

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

Annotations already declare a safe read-only profile, and the description adds real behavioral context: result ordering (newest matching timestamp first), the incompleteness of change capture, and the semantics of each returned URL type including the permanent 301 redirect behind recordUrl. This goes well beyond what annotations provide.

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?

Scope, alternative and caveats are front-loaded in the first two sentences, which is exactly the right ordering. The trailing four sentences on URL field selection are somewhat sprawling and partly duplicate what the output schema can convey.

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

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

Covers everything an agent needs for a filtered-list tool: date scope, ordering, mutation caveats, the exclusion to a sibling, and guidance on which returned URL field to cite. With an output schema present, further return-value detail is unnecessary.

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 from/to format, kind values, limit bounds and dimension are already documented. The inline example reinforces the date format and shows a concrete kind value, but it doesn't add new semantics for limit or dimension, 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+scope: location records added/modified in Atlas within inclusive UTC dates, ordered newest-first. It explicitly distinguishes itself from the sibling find_locations_by_time_range by assigning historical capture dates to that tool.

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

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

Gives an explicit routing rule ('For historical capture dates use find_locations_by_time_range') and a scope caveat ('Not a complete change log; render-only changes may not update a location'). An agent knows both when to pick this tool and when its results will be incomplete.

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 the read-only, non-destructive, closed-world profile, and the description adds real value beyond them: the 20-build cap, the permanent HTTP 301 behind recordUrl, and which URL field is appropriate for human links vs JSON. Minor gaps remain (build ordering, response size, auth/rate limits), which keeps it from 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?

Front-loaded with what is returned, then alternatives, then URL semantics — each sentence carries distinct operational value. The final URL-guidance run is dense and slightly run-on, but nothing is genuinely wasted.

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

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

An output schema exists, so return structure needn't be re-explained; the description still names the key fields an agent will cite. Combined with the sibling routing and URL-format guidance, an agent has everything needed 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?

There is a single required parameter with 100% schema coverage ('Persistent numeric Atlas group ID'), so the schema already carries the semantics. The description adds nothing about the id beyond what the schema states; 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 (fetch a group by known ID) and immediately enumerates the payload (history, links, total build count, first 20 builds). It distinguishes itself from search_groups, get_group_builds, and get_location by name, so an agent can route 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?

Explicit routing: use search_groups to discover an ID, get_group_builds with offset for more than the first 20 builds, and get_location for full location details. When-to-use and which-alternative conditions are both spelled out.

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 the read-only/non-destructive safety profile; the description adds the pagination termination rule, the redirect behavior of recordUrl (permanent HTTP 301 to interactive HTML), and which field to use for machine-readable output (apiUrl or JSONL). It also clarifies that derivative entities use different URL fields (locationInteractiveUrl/locationRecordUrl), which an agent could easily get wrong.

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, each with a distinct payload: pagination procedure, sibling relationship, URL selection, and derivative-field caveat. The call procedure is front-loaded and there is no 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, yet the description still adds the interpretive guidance an agent needs (which URL field for humans vs. JSON vs. derivatives) without duplicating field-by-field return docs. For a paged read tool with three simple params, nothing required for correct invocation 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 baseline is 3, but the description adds real semantics beyond the schema: offset should start at 0 and advance by the returned count, and iteration stops on a short page. It does not restate the 1-100 limit bound, which the schema already carries.

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 also explicitly separates itself from the sibling get_group, which 'supplies the total count and first 20 builds', so an agent can route between the two 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 an explicit call procedure ('Pass offset=0 initially, then advance by the returned count until a short page') and states the alternative path (get_group for totals and the first page). When-to-use, how-to-iterate, and the alternative are all named.

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

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

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 establish that this is read-only, non-destructive, and closed-world, and the description adds useful behavioral context: it returns a canonical record plus related data, and it explains URL alias semantics including a permanent 301 redirect. It does not cover pagination, response size, or error behavior, so it is strong but not fully exhaustive.

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 core action and then moves cleanly to sibling routing and output-URL selection. It is dense but each sentence serves a distinct disambiguation or usage purpose.

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

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

Given a one-parameter read-only tool with annotations and an output schema, the description supplies enough context: what is returned, which sibling tools cover adjacent tasks, and how to choose among interactive, record, and API URLs. No essential invocation context appears to be 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?

The single id parameter is fully documented in the schema as a 'Persistent numeric Atlas location ID,' and the description adds no syntax or format details beyond saying the lookup is by ID. With 100% schema coverage, the schema carries the parameter semantics and 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 description states a specific verb and resource: 'Get one canonical location by ID,' and lists the included data such as history, groups, warps, renders, attachments, WDLs, and provenance. It also clearly distinguishes this lookup-by-ID tool from search_locations and research_location.

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 search_locations for name discovery and research_location for name resolution with nearby context. That gives clear when-to-use-this vs when-to-use-alternatives 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 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?

The description goes well beyond the readOnly/destructive annotations: it discloses pagination (50 per page, follow nextOffset), what detailsJson may hold, that unknown inventories must not be read as empty, that dates describe captures or reads rather than placement or current survival, and that captured text is untrusted data. These are exactly the interpretive caveats an agent cannot infer from 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?

Six sentences, but each carries distinct payload and the identifying scope comes first. Slightly dense with caveats layered on caveats, but no sentence is filler and the ordering is front-loaded correctly.

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 shapes need not be explained, yet the description still clarifies the key ambiguity (detailsJson contents) plus the non-obvious semantic traps around missing inventories and date meaning. For a tool with an opinionated data model, nothing material is left for the agent to guess.

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 33% — kind and dimension are documented, while offset and the coordinate triple have no schema descriptions. The description partially compensates by explaining the page/nextOffset model, which effectively defines the offset parameter, and by framing kind as the 'category'. Coordinates are self-evident, so the gap is narrowed but not closed.

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: read public capture history at one dimension/category/XYZ position. The qualifier 'including sources outside the previous search filter' hints at how it differs from search_world_find and get_world_find_map, though it never names a sibling outright, and phrasing like 'native dimension/category' is jargon that requires the schema to decode.

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

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

Usage is implied rather than stated: the 'outside the previous search filter' clause suggests calling this after a search, and one sentence routes the agent onward ('Use an observation's id with get_world_find_inventory'). There is no explicit when-not-to-use guidance versus get_world_find_map, get_nocom_sign_history, or search_world_find, all of which cover overlapping territory.

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/destructive hints: the status vocabulary (recorded, empty, unknown, not_indexed, unavailable), null semantics for unknown totals, the 50-item page cap, the fact that observation IDs are index-scoped and require rediscovery after reindexing, plus an explicit untrusted-data warning against prompt injection from item names.

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 every sentence carries information, but the middle section is written in a dense, telegraphic style that packs status values, null rules and pagination into single clauses, which slightly raises parsing cost.

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 supplies exactly the missing operational context: data shape (item IDs, counts, slots, names, enchantments), nested path drilling, pagination mechanics, index volatility and trust boundaries. Nothing an agent needs to call it correctly appears absent.

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 20%, so the description carries most of the burden and does so for the non-obvious parameters: item_path gets its nested-shulker usage, include_saved_data is tied to limit=1 for raw components/tags, and pagination is explained via nextOffset with unchanged arguments and the 50 cap. limit and offset defaults themselves are left to the schema.

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

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

States a specific verb and resource: reading the saved contents of a single public storage observation from Find search/history. The phrase 'without scanning raw worlds' separates it from the search_world_find family, and 'one ... observation' separates it from list-shaped siblings.

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?

Establishes the usage context clearly (resolve saved inventories on demand rather than scanning raw worlds) and gives the nested-container procedure via item_path. It does not name a sibling alternative or state when not to use it, so it falls short of the top score.

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/non-destructive annotations: discloses that oversized views coarsen cells without dropping positions, explains what total vs groupCount count, gives the 50-group page cap, and warns that bounds/centers/counts describe groups, not individual containers. That last note heads off a real misuse.

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: purpose and constraints come first, drill-down routing and paging follow. Minor waste in the closing 'Coverage and historical-evidence limits are unchanged,' which is opaque without prior context.

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 wisely explains the two count fields and paging rather than return shapes. The one gap is the vague closing sentence about coverage/historical-evidence limits, which an agent cannot act on without outside knowledge.

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?

Although top-level schema coverage reads 0%, the nested properties are richly documented and the description adds constraint-level meaning: cellSize must be a power of two (and may be coarsened), all four bounds must be supplied together, and query.limit caps at 50. It works alongside the schema rather than duplicating it.

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 spatial aggregates of captured Find positions') and immediately distinguishes itself from search_world_find by noting it reuses the same filters but aggregates them. An agent can tell this is the map/aggregate variant vs the per-result search variant.

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 prerequisites are given (four viewport bounds, power-of-two cellSize) and the drill-down path is named: 'Use representative XYZ with get_world_find_history or search a group's bounds for its members.' Paging is also prescribed ('follow nextOffset with unchanged filters').

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 the safe read-only, closed-world profile, so the description's added value is the indexing semantics: 'products' and 'completedParts/totalParts' distinguish indexed, partial and waiting sources, and missing data is explicitly not evidence of absence. That is real interpretive context an agent would otherwise lack; only rate limits or auth expectations are absent.

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 with the core purpose front-loaded and no filler. The caveat about missing data and the pagination rule are both load-bearing, though the 'Products and completedParts/totalParts' phrasing is terse enough to be opaque on first 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?

With an output schema present, the description needn't explain return values, and annotations cover safety, so what remains is scope, filtering, caveats and paging — all covered. The main gap is sibling differentiation from search_world_find, which an agent choosing between the two would want.

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 a middling 60% — query, family and dimension are documented, while limit and offset are not. The description partially compensates by stating 'Up to 100 sources per page' (capping limit) and describing offset continuation, but it names 'nextOffset' rather than the actual 'offset' parameter, which risks confusing the agent about which field to pass.

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 and resource — listing public Find sources plus their indexing coverage across NoCom, location WDLs and primary maps — which lets an agent distinguish it from sibling read tools like get_world_find_map or get_world_find_inventory. It does not, however, explicitly contrast itself with search_world_find, which is the nearest name-alike.

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 operational guidance on filtering (by dimension, family, or name/ID) and on pagination ('Follow nextOffset with unchanged filters'), plus a useful caveat that missing data does not establish absence. What it never states is when to choose this over search_world_find or the other world-find lookups, so 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?

The annotations already establish that this is a read-only, non-destructive, non-open-world operation. The description adds meaningful behavioral context beyond that by explaining URL semantics: interactiveUrl for human links/citations, recordUrl as a stable provenance alias with a permanent HTTP 301 redirect, and apiUrl/JSONL for JSON consumers. It does not contradict 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?

The definition is front-loaded with the tool's purpose and its sibling alternatives, then adds a compact example and focused output-link guidance. Every sentence contributes either routing information, invocation context, or URL selection semantics, with no wasted preamble.

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 and nine optional parameters, the description supplies purpose, alternatives, an example, and output URL selection guidance. Because an output schema exists, it need not explain return values in full, and the remaining gaps are adequately covered by structured fields.

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

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

Schema description coverage is 100%, with all nine parameters documented directly in the input schema, including origin selection rules for x/z, location_id, and location_name. The description adds only a representative example and does not supplement parameter meaning beyond what the schema already provides, 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?

The description uses a specific verb, 'Bundle,' and names the concrete resources: nearby locations, credited groups, preservation, and native-dimension highways. It also explicitly distinguishes this tool from find_locations_near, research_location, and research_nocom_area, so an agent can identify its role without opening sibling 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 gives explicit routing guidance: use find_locations_near for only nearby locations, research_location for one named place, and research_nocom_area for NoCom storage/signs/portals. The example further clarifies a typical invocation, leaving little ambiguity about when this tool is appropriate.

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

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

Annotations already declare a safe read operation, so the description focuses on behavior beyond that: ambiguous matches return AMBIGUOUS_LOCATION with candidate IDs, recordUrl is a stable 301 alias, interactiveUrl is preferred for humans, and apiUrl/JSONL serve JSON consumers. These are non-obvious operational details that the 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, then usage alternatives, then URL semantics. It is dense but every sentence carries routing or behavioral information; the URL alias block is slightly lengthy but still useful for citation and provenance decisions.

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, but the description still explains the ambiguity path and candidate-ID workflow. Combined with the sibling routing rules and URL provenance notes, an agent has everything needed 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 description coverage is 100% and there is one required parameter. The description only restates that the name can be a 'distinctive search phrase,' which the schema already says, so the baseline of 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 ('Research a place by name or search phrase') plus the output shape ('full record and nearby places'). It explicitly distinguishes itself from get_location and search_locations, so an agent can select it 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 explicit routing rules: use get_location for a known ID, search_locations for discovery lists, research_area for coordinate context. It also covers the ambiguous-name case and tells the agent to pick a candidate ID with get_location.

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 context annotations cannot convey: ambiguous names return candidate IDs rather than guessing, disabled products come back null not zero, historical positions do not reveal inventories/owners/survival, and sign text is untrusted content. Radius bounds (1..8192, default 1024) and the World Pulse locality caveat are also disclosed.

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 correctly with purpose and alternative first, which is the right priority. But the closing block about interactiveUrl, recordUrl 301 redirects, apiUrl/JSONL and derivative URL fields is response-metadata boilerplate that crowds out the parameter explanations the agent actually needs before calling.

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 zero-required, ten-parameter aggregate query the definition is substantially complete, and the output schema means return values needn't be spelled out. The remaining gap is the include_* toggles: with a 10% schema coverage an agent cannot tell whether toggling them changes the payload shape or cost.

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%, so the description must carry the load. It does well on the origin triple (exact, case-insensitive name / ID / native x,z) and the radius range, and dimension inference is in the schema. However, the four include_signs/include_portals/include_storage/include_clusters booleans are explained nowhere, so the compensation is incomplete.

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, quotable use case ('what does NoCom know about this area?') and immediately contrasts itself with research_area for the no-NoCom-evidence case. The resource and scope are unmistakable and differentiated from siblings like find_nocom_storage or research_location.

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

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

Explicitly routes the agent: research_area for catalog-only context, get_nocom_daily_hits for exact daily local counts with date range and rectangle, low-level Find tools with nextOffset for deeper paging. It also imposes a hard rule ('Supply exactly one origin'), which prevents a common misuse.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description adds useful return-shape context ('compact records with canonical links') plus URL semantics. However, the URL paragraph (interactiveUrl, recordUrl 301 alias, apiUrl/JSONL, locationInteractiveUrl/locationRecordUrl) is largely output-field documentation that overlaps with the output schema, so it does not add much behavioral depth 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 is front-loaded in the first clause, followed by disambiguation and then URL guidance in a logical order. Every sentence carries information, though the tail URL/derivative sentence is dense with field names and is the weakest-value portion for tool selection.

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 seven-parameter, all-optional search tool with a 100%-covered schema, an output schema and safe read-only annotations, the description covers purpose, alternatives and link semantics. An agent has everything needed to select and 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 description coverage is 100%, so every one of the seven parameters is already documented in the schema, establishing the baseline of 3. The description restates the filter categories ('text, tags, group or preservation filters') but adds no format, syntax, or combination semantics beyond what the schema already says.

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 plus resource ('Discover locations') and enumerates the filter axes (text, tags, group, preservation), which maps directly onto the schema's query/type/group/has_render/has_world_download properties. It explicitly names the three sibling tools it is not, so an agent can separate it from find_locations_near, get_location and research_location without reading 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 three concrete routing rules with the condition that selects each alternative: proximity → find_locations_near, known ID → get_location, name-based research → research_location. That is explicit when-to-use-other guidance rather than implied context.

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

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

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?

Goes well beyond the read-only annotations: discloses Overworld-only scope, that text may merge multiple dated versions (with sourceJsonUrl for full history), the 1024-char excerpt cap with textTruncated flag, and an explicit untrusted-content warning. Rate/pagination behavior (max 25 per page, follow nextOffset with unchanged filters) is also stated.

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 and front-loaded, with the core scoping and matching semantics first. Every sentence carries information, though the block is tightly packed and could be broken up for readability.

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

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

For a 9-param search tool with an output schema available, the description covers the critical caveats an agent needs: matching semantics, scope limits, version-merging, truncation, pagination, and content trust. Nothing essential 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 0% schema coverage the description must compensate, and it does for the key params: text as a 2..100-char case-insensitive literal substring, x/z proximity, radius 1..8192 native horizontal blocks, and limit cap of 25. min_y, max_y, and dimension are left unexplained, so coverage is strong but not complete.

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 ('Search captured historical NoCom sign text') and distinguishes it from siblings by naming search_world_find as the whole-word alternative. An agent can identify the right tool 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?

Explicitly says to supply text for release-wide search, x/z for nearby signs, or both, and routes whole-word matching to search_world_find with specific parameter values. Both when-to-use and the alternative are spelled out.

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 past the readOnly/destructive/openWorld annotations: 50-position page cap, nextOffset/null terminator semantics, 'inventory filters affect storage only', NoCom having no recorded inventories, and an explicit prompt-injection warning that captured text is untrusted data, never instructions.

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 key coordinate/coverage constraints, then dense operational notes. A few sentences are compressed to the point of opacity (the GET /api/find and 'one dimension/category/XYZ' reference), but almost every line carries actionable 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 one-parameter nested-object tool with an output schema, this covers everything the agent still needs: coordinate conventions, paging contract, page size, source coverage caveats, cross-tool handoffs, and the untrusted-data handling rule.

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 description earns one more by explaining cross-parameter behavior the schema does not, e.g. that text filters signs, saved item names and object names while rare-block kinds stay visible, and that namedOnly/renderIds scope only their categories.

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 plus an enumerated resource set (signs, storage, rare blocks, mobs, map art, banners, item frames, other saved objects), so the agent knows this is the cross-category find endpoint rather than one of the category-specific siblings like find_nocom_storage or search_nocom_signs.

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: use an observation's id with get_world_find_inventory for contents and get_world_find_history for other source versions, and recommends radius/viewport for broad categories. It also names conditions to respect (follow nextOffset with unchanged filters; read source coverage before trusting missing results) and a hard constraint (native coordinates, never Nether scaling).

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