Live weather and air quality (GAIA)

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond the annotations: provenance (Copernicus CAMS via Open-Meteo) and the existence of a 'signed receipt', which hints at verifiability behavior an agent would not otherwise know.

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: the first front-loads what is returned and from where, the second front-loads how to call it. No filler, no repetition of the schema or the title.

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, the description carries the burden of describing returns and does so by listing the metric set and units. Minor gaps remain: what the 'signed receipt' contains and how partial/average values are handled, but nothing essential to a correct call is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds a semantic fact the schema does not express: coordinates and city are alternative modes ('latitude and longitude, or a city'), clarifying the either/or intent of three zero-required 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?

States a specific verb+resource ('Current air quality at a place') and enumerates the actual returned metrics (PM2.5, PM10, US/European AQI) plus the data source, so an agent knows exactly what it gets. It does not explicitly differentiate itself from nearby_sensors or weather_now, which keeps it out of 5 territory.

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 closing sentence conveys the input mode ('Send latitude and longitude, or a city'), which is useful invocation guidance, but nothing states when to prefer this tool over nearby_sensors or weather_now, and no exclusions or prerequisites are given. Usage is implied by the air-quality domain rather than made explicit.

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 carry the read-only, idempotent, open-world, non-destructive profile, so the bar is lower; the description still adds real value by disclosing that results are live and public, one per requested layer, and include a signed receipt plus source. It omits edge behavior such as what happens when nothing lies within max_km or whether any auth/quota applies.

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?

A single dense sentence that front-loads the core purpose and packs the return payload into the same clause. No wasted sentences, though the trailing 'and a signed receipt' reads as slightly bolted on.

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, the description usefully describes the response shape (reading, distance, source, receipt), and annotations cover the safety profile. It is close to complete, but gaps remain on no-match behavior and any auth/rate constraints.

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

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

Schema description coverage is 100%, so every parameter including layers and max_km is already documented in the schema. The description restates the layer concept ('one per layer asked for') without adding format or default detail beyond what the schema gives.

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 (nearest live public sensors to a point) plus the scoping rule 'one per layer asked for' and the returned fields (reading, distance, source, signed receipt). It implicitly differentiates from the single-layer siblings air_quality_now/weather_now by being multi-layer, but never names them, so it stops short of a 5.

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

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

The multi-layer framing implies you reach for this when you want several sensor types at once, but there is no explicit when-to-use, no when-not, and no reference to the sibling tools it overlaps with. 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?

Annotations already carry readOnly/idempotent/openWorld, so the description correctly focuses on traits annotations cannot express: the 75 km coverage radius, the 'nearest live relay' sourcing, and a signed receipt for provenance. It stops short of saying what happens when no relay falls within 75 km, which is the one behavioral edge case that matters here.

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?

A single dense sentence front-loads the resource and its returned fields, then closes with the input form. No filler, no restatement of the title.

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, the description does the right thing by enumerating the returned measurements and units. The remaining gap is failure/coverage behavior — no indication of the response when no relay is within 75 km or when a city name is ambiguous.

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 baseline is 3. The sentence 'Send latitude and longitude, or a city' hints at the coordinate/city alternative, but it does not state that the two modes are mutually exclusive or which takes precedence if both are passed, and all three parameters are optional in 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 resource (current weather) and enumerates the exact quantities returned with units (temperature °C, humidity %, pressure hPa, wind m/s), plus the data source (Open-Meteo relay). It distinguishes itself from air_quality_now by domain but never names the sibling, so the differentiation is implicit rather than explicit.

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

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

The description only tells the agent how to supply input ('Send latitude and longitude, or a city') — that is parameter syntax, not usage guidance. There is no statement of when to prefer this over air_quality_now or nearby_sensors, and no exclusions or prerequisites.

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