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

With no annotations, the description carries the full behavioral burden. It discloses that this is a read/fetch operation and that the response is WKT geometry, but says nothing about permissions, error behavior for unknown IDs, or whether it returns one or many geometries.

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 concise sentences, front-loaded with the action and output format, followed by a tightly scoped usage condition and example. Every 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?

For a simple two-parameter read tool with no output schema and no annotations, the description adequately covers what it returns (WKT geometry) and when to use it. Minor gaps remain around where IDs come from and error handling, but the core invocation context is present.

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 50%: the 'scr' parameter is documented in the schema, while 'ids' is undocumented there. The description adds 'by id' and clarifies the fetched result is exact geometry, but does not explain the ID source or relationship to the SCR document.

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 the exact geometry of features by id') and adds the output format ('as WKT'). It also implicitly distinguishes itself from map-display siblings by saying to use it only when shape matters, so an agent can select it 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?

Gives explicit usage guidance with 'Use only when shape matters' and a concrete example ('checking whether a route clears a building'). It does not name the alternative tool to use for non-shape queries, so it stops short of fully explicit 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?

No annotations, so the description carries the burden. It discloses the shape of the return conceptually (categorical twilight states rather than a boolean) and explains why, which is genuinely useful, but it says nothing about whether times are returned as instants vs. local strings, what 'sun position' looks like numerically, or any rate/permission constraints. Read-only is inferable only from the 'get_' name.

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

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

Two sentences, front-loaded with the returned quantities, then a short design note that prevents a wrong expectation (boolean vs. four-state twilight). Nothing is padded.

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

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

With no output schema and no annotations, the description does well to enumerate the returned quantities, but an agent still cannot predict the serialized form — time format of sunrise/sunset, units for sun position, or field names. For a 3-parameter lookup returning multiple values, that is a real 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 33% — only 'at' is documented in the schema. The description adds only 'for a coordinate', which maps lat/lon to location but gives no sign convention, unit, or precision guidance, and never mentions the optional 'at' override or UTC/Earth-time handling.

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 concrete resource ('sun position, sunrise, sunset, and twilight state') with its required input ('for a coordinate'), which makes it unmistakable against siblings like get_weather and get_terrain. The clarifying note about how twilight is reported reinforces exactly what this tool returns.

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

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

Usage is only implied: 'for a coordinate' and the twilight rationale hint at daylight/visibility decisions, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., get_weather for cloud cover that would make twilight moot).

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

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

With no annotations, the description carries the burden and does well: it discloses that output is token-budgeted, that results form a topological graph, and that omissions are reported so missing features should be treated as not-shown rather than absent. It does not explicitly state read-only/no side effects, but 'Fetch' strongly implies it.

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, front-loaded with the core action and output shape, then use cases, then an important caveat about omissions. Every sentence earns its place without redundancy.

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

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

For a six-parameter graph-fetch tool with no output schema and no annotations, the description explains the returned graph, edge attributes, token budgeting, and omission semantics. It could say more about response structure or layer effects, but what is present is sufficient for an agent to understand the call's result and caveats.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters in detail, including defaults, token cap, layers, radius, and returnScr. The description mentions token budgeting but does not add parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description gives a specific verb and resource: fetch real map data around a coordinate and return a token-budgeted topological graph. It clearly states the key output elements, named places joined by walkable edges with distances and directions, but does not explicitly distinguish this from siblings such as route or search_places.

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 use cases: answering 'what is near X' and 'how do I get from A to B'. However, it provides no when-not-to-use guidance and does not name alternatives like route or search_places, leaving the sibling routing overlap unresolved.

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

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

With no annotations, the description carries the full burden; it does disclose units (metres), the sampling concept, and the return shape (range plus high/low points). It omits important behavioral caveats such as data resolution/accuracy, cost or rate limits, and behavior when the coordinate falls outside coverage.

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 tight sentences with no filler; the core action and result are front-loaded in the first clause. Every 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?

There is no output schema, and the description gives only a one-line sketch of the return values, which is roughly adequate. However, for a four-parameter geo tool with zero schema descriptions, the missing parameter and data-quality detail leaves the definition only minimally complete.

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

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

Schema coverage is 0% for four parameters, so the description must compensate. It vaguely gestures at a 'coordinate' and sampling 'around' it, but never names lat/lon, never explains that radiusM is in metres with a 1000 m default, and says nothing about the 'samples' count or its default of 16 — 'in metres' is even ambiguous between elevation and radius.

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 ('Sample ground elevation around a coordinate') plus the output shape (range, high and low points). It is clearly distinct from siblings like route, get_weather, or get_daylight, though it never explicitly contrasts with them.

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

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

The phrase 'which is what an agent needs for grade reasoning' implies the intended use case, but there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives for elevation-adjacent needs. Usage is inferable 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?

