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

Goes well beyond the annotations: it details the idempotency key semantics (unique requestId, reuse on retry, rejection of reused IDs with different input), the auth requirement (Gillby account plus explicit account consent), and that the response carries source/freshness metadata. The annotations only say idempotentHint and the safety flags, so this adds real behavioral context.

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?

Three short paragraphs, front-loaded with the core action and the two input modes before tactical detail (requestId, auth) and the units/return note. Efficient overall; the 'Units' line is somewhat API-wide boilerplate rather than tool-specific, a minor dilution rather than real waste.

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 write tool with a nested object parameter, no output schema, and no per-field schema descriptions, it covers the essentials: what is saved, idempotency/auth behavior, and that source/freshness metadata is returned. The only gap is the handful of unmentioned nested fields (kind, sort, notes, boatId).

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%, so the description must carry parameter meaning. It names the important place fields (name, lat, lon, activity, spotId) and explains requestId's retry semantics, compensating for most of the gap, though it omits kind, sort, notes, and boatId that appear in the schema.

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 (save) and resource (a named map pin or a catalog favorite), and distinguishes the two input modes with their key fields (name/lat/lon/activity vs spotId). An agent can tell this is the create operation apart from siblings like update_my_place, delete_my_place, and save_my_trip without opening the schema.

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 clear context for use: the two save modes, the retry contract (reuse requestId), and the downstream consumer ('Saved coordinates can be used with get_point_conditions'). It stops short of explicit when-not-to-use or naming the update/delete siblings, so it is clear context without exclusions.

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