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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description usefully spends its words on return content instead: each sensor comes with its latest reading plus a quality check consisting of status, a 0–10 rating for the last checked day, and a 7-day mean with reasons. That clarifies semantics of the output, which matters because no output schema exists. Pagination behavior (20 default, 100 max) is left to the schema.

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 zero filler; the payload (what you get back) is front-loaded before the filter and sort options. The colon-chained clauses make it dense but not 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?

For an 11-parameter discovery tool with no output schema, the description correctly covers the return shape and the main geo/text filters. It falls short on the network filter semantics and pagination, both of which an agent needs to build a correct query.

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 45%, so the description should carry more weight. It adds real meaning for city/country/point-radius and min_rating (rating of the last checked day), but says nothing about the network enum values (sensor_community, airgradient, atmy, government) or page/limit, leaving several parameters documented only by bare enum lists.

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 a specific resource (single sensors), enumerates the measurements returned (PM1, PM2.5, PM10, temperature, humidity, pressure), and says it adds network plus quality-status data. That is enough to separate it from get_sensor (one sensor by id), get_sensor_readings (time series), and get_sensors_average (aggregates), but it never explicitly names those 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?

It gives practical filtering options (city, country, or point with radius) and explains that sort=rating surfaces the most reliable sensors first, which implies when to use it. It never states when to prefer get_sensor, get_sensors_average, or get_air_quality instead, so the routing decision 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.