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

Annotations already mark the tool as readOnly and openWorld, so no mutation risk is implied. The description adds valuable behavioral context beyond annotations: no account or API key is needed, pricing is pay-per-fax with a specific formula, and quoted prices are returned in USD cents. This gives the agent useful expectations about cost and access.

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 and front-loaded with the core purpose, usage guidance, and pricing. It earns its length, though phrases like 'send, transmit, or fax' are slightly redundant. Overall it is concise for the amount of useful context it packs in.

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?

The tool has no output schema, so the description's statement that prices are 'returned in USD cents' partially fills that gap. It covers geography, input alternatives, pricing, authentication, and when to call the tool. It could be more explicit about the exact response shape, but for a simple quote tool the provided context is sufficient.

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 parameters are already well documented. The description renames the three parameter options and adds the 'publicly downloadable PDF' constraint, but this mostly overlaps with the schema's 'Public http(s) URL of the PDF to fax.' The description does not substantially exceed the schema's parameter explanations.

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 action and resource: 'Get the exact price to send a real fax to any US, Canadian, or international fax number via faxer.me.' It is clearly distinct from sibling tools like send_fax, create_fax_payment, and get_fax_status. The phrase 'Call this first' reinforces that this is the quote-before-send tool.

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 call this tool first whenever a user wants to send, transmit, or fax a document or message. This is a clear usage trigger. It does not explicitly name sibling alternatives or exclusion cases, but the 'call this first' guidance makes the intended workflow clear.

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