With no annotations, the description carries the full burden. It usefully discloses the character of the data ('reports what is actually falling... rather than only a temperature'), but says nothing about permission needs, units, failure modes, or what the response contains.

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: purpose front-loaded, then usage trigger, then a differentiator. No filler, and each sentence adds a distinct piece of 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 3-parameter, no-annotation, no-output-schema tool, the description covers purpose and usage but leaves coordinate units, forecast horizon, and returned data shape unaddressed. Adequate to select the tool, thin for calling it precisely.

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 33%, so the description should compensate but mostly doesn't. 'At a coordinate' implies lat/lon without specifying units or format, and it never mentions the hours horizon parameter, whose default/max is only documented inside 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 gives a specific verb+resource+scope: current conditions and a short forecast at a coordinate. It is clearly distinct from terrain or daylight siblings by domain, but it never names or contrasts a sibling explicitly, so it stops short of the top score.

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 concrete triggering situations (before recommending walk/cycle/drive, or choosing indoor vs outdoor), which is clearer than typical implied usage. It offers no when-not guidance and does not point to an alternative tool for other weather needs.

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

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

With no annotations, the description carries the full burden and does well: it discloses the state-mutation lifecycle (store the updated SCR from the second content block, discard the old one) and the return semantics (delta only: + entered, - left, ~ moved/updated). It does not cover error behavior or what happens if the SCR is stale, keeping 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?

Three tight sentences, front-loaded with the core action and ending with the critical state-maintenance instruction. Every clause carries operational value with 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?

It compensates for the missing output schema by explaining the delta return format and the two-content-block structure, and covers the important stateful behavior. Minor gap: the optional budget/layers/radiusM parameters are not mentioned, though the schema documents them fully.

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 lat/lon, scr, budget, layers, and radiusM. The description adds a little beyond the schema by emphasizing the SCR rotation rule, but adds no syntax or format detail for the geographic or budget parameters; 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?

States a specific verb+resource ('Move within a map session') and distinguishes it from get_maplet by describing it as motion inside an existing session. An agent can tell it apart from the session-creating sibling 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 frames it as operating on a session 'you already hold' and names where the SCR comes from (get_maplet with returnScr, or the last localize), which implies the correct sequencing. It stops short of explicitly saying not to use this for an initial fetch or how it differs from route, but the prerequisite is clear.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: the default answer appends a 'verify the approach on arrival' caveat, and no turn-by-turn data is computed. However, it says nothing about units, coordinate ordering assumptions, error behavior, or what the 'mode' parameter actually changes if distance is straight-line.

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 capability is front-loaded in the first clause, which is good, but the second half is editorial prose that restates the same disclaimer about turn-by-turn navigation twice. It is not bloated enough to bury the point, but sentences could be tightened.

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

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

With no annotations and no output schema, the description is the only source of truth, and it does convey the substance of the return (distance, direction, a caveat string). It still leaves gaps an agent needs for correct invocation: units, response format, and the effect of mode.

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 five parameters, so the description must compensate. It only implies that fromLat/fromLon and toLat/toLon form the two coordinate pairs; it never explains units, precision, ordering, or the role of the walk/bike/drive enum, which is left entirely opaque.

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 concrete output set: straight-line distance and compass bearing between two coordinates. It sharply disambiguates itself from a true routing engine by denying turn-by-turn capability, so an agent knows exactly what it will and will not get. It does not distinguish itself from any sibling tool by name, which keeps it below a 5.

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

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

Usage is implied rather than stated: the word 'Feasibility' and the denial of turn-by-turn suggest a quick sanity check, not navigation. There is no explicit 'use this when…, use X instead' guidance, and no sibling (get_maplet, localize, search_places) is named as an alternative.

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

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

With no annotations, the description must carry the behavioral burden; it does disclose the cost tradeoff versus get_maplet, which is genuinely useful. It says nothing about return shape (names only, or with type/distance?), result ordering, or how radius/limit affect recall, so an agent cannot predict output.

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 tight sentences, zero filler, with the core purpose front-loaded and the sibling comparison as a secondary clause. Every phrase 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 5-parameter tool with no annotations and no output schema, the description covers purpose and the sibling tradeoff but leaves output content and the radius/limit behavior unexplained. Adequate to call the tool, not adequate to predict what comes back.

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% — just the `query` property is documented — and the description does not compensate. It never mentions that limit defaults to 20 or that radiusM defaults to 300m, a value that materially constrains results; only lat/lon are implied by "near a coordinate".

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?

Specific verb (Find) plus resource (named places) with concrete examples and a spatial scope (near a coordinate). It also explicitly distinguishes itself from get_maplet, so an agent can pick between them 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?

"Cheaper than get_maplet when only names are needed" names the alternative and the condition that selects it, implying get_maplet is for richer detail. It gives no guidance on the other siblings (route, localize, expand_feature), but the core routing decision is covered.

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