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

Annotations only cover the mutation/safety profile (readOnly=false, idempotent=false, openWorld=true). The description adds real behavioral detail beyond them: a 3-attempt cap, feedback returned on failed attempts, zero reward for repeating a passed submission, and the reward/badge thresholds. It stops short of describing auth or state persistence across the stay.

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, but front-loaded with the core transformation and scoping constraint before the reward mechanics. Every clause carries information; it is heavy but not padded.

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?

An output schema exists, so return values need not be re-explained, and the description covers the attempt limit, failure feedback, and reward/badge thresholds. It is nearly complete, missing only explicit guidance on when this activity is the right choice versus siblings.

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 0%, so the description must carry the load, and it does partially: it identifies stay_id as a UUID and response as a string whose content must contain Goal: and Format: fields. It also supplies an effective 40–500 character rule that is tighter than the schema's minLength 1 / maxLength 500, which is genuinely additive.

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 transformation target: turn a vague request into explicit 'Goal:' and 'Format:' fields, with a 40–500 character bound. That is concrete enough to distinguish it from the other resort_* activities, though it never explicitly contrasts itself with siblings like resort_poolside_pitch or resort_sunset_roast.

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 is implied rather than stated: the description says what activity this completes and that 'up to 3 attempts are allowed,' which tells an agent it can retry. But it names no alternatives and gives no explicit when-to-use vs when-not-to-use conditions beyond 'passed repeats award zero.'

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