PromptFax

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

Annotations already declare destructiveHint=false and openWorldHint=true. The description adds value by explaining the tool is a 'fallback/non-widget' option, which implies behavioral constraints compared to the widget. It also clarifies that the tool binds documents into a session, but does not elaborate on side effects or potential failures; however, the annotations cover the safety profile, so this is adequate.

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 concise, consisting of two sentences that front-load the purpose. It contains no fluff, but the first sentence is somewhat dense. Still, it is efficient and well-structured.

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?

Given the tool has 3 parameters and an output schema, the description adequately covers purpose and usage context. It explains the relationship to widget sessions and when to prefer alternatives. It does not need to explain return values because an output schema exists. Overall, it provides enough context for correct use.

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 input schema already documents all parameters. The description does not add meaning beyond the schema; it only reiterates that the tool binds 'PromptFax document or HTTPS PDF URLs', which maps to documentId and fileUrls. Baseline of 3 is appropriate when schema does the heavy lifting.

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 clearly states the tool's purpose: 'Fallback/non-widget tool for binding a PromptFax document or one or more HTTPS PDF URLs into the current MCP session before requesting a quote.' It uses a specific verb ('binding') and resource ('PromptFax document or HTTPS PDF URLs'), and distinguishes itself from sibling tools like start_session and widget file controls.

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 tells when to use this tool versus alternatives: 'In ChatGPT widget sessions, prefer the widget's file controls after start_session instead of calling this tool unless the widget is unavailable or the user explicitly asks for fallback behavior.' This provides clear context, exclusions, and a named alternative.

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 declare destructiveHint=true, so the description doesn't need to emphasize destructiveness. The description adds minimal behavioral context beyond this, such as clarifying that it applies to 'active' sends, but doesn't disclose side effects like whether the cancellation is reversible or what happens to associated resources.

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 a single clear sentence with no unnecessary words or redundancy. It is highly concise and 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?

Given the tool's simplicity, the description adequately covers the basic operation. However, it lacks explicit mention of prerequisites (e.g., needing an active send) and does not reference sibling tools for comparison. An output schema exists but is not shown; still, the description is largely sufficient for a straightforward cancel action.

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?

Both parameters have full schema descriptions (100% coverage), so the description adds no additional meaning beyond what the schema provides. The baseline 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 clearly states the verb 'cancel' and the resource 'active PromptFax send', making the tool's purpose unambiguous. It effectively distinguishes from sibling tools like 'send_fax' or 'retry_failed_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 mentions when to use it (for canceling an active send) but provides no explicit exclusions, prerequisites, or alternatives among sibling tools. Usage context is implied rather than explicit.

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 description discloses key behavioral traits beyond the annotations: it is a fallback, opens external Checkout, and that PromptFax treats webhook-confirmed authorization as payment truth, not the browser redirect. Annotations only indicate non-destructive and open-world, so the description adds valuable safety context.

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 very concise at two sentences, with the main purpose front-loaded. Every sentence adds essential information without redundancy or filler.

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?

Given the tool's moderate complexity and the presence of an output schema, the description is complete. It covers the tool's role, when to use, behavioral nuances, and workflow context (widget vs. non-widget), leaving no major gaps.

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 detailed descriptions for each parameter. The description does not add significant new meaning beyond what the schema already provides. It restates the parameter usage (e.g., sessionId for session-backed workflow) but does not expand on constraints or formats.

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 clearly states it is a fallback/non-widget tool for starting external Stripe Checkout after the user accepts a pay-per-use quote. It distinguishes itself from siblings by explicitly noting it should not be called after start_session in widget sessions, making its unique role clear.

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 provides explicit guidance on when to use (after user accepts a pay-per-use quote) and when not to use (in widget sessions after start_session). It also explains the payment authorization logic (webhook vs. redirect), giving clear context for correct invocation.

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 (openWorldHint, destructiveHint false) are already present. Description adds context: the quote is user-reviewable, required before Stripe Checkout, and warns against calling after start_session in widget sessions. No contradictions.

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, front-loaded with critical information. No filler; every word serves a purpose. The structure is efficient and easy to parse.

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?

