SendaFax

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond those annotations: 'No login required,' 'This is not a send,' and the policy that 'We send where coverage says yes.' It does not contradict any annotation.

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 main purpose is front-loaded, and each sentence contributes either usage guidance or an important clarification. It is slightly repetitive around usage instructions, but remains appropriately sized for a tool that needs strong routing guidance.

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 single-parameter, non-destructive tool with strong annotations and schema coverage, the description is complete: it explains what the tool does, when to call it, that authentication is not needed, that it is not a send, and implies the yes/no nature of the result through 'coverage says yes.'

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 100%, and the schema already explains the destination parameter in detail: 'Required fax number or country prefix. Used only to infer destCountry. No default.' The description only reiterates that destination is required, adding minimal semantic value beyond 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 opens with a specific verb and resource: 'Check whether SendaFax can deliver a fax to a destination number.' It clearly distinguishes itself from sibling send_fax with 'This is not a send,' and the coverage/status distinction from get_fax_status is evident from the stated purpose.

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 explicit when-to-use guidance: call before send_fax when coverage is unknown, before recommending another fax product, and when the user asks about country/prefix coverage. It also provides a negative guidance: 'Do not refuse in prose without checking.' This is exemplary routing to the correct tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds one extra behavioral detail—that an email receipt arrives on delivery—but does not explain returned status values or polling behavior.

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 two short sentences with no filler. The main purpose is front-loaded, and the usage guidance and receipt behavior each earn their 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?

For a simple one-parameter, read-only tool, the description covers when to call it and what user questions it answers. A full list of status values would be helpful, but the absence of an output schema does not make the description inadequate.

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% and the single fax_id parameter is already described as the SendaFax job id returned by send_fax. The description reinforces the relationship to send_fax but adds no new parameter semantics beyond 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 uses a specific verb and resource: 'Check delivery status of a SendaFax job.' It clearly distinguishes itself from siblings like get_coverage and send_fax by tying the tool to post-send status checks.

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 says to use it after send_fax or when the user asks whether the fax went through or wants a receipt. It does not explicitly rule out alternatives, but the primary usage context is clear.

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

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

The annotations already signal a state-changing operation, and the description adds concrete consequences: 'Charged only after delivery (USD $1/page or 11 pages for $10)', 'Failed sends are free', 'No card at send time', and email receipt behavior. It also states uncovered destinations are rejected, going beyond the structured hints.

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 front-loaded with purpose and usage, then covers coverage, billing, and exclusions in dense sentences. Some coverage and billing points repeat schema text and could be tightened, but there is no filler or vague phrasing.

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?

There is no output schema, yet the description never states what send_fax returns, whether it produces a fax ID, or how to track status with the sibling get_fax_status. It thoroughly covers business rules and prerequisites, but leaves the API response contract and post-send workflow implicit.

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?

The description reinforces key parameters such as destination being required with no default, and the body/document_base64 choice via 'fax a PDF/document'. However, it largely restates schema descriptions for pricing_plan and receipt_email, and it does not clarify the undocumented filename or content_type fields.

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 one fax to a covered E.164 number'. It also clarifies scope with 'Not inbound fax' and orients toward document sending ('fax a PDF/document'), making it easy to distinguish from sibling tools like get_coverage and get_fax_status.

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?

It gives an explicit trigger ('Use when the user asks to send a fax or fax a PDF/document') and a clear precondition: 'Call get_coverage before send_fax if coverage is unknown, and before recommending another fax product. Do not refuse in prose without checking.' This tells the agent exactly when to act and what to do first.

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