massprint

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that no key is issued immediately, the application is reviewed, and the key is emailed to contact_email. It also discloses the invoicing model (GSTIN required, default 25% discount, monthly settlement). While it doesn't cover failure modes or review timelines, it provides substantial behavioral 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 a moderately sized paragraph that front-loads the core purpose and then explains key behaviors and usage restrictions. Every sentence contributes useful context, though it could be slightly more streamlined without losing meaning.

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 the application flow, requirements, pricing model, and usage guidance. It lacks information about review timelines, rejection reasons, or post-approval steps beyond emailing the key, but given the complexity of an enterprise application and the absence of an output schema, it is reasonably 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some context around why GSTIN is required and how contact_email is used, but these are largely restatements of the schema descriptions. It doesn't enrich parameter semantics 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 opens with a specific verb+resource ('Apply for an enterprise (invoiced) account') and immediately distinguishes this from order creation by describing the target user: 'platforms printing at volume behind their own checkout.' It also contrasts with sibling tools like create_order by clarifying this is for account setup, not order placement.

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 a usage gate: 'Use this only when a human has asked to set up a business/enterprise print account.' It also describes when this tool is appropriate (volume printing, own checkout) and what it does differently from standard order tools (auto-confirm, no payment link, monthly settlement), guiding selection among siblings.

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?

No annotations are provided, so the description carries full responsibility. It discloses key behaviors: cancellation does not move money, releases the client_reference (allowing reprint), and handles race conditions by returning not_cancellable rather than falsely claiming success.

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 dense paragraph, front-loaded with the core purpose. Every sentence adds distinct value, but the length is substantial; a structured list could improve scannability.

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 complexity of cancellation semantics, the description covers all relevant scenarios, effects, and errors. It also references the appropriate sibling tool for refunds, making it self-contained despite the lack of an output schema.

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 schema provides descriptions for order_token but not order_id. The description enhances understanding of order_token's role and alternates, and explains error conditions. order_id is implied as the order to cancel, but its origin is not explicitly stated beyond context.

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 'Cancel an order, stopping it before it is printed', a specific verb and resource that clearly distinguishes this from siblings like create_order and get_order. It continues with concrete state-based behavior, further differentiating from related 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?

Provides explicit when-to-use guidance: cancel works while awaiting_payment with order_token, and platform-created orders can be canceled even in confirmed/printing states. It also states when not to use it (shipped/delivered cannot be canceled) and directs to refund alternatives via get_catalog.

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?

With no annotations provided, the description carries the full burden. It discloses important behaviors: validation occurs before payment link creation, order_token is shown once, orders auto-confirm after payment, and unpaid orders expire in 72 hours. It lacks failure mode details but is substantially transparent.

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 and well-structured, with two sentences that pack essential details: purpose, validation flow, return shape, token handling, and expiry. Every sentence earns its place with no redundancy.

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 a nested address object, no output schema, and five params, so the description needs to explain return values and usage flow. It does so thoroughly, covering the order object fields, payment_url usage, token persistence requirement, auto-confirmation, and 72-hour expiry. Minor omission: nothing about error cases or cancellation behavior beyond token requirement.

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 80%, so the schema handles most parameter documentation. The tool description adds a bit by emphasizing the upload must be validated and referencing the payment_url output, but it does not compensate for the undocumented 'copies' param or add deeper field semantics 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 verb ('Create'), resource ('print order'), and specific precondition ('validated upload'), distinguishing it from sibling tools like create_upload and validate_pdf. It also outlines the scope by mentioning the validation step before payment link generation.

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 implies use after validation by saying 'for a validated upload' and explains next steps (giving payment_url, saving order_token). It references sibling tools get_order and cancel_order for token usage, but does not explicitly state exclusions or when to use this tool over 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?

With no annotations, the description carries full burden and exceeds expectations. It discloses the return fields, the need for HTTP PUT with specific Content-Type, that the URL is signed and needs no auth, that the PUT response contains the validation report, and detailed rate limits (20/hour, 5 open, 2-hour expiry). It also advises to reuse upload_id, which is essential behavioral 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?

Every sentence adds value: the first states the purpose and return, the second describes the follow-up action, and the third provides critical usage limits and advice. The description is dense but well-structured, with no filler or redundant information. It is front-loaded with the core action.

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?

