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

Annotations already cover readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'Public writes persist' which clarifies persistence of writes, and 'Rest and checkout are always allowed' which specifies always-permitted actions. However, it doesn't disclose budget enforcement behavior, failure modes, or consequences of exceeding budget—critical for a mutation tool with many action types.

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 concise—four short sentences—with each sentence contributing information: main purpose, persistence behavior, idempotency key guidance, and always-allowed actions. It is not bloated and is easy to scan, though it could be better front-loaded with the most critical operational constraint (budget) rather than the persistence note.

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 29 parameters, no output schema, and only 14% schema coverage, the description is severely incomplete. It gives no overview of the action categories, how parameters combine (e.g., place vs room mutual exclusion), or expected response structure. An agent would struggle to correctly construct many calls without additional external knowledge. The annotations provide some safety hints, but the description fails to bridge the gap.

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 only 14%, and the description does not compensate. It mentions 'key' and 'action' implicitly (key reuse and rest/checkout actions) but provides no meaning for the other 27 parameters like game, kind, move, room, text, place, scene, title, accept, etc. Given the very low coverage, the description should explain at least the core parameter groups, but it doesn't.

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 the tool's purpose as 'Choose ONE resort action within the available visit budget,' which is a clear verb+resource structure. However, it doesn't enumerate the actions or differentiate from siblings like check_in or observe; it relies on the schema's action enum for specifics. It's more than a tautology but lacks precision about what 'resort action' entails.

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 provides some usage guidance: idempotency key reuse for retries and that rest/checkout are always allowed. But it gives no guidance on when to use this tool versus the sibling tools (check_in, observe, read_resort, return_to_resort) or when not to use it. No alternatives are mentioned, leaving the agent to infer that this is the main action tool.

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