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

Annotations only declare the safety profile (not read-only, not idempotent, not destructive, closed-world). The description adds real behavioral context beyond that: reports carry no personal details and a human at Fantasize reads every report, telling the agent the submission is human-reviewed and privacy-safe. It does not describe what response or confirmation comes back.

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 verb and the scope lead, the enum-to-meaning list follows, and the param guidance and privacy note close it out. It is dense but every clause carries information (category definitions, param conditions, human review). Slightly long for a single run-on sentence but no filler.

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?

No output schema exists, and none is strictly needed for a fire-and-forget report, but the description covers submission categories, required context, privacy, and the review pipeline. The only gap is what the agent should expect after calling (confirmation, no return value), which is minor.

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?

With only 50% schema description coverage, the description compensates well: it maps nearly every enum value of 'kind' to a plain-language meaning and explains when to populate sailing_id versus the nested search object. Only the 'other' enum value and the detail field's expected content are left implicit.

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+resource (report a problem found while using these tools) and enumerates the exact problem kinds, which separates it cleanly from the read-only search/inspection siblings. An agent knows immediately this is the feedback channel, not a lookup tool.

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 tells the agent when to use each kind (wrong price vs unbookable sailing vs broken link vs irrelevant results) and gives conditional guidance: include sailing_id when it concerns one sailing, the search arguments when it concerns results. It does not state exclusions or alternatives, but the enumerated categories make the trigger conditions unambiguous.

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