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

Annotations already declare write and open-world behavior, so the description focuses on consequences instead: the submission is stored as a proposal for human review only and no work is accepted, scheduled or paid. That is exactly the outcome semantics an agent needs before writing. It omits what the call returns and how to track the request afterward, and idempotency is only covered by the annotation, not the text.

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?

Two sentences, front-loaded with the action and followed by the most important constraint (review-only, no commitment). No filler, no restatement of the title, every clause earns its place.

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?

Handles the 'what happens' question well but leaves the operational loop unfinished: there is no output schema and the description never says a request identifier or pending status comes back, nor points to get_capability_request_status or wait_for_reply. For a 23-parameter submission tool with only two required fields, the agent would want guidance on minimum viable payload (objective or problem_statement) — that is absent.

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 23 parameters and 13% schema description coverage, the description is expected to carry parameter meaning, yet it addresses only category_hint (optional, any value accepted, unknown values reviewed). The core inputs — objective vs problem_statement, conversation_id, client_request_id, budget, confidentiality_preference — get nothing beyond the schema. One of twenty-three parameters explained is far too thin for a low-coverage schema.

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?

Opens with a concrete verb and object: submits an open-ended description of something a human should do, observe, judge or create. The scope (open-ended, proposal-only) is unambiguous. It never distinguishes itself from the many narrowly-scoped siblings such as request_human_observation, request_human_embodiment or request_independent_witness, so an agent cannot tell from the description alone which entry point to choose.

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?

'Open-ended' implies this is the catch-all when no specific request_* tool fits, but that routing is left implicit. No alternative is named and no when-not condition is stated despite ten-plus sibling request_* tools competing for the same intent. The one explicit constraint given — proposals are reviewed only, nothing is scheduled or paid — is useful but does not help selection.

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