SendFaxFast

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds genuinely new behavioral facts: the link is one-time, expires after 30 minutes, creating it sends nothing and costs nothing, and it is a handoff mechanism feeding send_fax. This answers the natural 'does this have side effects or cost?' question for a non-read-only tool.

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?

Three sentences, front-loaded with what is created and its constraints, then when to use it over send_fax, then the follow-up flow. No filler; every clause carries operational information.

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 parameterless tool with no output schema, the description covers constraints (expiry, size, formats), the selection rule versus the sibling, and the return values and their downstream use. Nothing needed to invoke or chain it correctly is missing.

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 tool takes zero parameters, which sets the baseline at 4. The description does add value by naming the two output artifacts (upload_url and upload_id) and how they are consumed, partially compensating for the absent output 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?

States a specific verb and resource (creates a secure one-time upload link) with scope details: 30-minute validity, accepted formats (PDF, JPG, PNG), and 10 MB cap. It is instantly distinguishable from siblings like send_fax 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?

Explicitly names the alternative and the selecting condition: use this for files on the user's device or chat attachments not available via send_fax's "file" parameter. It also spells out the required follow-up workflow (user opens upload_url, then send_fax accepts the returned upload_id).

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations do not: this call requires a subscription API key in the 'sff_...' format. It stops short of describing error behavior for a missing/invalid key, so not a 5.

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, no filler. The high-value content (what you get back) is front-loaded and the credential prerequisite is placed second, which is the correct ordering.

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?

With no parameters and no output schema, the description does the necessary work by naming the three returned data groups, and it covers the auth prerequisite. It could go slightly further by noting what a failed auth returns or the response shape, but for a trivial read tool this is close to complete.

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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate and a 4 is the ceiling. The description's mention of the API key is an auth requirement rather than a schema parameter, so it adds no parameter-level semantics.

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?

Specific verb (Get) plus resource (account/subscription info), and it enumerates exactly what is returned: plan details, remaining fax quota, billing period. That is well beyond a restatement of the name. It doesn't explicitly position itself against siblings, though the account/subscription domain is naturally distinct from the fax-operation siblings (send_fax, list_fax_history, etc.).

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 implies the obvious use case (checking your plan/quota) and states the prerequisite credential, but gives no explicit when-to-use vs when-not guidance and never names an alternative. For a simple zero-arg read tool, implied usage is arguably sufficient, so a 3 rather than a 2.

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 readOnly, idempotent, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: no authentication is needed, the supported-country scope, and that premium-rate numbers will fail, which an agent cannot infer from the structured fields.

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?

Three short sentences, front-loaded with the core action, the auth fact, then the coverage/exclusion caveats. Reasonably tight, though the '(same list as sendfaxfast.com)' reference is an external pointer that adds little for an agent.

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 read-only pricing lookup with a fully documented two-parameter schema and no output schema, the description supplies the constraints an agent needs: supported geographies, premium-number exclusion, and no API key. Only the relationship to send_fax in a cost-estimation flow is left 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?

Schema coverage is 100%, with fax_number's E.164 format and examples fully documented in the schema, so the baseline of 3 applies. The description implies the destination restricts valid numbers (country list, no premium rates) but adds no syntax or format detail 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 names a specific verb and resource ('Calculate the pay-per-fax price for sending a fax to a specific number'), which cleanly separates it from send_fax and get_fax_status. It does not explicitly reference any sibling tool, so it stops short of full sibling differentiation.

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 clear conditions for when the result is valid: supported destination countries, premium-rate numbers excluded, and no API key required. It never states the workflow relationship to alternatives (e.g. call this before send_fax to estimate cost), so no explicit when-not/alternative routing is provided.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the API-key auth requirement for fax_id and the visibility scoping ('only your own faxes are visible'), which an agent needs to avoid surprising 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?

Two tight sentences: the purpose first, then the parameter routing and auth caveat. No filler, and the operationally important constraint is 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 compact two-parameter read tool with no output schema, the description covers purpose, parameter routing, and the auth/visibility constraint. It omits edge-case behavior (pending faxes, missing/expired token, mutual exclusivity of the two params), leaving slight room for ambiguity.

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%, so the baseline is 3. The description nonetheless adds value beyond the schema by tying token/fax_id to order type routing and surfacing the auth/visibility constraint. It does not state whether the two parameters are mutually exclusive, which is a minor gap.

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?

States a specific verb+resource ('Check the delivery status of a fax'), which is clear and unambiguous. It does not explicitly contrast with close siblings like list_fax_history or send_fax, but the resource is distinctive enough that an agent can separate it without opening the schema.

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?

Routes the agent between the two parameters by order type: 'token for pay-per-fax orders, fax_id for subscription orders.' That is genuine selection guidance, not just a restatement. It stops short of naming alternatives or stating when the tool should not be used.

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 cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), so the bar is lower. The description adds genuinely useful operational context the annotations do not carry: a required subscription API key in the sff_... format, which is a hard prerequisite for calling it.

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 short sentences, zero filler, with the action and scope front-loaded before the credential requirement. Every clause earns its 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 read-only list tool with two optional, fully documented parameters and annotations covering the safety profile, the essentials are present. It does not say what a returned fax record contains, which is a minor gap given there is no output schema, but nothing prevents correct invocation.

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 both parameters (limit, offset) are fully documented with defaults and bounds in the schema. The description adds nothing about pagination or result-size behavior, so the baseline 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?

States a specific verb and resource (list faxes) plus the scope qualifier 'recent' and the account boundary 'sent from this subscription account'. This cleanly distinguishes it from siblings like send_fax and get_fax_status, though it never names a sibling explicitly to sharpen the contrast.

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?

There is no explicit when-to-use statement and no mention of alternatives such as get_fax_status for a single fax. The use case is only inferable from the word 'List'; nothing tells the agent when this is the right tool versus another.

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?

Goes well beyond the annotations (destructiveHint/openWorldHint/idempotentHint) by disclosing the payment gate ('fax is sent after the user pays'), quota consumption, real-world transmission, one-time use of upload_id, size ceilings (10 MB link, 700 KB base64), country coverage, and what the result reports (sent/scheduled/awaiting payment).

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?

Front-loaded with the action and the payment branches, and dense with useful detail, but the document-source enumeration restates schema parameter descriptions and adds length. It is efficient for its complexity though not maximally tight.

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?

With no output schema and an 8-parameter mutation tool, the description still covers auth/payment model, input constraints, geography, and return-value meaning ('states whether the fax was sent, scheduled or is awaiting payment'), leaving nothing essential for a correct call.

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 already 100%, yet the description adds real meaning: the mutual exclusivity of the four document sources ('exactly one'), size limits per source, and that document_name is unnecessary with upload_id or file. It stops short of describing email or scheduled_at semantics, which the schema covers.

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?

Opens with a specific verb+resource ('Send a PDF document to a fax number') and immediately names the alternative path (create_upload_link) for obtaining a document, which cleanly separates it from its siblings get_fax_status, get_fax_price and list_fax_history.

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?

Explains the two operating modes (pay-per-fax checkout link vs. subscription key for immediate send), the constraint that exactly one of upload_id/file/document_url/document_base64 must be supplied, the geographic and premium-rate exclusions, and when to fall back to create_upload_link. An agent can pick the correct invocation path without inference.

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