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

With no annotations, the description carries the full behavioral burden and discloses important effects: withdraw returns the raffle to draft while preserving prizes/inventory/check-in only under stated conditions, complete publishes the seed and permanently ends the raffle, and preview uses previewHash plus consent. It still omits validation/error behavior and any rate-limit or failure-mode details.

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 compact and front-loads the action semantics, then preview/retry rules, then action-specific requirements. The semicolon-separated fragments make it dense and somewhat hard to parse, but there is little wasted text.

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 12-parameter lifecycle tool with no annotations and no output schema, it covers most action semantics and the preview workflow. However, it omits the action-to-parameter mapping for cases such as review deciding approve/reject, and it does not explain reason or expected return/error behavior, leaving meaningful gaps for an agent to infer.

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?

At 0% schema description coverage, the description explains many key parameters and actions: prizeId for draw, drawId for review, previewHash/consent/preview for the preview flow, requestId for retries, evidenceReviewedByUser for review, and claimCode for claim. It leaves decision (approve/reject), reason, activityRef, and action-specific required parameter mappings unexplained.

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 names the raffle lifecycle actions (open/withdraw/lock/draw/review/claim/complete) and the organizer/login context, so the tool's purpose is clear. It does not explicitly distinguish this lifecycle tool from siblings such as configure_activity_raffle and get_activity_raffle, though the action list implies the difference.

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?

It provides concrete usage rules: organizer/login, preview first with the same parameters plus previewHash, consent=true and preview=false, preserve requestId on retries, review only after user evidence, and claimCode supplied by the user. It also gives a specific precondition for withdraw (no participants and unlocked), but it does not explicitly name alternatives for configuration or read-only workflows.

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