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

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: prepare holds no server state, the receipt is minted only at ask_submit_draft, generation happens on the connected model's side so no LLM credential reaches the server, and unanswerable drafts can never earn a verified verdict. No annotation contradiction exists.

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 front-loads the tool's role and step in the flow, and each sentence generally earns its place given the complexity of the handoff protocol. It is long and densely worded, so most of the same information could be delivered in fewer words, but it is still well-structured with an opening summary and focused callouts.

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 two-stage BYO workflow with an output schema, the description is nearly complete: it explains the prepare/receives handoff, identify semantics, verbatim question requirement, original_question fallback, answerability after an unanswerable question, no redaction rule, no LLM credential exposure, and the recommended path to ask_submit_draft. Nothing essential is left unclear.

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 100%, so the baseline is 3, but the description adds real value: it insists the question be passed verbatim and explains why — do not expand, narrow, or reword it. It also clarifies the conditional requirement for original_question and how to fold in essential conversation context. It only slightly under-serves the history parameter, which is otherwise well covered by the 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?

The description names a specific verb-resource pair — 'run the server-side trust plane for a business question' — and specifies the deliverables: a composed prompt plus a single-use prepare_key/ask_id. It also self-identifies as 'BYO step 1 of 2,' clearly distinguishing it from ask_submit_draft and the other sibling tools.

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 explicitly sequences the usage: run prepare first, then write the draft from the returned prompt, then 'submit it with ask_submit_draft.' It also gives edge-case guidance: only a policy refusal stops at prepare, while unanswerable questions still prepare but are force-refused at submit. This is strong when-to-use and when-not-to-use guidance.

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