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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), and the description adds genuinely non-obvious behavior: the Camp Map Pass key auth requirement, a hard 10-per-day rate limit, and a 'no free text' constraint. It stops short of saying what success/failure looks like or whether the report appears immediately.

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?

A single dense sentence that front-loads the core action, then the accepted values, then authorization and rate constraints. No filler, though the parenthetical enum dump is long and largely duplicative of the schema.

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 4-param mutation tool with no output schema, the description covers the essentials: what is stored, what inputs are valid, who can call it, and how often. The only gap is the return behavior/confirmation, which is minor given the low complexity.

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 50%: lat/lng carry their own WGS84 descriptions, while kind and vehicle rely on enums that are already fully self-documenting. The description reproduces the enum values rather than adding meaning, so it neither compensates for nor improves on the schema beyond confirming that only fixed kinds/vehicles are accepted.

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 states a specific verb and resource ('Stores a one-tap field report at a point') and clarifies scope ('the same kind the map's users leave'). It is clearly distinct from read-oriented siblings like road_reports and find_spots, though it never names an alternative outright.

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?

Usage context is implied through prerequisites ('Needs the user's Camp Map Pass key') and limits ('at most 10 stored reports a day per key'), but there is no explicit when-to-use this versus check_spot, confirm_spot, or road_reports. The agent must infer that this is the write path for leaving a report.

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