air_quality_nowCurrent air quality at a place: PM2.5 and PM10 (µg/m³), US and European AQI, from Copernicus CAMS via Open-Meteo, with a signed receipt. Send latitude and longitude, or a city.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | A city instead of coordinates, e.g. Tokyo | |
| latitude | No | Latitude in degrees | |
| longitude | No | Longitude in degrees |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.