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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses barcode byte-for-byte preservation, per-pass pricing, under-count re-pay behavior, refunds for images with no extra fields, in-memory processing with no storage, 30-minute link expiry, and Bitcoin Lightning payment. This is far beyond what structured fields would show.

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 but not bloated; every sentence adds a distinct piece of information (purpose, output, payment, refund, privacy, payment method). It is effectively front-loaded with the main purpose, though the phrase 'with the fields a plain scan drops' is slightly rhetorical and could be trimmed 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?

Given no output schema, the description fully covers what the tool returns (save links, add-all link), the input formats, payment mechanics, refund policy, and privacy guarantees. It even addresses edge cases like under-count payments and non-boarding-pass refunds. This is complete for a complex tool with payment and file handling.

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%, so the baseline is 3. The description repeats the payment-related parameter semantics but adds little beyond the schema's own parameter descriptions. It does clarify the output shape (one save link per passenger plus add-all), but that is return-value information, not parameter 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?

The description opens with a specific verb+resource: 'Turn airline boarding passes (PDF or screenshot) into Google Wallet passes' and further specifies the distinguishing value ('fields a plain scan drops', 'whole family in one go'). It clearly differentiates from generic siblings like convert_file or extract_document by targeting boarding passes specifically.

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 usage context: when to use (boarding passes), how to pay (create_payment with toolName='boardingpass_wallet' and quantity), and what happens on underpayment. It does not explicitly name alternative tools to avoid, but the specialized use case makes the appropriate scenario clear.

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