PromptFax

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

Annotations (openWorldHint=true, destructiveHint=false) already cover safety. The description adds context about fallback behavior and binding documents, but does not elaborate on side effects like multiple calls or state changes. However, it does not contradict 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?

Two concise sentences, front-loaded with purpose. The second sentence adds essential usage context. No wasted 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?

Given the tool's role in a workflow (start_session -> attach_document -> get_quote), the description provides enough context. It mentions prerequisite session and purpose before requesting a quote. With an output schema present, return values need not be detailed.

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 parameter descriptions. The description adds slight value by grouping fileUrls and documentId as alternative ways to attach documents, but does not provide significant additional meaning 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 clearly states the tool's purpose: binding a PromptFax document or HTTPS PDF URLs into the current MCP session before requesting a quote. It also distinguishes it from the widget alternative, making it specific and differentiating from sibling tools.

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 and when-not-to-use guidance: 'In ChatGPT widget sessions, prefer the widget's file controls... unless the widget is unavailable or the user explicitly asks for fallback behavior.' This clearly defines context and exclusions.

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 include destructiveHint: true, and description matches but adds no additional behavioral context beyond the 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?

Single sentence, front-loaded, no wasted words—highly concise.

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 cancellation tool with output schema and fully described parameters, the description is sufficient; could mention constraints but not required.

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 descriptions cover both parameters fully, and the description adds no extra meaning beyond what the schema provides; baseline 3 applies.

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?

Description clearly states the verb 'cancel' and resource 'active PromptFax send', and it distinguishes from sibling tools like send_fax or get_quote.

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 states when to use it ('when you need to cancel the active PromptFax send'), but does not mention when not to use or provide 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?

The description adds critical behavioral context beyond annotations: it explains that PromptFax treats webhook-confirmed authorization as payment truth, not browser redirect, and that payment authorization is required before sending. This clarifies the non-destructive nature (destructiveHint false) and external system interaction (openWorldHint true).

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 three sentences, each serving a distinct purpose: defining the tool, explaining payment truth, and providing usage constraint. No redundant or extraneous 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?

Given the presence of a complete output schema and 100% parameter coverage, the description sufficiently covers tool purpose, behavioral traits, usage guardrails, and constraints. It leaves no major gaps for an agent to misunderstand when or how to 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?

Parameter descriptions in the schema are comprehensive (100% coverage), so the description does not need to add further detail. It does not reiterate or enhance parameter meaning beyond what the schema already provides.

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 that the tool is a fallback for starting external Stripe Checkout after a user accepts a pay-per-use quote, distinguishing it from widget-based workflows. The purpose is specific and actionable, directly addressing the tool's core function.

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 the tool (after quote acceptance) and when not to use it (in ChatGPT widget sessions after start_session). While it does not explicitly name alternative tools, the exclusion is clear and informative.

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 openWorldHint and destructiveHint false. The description adds that a quote is required before Stripe Checkout and fax transmission, but does not disclose additional behavioral traits like what happens if multiple optional parameters are provided or error scenarios. The transparency is adequate but not comprehensive.

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 with only two sentences, but the first sentence is long and packs multiple conditions. It is front-loaded with the core purpose but could be more readable. Still, no wasted 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?

Given that an output schema exists, the description does not need to explain return values. It covers prerequisites (needs fax number and document), usage context (fallback for non-widget), and critical constraints (quote required before checkout). It could mention how the quote is presented but is sufficient for the tool's complexity.

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 all parameters. The description reiterates the optionality of parameters (either session, documentId, or fileUrls) but adds no new meaning beyond the schema. Baseline score of 3 is appropriate as 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: creating a user-reviewable pay-per-use fax quote. It specifies required inputs (fax number and one of session, documentId, or PDF URLs) and distinguishes from other tools by noting it's a fallback for non-widget scenarios, avoiding confusion with sibling tools like 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 gives explicit context on when to use (non-widget scenarios with fax number and document) and when not to use (in ChatGPT widget sessions after start_session because auto-quoting occurs). It does not explicitly list alternative tools but the context is clear enough for an AI agent to decide.

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, indicating safe operations. The description adds specific types of state (workflow, quote/payment, transmission) beyond the annotation data, enhancing transparency without contradicting 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?

