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

The description contradicts annotations. Annotations include openWorldHint: true and destructiveHint: true, but the description states 'no external research or outbound actions' and that it 'returns a draft for human review,' which conflicts with openWorldHint and implies non-destructive behavior. This is a serious inconsistency that undermines trust.

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 relatively concise, with the core function stated first. It includes price and payment information that is important context for this service. Not overly verbose, but the inclusion of price might be seen as extra; still, it's relevant for a paid service. Structure is acceptable.

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?

Given the complexity (5 parameters, nested input, payment, no output schema), the description is severely incomplete. It does not explain how to provide payment authorization, what the draft output looks like, or the meaning of result_expires, idempotency_key, and signatures. An agent cannot reliably call this tool without additional information.

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 description coverage is 0%, and the description provides no parameter details. It does not explain the nested input object (brief, audience, source_text) or the signature/expiry fields. The agent is left without any semantic meaning for any parameter, making correct invocation difficult.

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 clearly states the verb 'summarize' and the resource 'policy text', and specifies the output structure (scope, requirements, exceptions, implementation questions). It also clarifies it is not legal advice. This distinguishes it from generic summary tools, though it could be confused with document_summary; still, the specific policy focus and output structure make it clear enough.

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?

No explicit guidance is given on when to use this tool versus alternatives. It does mention constraints (no external research, returns draft for human review) but does not state when to prefer this over siblings like document_summary or requirements_extraction. The absence of 'use for' or 'don't use for' leaves selection partly to inference.

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