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

With no annotations, the description carries the full burden; it usefully discloses that no payment or unlock_token is needed, that 409 occurs during pending_payment, and that answer bodies aren't sent to callback_url. It omits auth requirements, idempotency/re-submission behavior, and what happens to ask state, leaving meaningful behavioral gaps.

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 short and front-loads the action, but it opens with the opaque "Hold/relay step 4", and the trailing pricing fragments ("Poll unlock $1. Asker posts $1–$5. Reader unlock $1. Answers are free.") partly duplicate "No payment" and read as protocol chatter rather than guidance for this call.

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 and no annotations, so the description must cover both behavior and inputs, yet it leaves all five parameters undocumented and omits auth and repeat-submission behavior. Only the error/precondition side is addressed; for a 5-param tool this is substantially incomplete.

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?

Five parameters with 0% schema description coverage, and the description explains none of them — not body, ask_id, source, confidence, or source_note. The agent gets no semantic guidance for any input beyond what the bare type/enum declarations show.

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?

"Submit a free answer to an open ask" is a clear verb+resource, but the leading fragment "Hold/relay step 4" is cryptic without external context and the description never distinguishes this from the sibling submit_answer, so an agent can't confidently route between the two.

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 gives real preconditions: call after unlock.completed, and HTTP 409 while the ask is pending_payment. It states the free/no-token condition clearly but never names submit_answer as the alternative for the different workflow, so routing guidance is incomplete rather than absent.

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