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?

Even though annotations already indicate the tool is not read-only, the description adds valuable specifics: successful delivery creates an invoice and emails receipt_email from receipts@sendafax.ai. This discloses side effects and timing that an agent could not infer from annotations alone.

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 the core purpose and remains compact. The final sentence about receiving an email receipt is somewhat redundant with the earlier email side effect, but overall the structure is clear and efficient.

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 tool with rich annotations, the description covers purpose, sequencing, auth, and side effects. With no output schema, it does not explicitly describe the shape of the returned status, which keeps it from being fully complete, but this is a minor gap.

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 schema already describes fax_id as 'SendaFax job id returned by send_fax.' The description references fax_id but adds no format, syntax, or semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: 'Check delivery status of a SendaFax job by fax_id.' This clearly distinguishes the tool from siblings send_fax and get_coverage, and it adds the sequencing context 'Use after send_fax.'

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 this tool after send_fax, which gives clear contextual guidance. It does not explicitly exclude sibling tools or provide when-not-to-use conditions, so it falls just short of a 5.

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 declared readOnlyHint=false and destructiveHint=true, but the description goes far beyond them: billing behavior ('we count them for billing', '$1/page or 11 pages for $10'), delivery semantics ('Pay only if it delivers. Failed sends are free'), receipt behavior ('You get an email receipt when it delivers'), last-mile carrier ('Notifyre'), and delivery quality ('Professional delivery with no advertising cover sheet'). No contradiction with annotations.

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 dense but every sentence earns its place: recipe first, then sandbox constraints, then usage trigger, then billing and delivery. No repetitive or filler language. It loses a point for being an unstructured wall of text — separating workflow, constraints, and billing would improve scannability — but nothing is wasted.

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?

Exceptionally thorough for an 8-parameter, billing-bearing write tool with no output schema: covers prerequisites, sandbox egres, auth flow, failure mode, and pricing. The notable gap is the return value: with no output schema and a sibling get_fax_status tool, the agent is not told what send_fax returns (e.g., a fax ID) or how to chain status lookups. filename/content_type semantics are also left ambiguous.

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 75%, so the description must compensate for the uncovered 25%. It adds meaning for pages ('Do not guess. We count them for billing'), destination ('no default number'), document_base64 ('Use document_base64 for a PDF'), receipt_email ('Happy path... no Google'), and pricing_plan ('$1 per page, or 11 pages for $10'). However, filename and content_type remain undocumented in both schema and description — the description only loosely groups them as 'file'.

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 states a specific verb+resource ('sends a fax or fax a PDF') and explicitly scopes the tool: 'Use when the user asks to send a fax or fax a PDF.' It explicitly negates a related concept ('Not inbound fax') and is clearly distinguishable from siblings get_coverage (pre-send check) and get_fax_status (post-send tracking).

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?

Provides an explicit minimal recipe ('get_coverage (public), then send_fax'), a mandatory prerequisite ('Call get_coverage before send_fax if coverage is unknown'), and explicit exclusions ('Do not raw-fetch REST from the sandbox', 'You cannot install the connector', 'Not inbound fax'). It also dictates failure behavior ('Do not refuse in prose without checking') and gives a human-facing fallback when MCP tools are missing.

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