MET: luftkvalitetsvarsel for et punkt

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

With no annotations provided, the description carries the full burden and discloses important behavioral traits: the data is modeled per grunnkrets, not measured on-site, and the source and license are stated. It does not mention auth or rate limits, but for a read-only data lookup and with the modeled-vs-measured caveat explicitly disclosed, this is solid 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?

The description is concise and front-loaded with the core output details, followed by the important modeling caveat and source/license information. Each sentence provides useful context; the license line is slightly auxiliary but contributes to data provenance transparency.

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 adequately explains the return content: index, health risk text, pollutant concentrations, and source contributions. It also covers the time range and the modeled nature of the data. Minor gaps like units or coordinate reference system are not critical for invoking 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?

Schema description coverage is low (33%) since lat and lon lack descriptions, but the description says 'for koordinater', making their role clear. It also mentions 'opptil 56 timer', reinforcing the timer parameter's meaning which the schema already explains. The description adds some context but does not fully compensate for the undocumented lat/lon format details.

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 what the tool does: provides hourly air quality (up to 56 hours) for a coordinate, including a combined health-risk index, specific pollutant concentrations (NO2, PM10, PM2.5, ozone), and source attribution. This is specific and distinct from sibling tools like met_varsel, met_farevarsel, and met_sol_og_mane, which cover weather forecasts, warnings, and sun/moon data respectively.

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: air quality at a point, with a notable caveat that data is modeled per statistical unit, not measured at the address. It does not explicitly name alternatives or state when not to use it, but the domain and limitations are clear enough for an agent to select it appropriately among the MET tools.

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