Given the presence of an output schema (per context signals), the description adequately covers purpose, prerequisites, usage context, and a key caveat. It is sufficiently complete for an AI agent to correctly invoke the tool.

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 descriptions for each parameter. The description adds value by clarifying that fileUrls expects one or more HTTPS PDF URLs (schema also mentions images) and emphasizes the combination requirement (faxNumber + one of sessionId/documentId/fileUrls).

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 clearly states the tool is a fallback/non-widget for creating a pay-per-use fax quote when you have a fax number and one of sessionId, documentId, or fileUrls. It distinguishes from the widget's auto-quoting mechanism, making the purpose unambiguous.

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 provides when to use (as a fallback, before checkout/transmission) and when not to use (after start_session in widget sessions). Prerequisites are clearly listed: fax number plus one of the three document sources.

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. The description adds value by specifying the nature of the status (workflow, quote/payment, transmission), which supplements the annotations without contradiction.

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?

Single sentence, front-loaded with purpose, no extraneous words – highly 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?

With annotations and output schema present, the description explains what the tool returns, and parameters are fully documented in schema. No gaps identified.

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 description adds no new parameter information beyond what the schema already provides. 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?

The description clearly states the tool returns 'latest PromptFax workflow state, quote/payment state, or fax transmission status,' using a specific verb and resource, and distinguishes it from siblings by specifying what status information is provided.

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 explicitly says 'Use this when you need...' which provides usage context. It does not mention when not to use or contrast with sibling tools, but the sibling list and context signals imply alternatives.

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 indicate openWorldHint and no destructiveness. The description adds that the tool 'prepares a new authorization attempt', which implies a safe, state-changing operation. No contradictions; but more detail on the authorization process would be beneficial.

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?

A single, well-structured sentence that immediately conveys the tool's purpose and context. No unnecessary words.

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 two well-documented parameters and an output schema, the description is largely complete for a simple retry operation. However, it could briefly mention what 'prepare a new authorization attempt' involves, though the output schema may cover that.

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 detailed parameter descriptions. The tool description adds no additional parameter meaning beyond the schema, meeting the baseline for high coverage.

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 clearly states the tool retries a failed fax to prepare a new authorization attempt, using specific verb 'retry' and resource 'failed fax'. It uniquely distinguishes from siblings like send_fax or cancel, which handle other fax states.

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 after a retry-eligible failed fax, providing clear context. While it does not list when-not-to-use or alternatives, the sibling tool set implies other use cases, but explicit exclusion would improve.

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 provide destructiveHint=true, so the description adds value by explaining the context (fallback, after payment) and user authorization requirement. It doesn't contradict annotations and offers useful behavioral detail beyond the structured field.

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 sentences, front-loaded with purpose, no wasted words. It is concise yet packed with essential usage 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?

Given the tool has 2 params, no required fields, and an existing output schema, the description covers key context (fallback, authorization, when to avoid). It could add more about post-send behavior but is sufficient for an agent to use correctly.

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% with detailed descriptions for both parameters. The tool description does not add additional meaning beyond what the schema already provides, so 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?

The description clearly states it sends a fax after payment authorization, and distinguishes it as a fallback/non-widget tool. The verb 'send' and resource 'fax' are explicit, and it differentiates from sibling tools like 'checkout' and 'start_session'.

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 states when to use (after payment authorized and user wants to send now) and when not to use (in ChatGPT widget sessions unless widget unavailable or user asks for fallback). This provides excellent decision guidance.

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 description discloses key behavioral traits beyond annotations, such as the need for user-reviewed quote and Stripe payment, widget behavior differences across hosts, and that the widget does not provide document preview. It does not contradict the openWorldHint=true or destructiveHint=false 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 front-loaded with the primary purpose and is structured clearly, but it is somewhat verbose. It could be slightly more concise without losing critical context, but every sentence does add value for correct tool invocation.

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 description covers all necessary aspects: when to use, host-specific workflows, instructions for file handling, and explicit exclusions of sibling tools. Given the complexity (6 parameters, nested objects, output schema exists), the description is complete and leaves minimal ambiguity for an AI agent.

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 adds value by providing usage context for parameters like hostType (e.g., 'set hostType to chatgpt') and files (e.g., ChatGPT may provide download URLs). However, it does not significantly expand beyond schema descriptions for all parameters.

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 clearly states the tool is used to start a session for sending or pricing a fax. It provides specific context about PromptFax's pay-per-use model and distinguishes it from sibling tools by instructing not to call get_quote, checkout, or send_fax for ChatGPT widget sessions.

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 when to use this tool ('first when a user wants to send or price a fax'), provides host-specific guidance, and explicitly states when not to call other tools (e.g., 'Do not call get_quote, checkout, or send_fax for a ChatGPT widget session').

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