Despite having no output schema or annotations, the description fully covers the tool's behavior, return value, next steps, and constraints. It even explains the validation report in the PUT response and how API keys affect limits. This is complete for a tool with this 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?

The tool has zero parameters, so the baseline is 4. The description adds meaningful semantic context about what the tool produces and how to use the result, which compensates for the absence of parameters. It does not describe any parameter constraints because there are none, making the score 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 opens with a specific verb and resource: 'Start a PDF upload.' It clearly defines the tool's role as the initial step in the upload workflow, distinguishing it from siblings like create_order (which uses the upload_id) and validate_pdf. The purpose is 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?

The description provides clear workflow context: HTTP PUT to put_url, then pass upload_id to create_order. It also gives practical guidance on rate limits and reusing upload IDs. However, it does not explicitly mention when NOT to use this tool or compare it to alternatives (e.g., validate_pdf), so it stops 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It states the output contents (SKUs, formats, sizes, page-count limits, prices with INR and shipping included, shipping coverage India only) and its purpose (first step for pricing/PDF acceptance). This adds meaningful context about what the tool returns and its role, though it doesn't explicitly state it's read-only or non-destructive.

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, well-front-loaded sentence. It opens with the core action 'List what can be printed' and then efficiently enumerates all relevant catalog attributes without unnecessary fluff. Every clause adds value.

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 no output schema, the description adequately explains what the tool returns by listing the types of data (SKUs, formats, sizes, page counts, prices, shipping coverage). It also puts the tool in context with 'Call this first', making it complete for a low-complexity catalog listing 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?

The tool has zero parameters, so the description doesn't need to explain parameter usage. The description still adds value by outlining the catalog contents, which inherently communicates what information the tool provides. Baseline for 0 params is 4.

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 function: 'List what can be printed' followed by a detailed enumeration of catalog contents (SKUs, formats, sizes, prices, shipping). It distinguishes itself from sibling tools like create_order, validate_pdf, and get_order by focusing on catalog data rather than order/validation operations.

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 instructs when to use the tool: 'Call this first to quote a price or check whether a PDF will be accepted.' This provides clear context for use, though it doesn't explicitly mention alternatives or when not to use it. Given the simple nature of the tool, this is strong 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?

No annotations are provided, so the description carries the burden. It discloses authentication requirements and the status lifecycle, which is helpful. It does not explicitly state read-only behavior or error handling, but for a simple read tool this is acceptable.

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 long, front-loaded with the core purpose, and every sentence contributes essential details. No filler or redundancy.

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 the main return values and authentication context. Given no output schema or annotations, it does not describe the exact return format or error scenarios, but it provides enough for typical usage.

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 schema already describes order_token sufficiently, and the description does not add new meaning for order_id. Since schema coverage is 50%, the description partially compensates by explaining the alternative authentication method, but it does not clarify the order_id parameter further.

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 uses the specific verb 'Check' with the resource 'an order' and enumerates the returned data: status, tracking number, and payment_url. This clearly distinguishes it from sibling tools like cancel_order or create_order, which have different actions.

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 context for when to use this tool (e.g., to re-answer 'how do I pay') and prerequisite guidance (requires order_token or the API key). However, it does not explicitly mention when not to use it or name alternative tools for similar purposes.

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?

With no annotations, the description fully discloses key behavioral traits: it is a read-only report, free, and distinguishes blocking errors (hard) from non-blocking (soft). Also reveals that errors include a resolution field, which is not obvious.

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 purpose, and every clause adds value (contents, blocking nature, cost, usage timing). No redundancy or fluff.

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 no output schema, the description is complete: it states what the report contains, the meaning of errors, and when to call it. No critical gaps remain.

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% for the single parameter upload_id, already describing it as returned by create_upload. The description adds no parameter-specific semantics beyond mentioning 'uploaded PDF', 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?

States a specific verb ('Get') and resource ('print-validation report for an uploaded PDF'), and enumerates report contents (page count, trim size, hard errors, soft warnings). Clearly distinct from siblings like create_order or get_order by positioning it as a pre-payment check.

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 says to use it 'before paying' and 'to check printability before create_order', giving clear temporal and contextual guidance. Also notes it is 'Free to call', informing cost/usage decisions.

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