The description is a single, concise sentence that front-loads the purpose ('Use this when you need...'). Every word adds value with no redundancy, achieving high conciseness and structure.

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, the description does not need to explain return values. The tool has two optional parameters, and the description adequately covers its purpose as a status retrieval tool. No gaps are evident.

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 both parameters (sessionId, sendIntentId) having detailed descriptions. The tool description adds no additional parameter meaning beyond what the schema 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 the tool returns the latest PromptFax workflow state, quote/payment state, or fax transmission status, with specific verb (get) and resource (status). It effectively defines the tool's scope and distinguishes it from action-oriented siblings like cancel, checkout, or 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 'Use this when you need...' which provides clear guidance on when to invoke the tool. While it does not list exclusions or alternatives, the context signals and sibling names imply this is for status retrieval, not for initiating actions, which is adequate.

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 destructiveHint: false. The description adds only 'prepare a new authorization attempt,' which is consistent but doesn't disclose additional behavioral traits (e.g., side effects, permissions, or what 'prepare' entails). Minimal extra value.

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 that is direct, front-loads the usage condition, and contains no filler. Every word 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?

Given an output schema exists, the description need not detail return values. The two parameters are fully documented in the schema. The description provides the necessary precondition. Slightly lower due to no mention of what 'authorization attempt' involves, but overall 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 coverage is 100% with detailed descriptions for both parameters. The description does not add meaning beyond the schema, so 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 title and description clearly state the tool's action: retrying a failed fax. It specifies the prerequisite ('after a retry-eligible failed fax') and the outcome ('prepare a new authorization attempt'), distinguishing it from sibling tools like cancel or 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 conditions usage on a retry-eligible failed fax, providing clear context. It does not list alternatives or when not to use, but the sibling tools imply alternative states, so guidance is adequate.

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 complements the destructiveHint annotation by noting that sending occurs after payment authorization, implying irreversible action. It adds context about fallback behavior, which is beyond the 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?

Two sentences with no waste. The key purpose and usage conditions are front-loaded, making it easy for an AI to quickly understand the tool.

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 that the tool has an output schema, the description adequately covers when to use, fallback context, and parameter reliance on session IDs. No gaps remain for 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?

The input schema already describes both parameters thoroughly (100% coverage). The description does not add parameter-specific details, so it meets the baseline for high schema 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's purpose: a fallback for sending a fax after payment authorization, explicitly distinguishing it from the widget-based workflow. It uses specific verb ('send') and resource ('fax'), and mentions when to call it vs the widget.

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 when-to-use (after payment authorized, user wants to send now) and when-not-to-use (in widget sessions unless fallback needed). It implies an alternative (widget) but does not name specific sibling tools.

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: true, destructiveHint: false) already indicate non-destructive behavior. The description adds detailed context about session creation, widget flow, file handling, and payment authorization, which is valuable beyond 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 lengthy and contains many details that could be streamlined. While front-loaded with the main purpose, it includes extensive workflow instructions that may be better placed in sibling tool descriptions.

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 flows, widget handling, and coordination with sibling tools. Given the existence of output schema, return values are not needed. The tool complexity is fully addressed.

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 baseline is 3. The description adds value by explaining how hostType affects interaction mode and how files are handled, providing contextual advice above the schema's descriptive text.

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 'Use this first when a user wants to send or price a fax.' It identifies the tool as the initial step for fax workflow and distinguishes from siblings by specifying that other tools should not be called directly in widget mode.

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 (first step) and when not to use (e.g., 'Do not call get_quote, checkout, or send_fax for a ChatGPT widget session unless...'). It also differentiates between ChatGPT, Claude, and browser hosts with specific instructions.

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