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

The description discloses meaningful behavior beyond the annotations: sending returns a job id immediately, delivery must be polled via get_fax, billing occurs per page at delivery, and failed faxes are not charged. These details tell the agent what to expect from an asynchronous, externally visible action and add value beyond the flat annotation flags.

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 carry the entire definition with no filler. Purpose, pricing, all input alternatives, return behavior, and failure semantics are packed efficiently, and the most important facts are front-loaded.

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 tool with 7 parameters, no schema descriptions, and only flat annotations, this description is complete: it covers the required format, all source alternatives, the asynchronous job flow, and cost implications. The presence of an output schema is not even needed because the description already states the job id return and the polling step.

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 0%, so every parameter is explained in the description: to must be E.164, artifact_id comes from any earlier result, job_id has a readiness precondition, form_id refers to a fillable form, pdf_url and pdf_base64 each supply one PDF, and sources lists artifact IDs with optional page ranges. The 'or' structure also conveys that these are mutually exclusive ways to provide the PDF.

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 opens with a specific verb and resource—'Send a PDF to a fax number'—and immediately adds 'track delivery' and 'priced per transmitted page,' making the action unmistakable. It clearly distinguishes send_fax from siblings like get_fax or compose_pdf by stating the tool is the fax-sending action.

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 gives strong contextual routing: it tells the agent to poll get_fax for delivery, and explains that job_id should come from fill_form_from_context or commit_proposal only after get_job reports ready. It does not explicitly say when not to use send_fax or when to prefer another PDF-producing tool, so it lacks the explicit exclusion clause of a 5.

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