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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's job is to add context. It adds meaningful behavioral context: the tool only uses buyer-supplied information, performs no external research or outbound actions, returns a draft for human review, and requires explicit wallet authorization for the 0.25 USD payment. This goes beyond the annotations and helps the agent understand side effects and prerequisites.

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?

Four sentences, each earning its place: deliverable scope, boundary conditions, output nature, and payment requirement. The most decision-relevant information (what it creates and what it does not do) is front-loaded, and the payment detail is placed at the end where it is less likely to distract from selection.

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 content-generation tool with no output schema, the description covers the deliverable, the input source, the absence of external actions, the human-review nature, and the payment requirement. It does not detail the return format or how the payment_signature parameter is used, but the essential selection and invocation context is present.

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%, so the description must compensate. It names the core input concept (buyer-supplied information) and the output (draft for human review), but it does not explain the individual parameters (brief, audience, source_text) or the payment/expiry fields. The description adds some context but leaves the agent to infer parameter meanings from names alone.

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 deliverable (sales call script) and enumerates its components (opening, discovery flow, value explanation, objections, next-step close), and explicitly distinguishes it from a live calling action. This clearly differentiates it from siblings like tradepilot_service_sales_deck_outline or tradepilot_service_objection_responses.

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 states when to use it (when a sales call script draft is needed) and what it does not do (no calling action, no external research or outbound actions). It does not name specific sibling alternatives or exclusion conditions, but the scope boundary is clear enough for an agent to select it among the many content-generation siblings.

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