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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add planning behavior: it discloses how the route is computed (vehicle profile, departure time, max driving, lunch, breaks) and what comes back (real road detour, arrival time, season status, alternatives, per-campsite URL). No auth or rate-limit notes, but nothing contradicts the annotations.

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?

Four sentences, front-loaded with purpose then usage triggers, then computation, then return shape. Dense but every sentence carries information; the only mild bloat is the final URL sentence, which is still useful for the agent to know what it gets.

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 15-parameter tool with no output schema, the description does the important extra work of describing the return payload (count, fields, itinerary with alternatives). What remains uncovered (error behavior for unrecognized origins) is handled in the schema's parameter descriptions, so the description is close to complete.

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% with self-documenting parameters, defaults and enums, so the schema carries the semantics and baseline 3 applies. The description adds a little meaning by framing which inputs drive the calculation (vehicle profile, hora_salida, max driving, comida, descansos), but it does not explain interactions such as max_km vs max_conduccion_h beyond what the schema already states.

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 ('Planifica dónde dormir en un viaje por carretera') and enumerates the concrete outputs: 8-12 campsites reachable at a given hour plus a nightly itinerary with alternatives. This is far more specific than the sibling campings_en_ruta, though the sibling is never named explicitly.

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 trigger conditions with example user phrasings ('dónde hacer noche', 'en cuántas etapas', 'cómo repartir un trayecto largo'), which is strong when-to-use guidance. It stops short of stating when NOT to use it or explicitly routing to campings_en_ruta for simpler lookups.

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