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

With no annotations, the description carries the full burden and does so: it discloses quota consumption ('one quota unit per parcel found, 0 to 3'), partial-failure semantics (a not-found parcel returns an error but the others are still compared), per-country field coverage (area/land use/municipality only for Spain), and an explicit data exclusion ('No market prices'). These are exactly the behavioral facts an agent cannot get from 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?

Purpose is front-loaded in the first clause, followed by a tight sequence of caveats, each of which earns its place. Slightly dense as a single run-on block of constraints, and the cost note (a decision-relevant fact) sits last rather than earlier.

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 comparison tool with no output schema and no annotations, the description covers geography, field availability, cost, and error behavior. The remaining gap is the shape of the comparison result (how each parcel's row is keyed/labeled), which the agent must infer.

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 100% and the single parameter's shape (array of 2-3 objects with country enum and reference) is fully documented in the schema itself. The description restates '2 or 3 parcels' and the supported country list, which duplicates minItems/maxItems and the enum rather than adding new semantics.

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 ('Compare 2 or 3 parcels side by side') and enumerates the compared dimensions: location, solar potential, agricultural use, investment score. It is clearly distinct from the single-parcel siblings (get_parcel, get_solar_potential, etc.), which it implicitly contrasts by being the multi-parcel aggregate.

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?

Gives explicit when-to-use context (2-3 parcels, cross-country) and an exclusion: the Basque Country and Navarre are not supported, and it routes to 'the single-parcel tools'. The routing is slightly vague since the sibling set contains several single-parcel tools, but the condition that triggers the alternative is stated.

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