gps_jamming

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

With no annotations, the description carries the full burden and does substantial work: it discloses the underlying detection method, that results are aggregated into 1° cells, and the shape of what comes back (ranked flagged cells, severity counts, sample aircraft). It does not state read-only/safety posture, data freshness or latency, or coverage caveats of the GPSJam method, which keeps 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?

Dense and front-loaded: method and output content come first, scoping rules last, with no filler sentences. Parenthetical method detail is information-bearing rather than noise.

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?

An output schema exists, so return values needn't be spelled out, and the mutation/safety story is implicitly absent because this is an assessment read. However, for an 8-parameter tool with zero schema description coverage and no annotations, the description leaves an agent unable to set `detail` or understand radius semantics, which is a material 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 description coverage is 0% across 8 parameters, so the description must compensate and only partly does — it explains the centre (lat/lon) versus bbox (min/max lat/lon) choice. It never explains the `detail` string parameter (no enum, default "short", allowed values unknown), the default radius_nm=500 or how it interacts with a centre, or whether a centre requires a 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 (GPS/GNSS jamming assessment) and names the exact detection method (ADS-B NACp<8 / NIC<7 binned into 1° cells), so an agent knows precisely what analysis produces the result. It also enumerates the return content (flagged cells ranked by severity, high/medium counts, sample aircraft), which distinguishes it from general siblings like anomalies or aircraft_density.

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 final clause gives explicit branching on scope: omit all coordinates for a global view, or pass a centre or a bbox to scope it. That is genuine usage context, but it is about parameterization rather than tool selection — nothing says when to prefer this over anomalies, aircraft_density, or aviation_sigmet, and no exclusions or prerequisites are stated.

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