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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds substantial behavior beyond that: the API returns 422 if geometry is omitted for raster tile sets, the geometry is required to scope pixel queries, and a BYO API key is mandatory. These are critical runtime behaviors not captured by annotations, justifying a score above the baseline.

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 three sentences of dense, essential information. The purpose is front-loaded, the geometry requirement is placed prominently, and every clause earns its place: no filler, no repetition of schema content. The length is appropriate given the tool's complexity.

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 a tool with no output schema, the description adequately conveys expected results through examples (hectares by year, alerts in a bounding box) and warns of the 422 failure mode. It covers the key pitfalls (table name, geometry, API key) and prerequisites (gfw_dataset). It could explicitly state the return format or pagination, but this is a minor gap given the query context and the schema's limit parameter.

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 description adds value by clarifying the table is always called `data` (redundant with schema but reinforces), and—more importantly—explains the geometry parameter's requirement for most datasets, including the exact consequence (422) and the exception for vector tables. This goes beyond the schema's generic description of geometry as a GeoJSON polygon.

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 opens with a clear, specific verb–resource pair: 'Run a read-only SQL SELECT against one Global Forest Watch dataset version,' then gives concrete examples (tree cover loss hectares, deforestation alerts) and names the table `data`. It also implicitly differentiates from gfw_dataset by instructing the agent to use that tool for columns, so siblings are distinguishable.

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 actionable context: 'use gfw_dataset to see the available columns first' and explains when geometry is required (raster tile sets) versus when to omit it (vector tables like wdpa_protected_areas). It does not explicitly enumerate alternative tools, but the pruning of `gfw_dataset` as a prerequisite and the raster/vector guidance are sufficient for correct selection. Exclusions are clear but not exhaustive (e.g., no mention of `gfw_datasets` for listing datasets).

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