Sats4AI - Bitcoin-Powered AI Tools

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

Annotations only mark destructiveHint and openWorldHint. The description adds substantial behavior context: async execution, voicemail retries (up to 3), pending_confirm return state, recording consent and deletion if not granted, pricing model, screening, and refund/data-retention policies. There is no contradiction with the 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 far from concise: it includes long policy, data-retention, refund, and legal paragraphs that go well beyond what is needed to select and invoke the tool. It is front-loaded with use and usage guidance, which is good, but the bulk of the text could be trimmed or moved to external documentation.

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 no output schema present, the description compensates by covering the expected return states (transcript, structured analysis, pending_confirm), async polling, language behavior, payment prerequisites, and safety constraints. An agent has enough context to decide whether and how to call 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?

The input schema already documents all six parameters (100% coverage). The description adds meaningful workflow context beyond the schema, especially around paymentId (requires create_payment with toolName='ai_call', phoneNumber, and durationMinutes) and the pricing/return-state behavior, which helps an agent understand how to supply parameters correctly.

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 — sending an AI voice agent to handle a phone call — and clearly distinguishes itself from siblings in the 'When NOT to use' section, naming open_voice_bridge, place_call, and send_sms. It also enumerates concrete use cases like booking, negotiating, and navigating IVR menus.

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 describes when to use the tool ('when your task hits a wall that requires a human') and provides an explicit 'When NOT to use' section with alternative tools. It also explains the prerequisite flow through create_payment and async polling via check_job_status.

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 provided, so description carries full burden. Discloses model (Qwen VL), capabilities (OCR, chart reading, spatial reasoning), pricing, and a critical behavior warning about PDFs causing hallucinations. Missing info on async vs sync and error handling.

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?

Description is concise with only necessary sentences. Front-loads the core purpose. Minor redundancy: payment info could be separate but not detrimental.

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?

Covers purpose, usage, behavioral traits, and payment. Missing clarity on return format (presumably text) and whether results are synchronous. With 4 params and no output schema, some 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 covers all 4 parameters with detailed descriptions, so baseline is 3. Description reinforces the PDF warning for imageBase64 parameter but adds no new semantic value beyond 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?

Description clearly states the tool analyzes images, answers visual questions, and extracts information. It distinguishes from sibling extract_document by explicitly noting single images only.

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 (visual analysis) and when not (PDFs/multi-page documents, recommending extract_document). Also mentions payment requirement and cost (21 sats per image).

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 behavioral burden and delivers: async semantics (returns requestId, poll with check_job_status), output trait (Native audio), quality behavior (2K is upscaled from 768p), cost model (priced per second by resolution), auth model (Bitcoin Lightning, no API key/signup), and a hard prerequisite (create_payment). This is unusually thorough behavioral disclosure for an unannotated tool.

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?

Three sentences with zero filler. The order is ideal: core purpose first, then async/audio behavior, then resolution/duration/pricing, then payment/auth and prerequisite. Every sentence earns its place and no information is repeated from the schema.

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, the description explains the return contract (requestId) and how to retrieve results (check_job_status), covering the async gap. It also addresses the payment dependency, the resolution billing quirk, and constraints that an agent must know to call this tool correctly. Nothing an agent needs to execute the full create_payment → animate_image → check_job_status flow is missing.

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 adds genuine value beyond the schema: naming 'MiniMax H3' clarifies what modelId's 'default model' actually is, and it reinforces the resolution and duration semantics (5-15 seconds, 768p/2K with upscaling note). The schema's resolution parameter is already extremely detailed, so the marginal gain is modest but real.

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+outcome: 'Animate a still image into cinematic video with MiniMax H3.' It clearly distinguishes this image-to-video tool from siblings like generate_video (no first frame needed), check_job_status (polling), and create_payment (payment) by framing the exact input ('first frame and a prompt') and the pipeline position. Nothing is left ambiguous about what the tool does.

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 workflow guidance: 'Requires create_payment with toolName="animate_image"' establishes the prerequisite, and 'Async — returns requestId, poll with check_job_status' tells the agent exactly how to use it after invocation. It does not explicitly state when-not-to-use or name an alternative (e.g., 'for text-only video use generate_video'), but the clear context makes the appropriate use evident.

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?

Beyond the readOnly and idempotent annotations, the description adds substantial behavioral detail: streaming vs. one-shot status check, the ~4 minute wait limit, timed_out=true behavior, and the fact that it is free with no payment. No contradiction with 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 dense but well-structured: the core purpose is front-loaded, followed by streaming behavior, timeout behavior, and equivalence to siblings. The final 'Free; no payment' is slightly extraneous but not harmful, and each sentence contributes useful operational detail.

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 absence of an output schema and the asynchronous nature of the tool, the description covers the key return states (COMPLETED, IN_PROGRESS with timed_out), streaming behavior, and retry semantics. It does not detail failure statuses, but the overall guidance is sufficient 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by tying requestId/jobType to specific async tool names and clarifying that jobType must match the tool that returned the requestId, which helps the agent choose the right enum value.

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: wait for an async job and return its result in one call, explicitly avoiding a manual polling loop. It distinguishes itself from the sibling tools by naming its relation to check_job_status and get_job_result as a combined equivalent.

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 clearly states the required inputs (requestId + jobType), lists the async tools that produce them, and explains the two modes depending on the Accept header. It also gives explicit retry guidance for long jobs, so an agent knows exactly how to use it and when to call again.

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 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.

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

Beyond the idempotentHint annotation, the description discloses the return JSON shape, special epub-audiobook fields, polling cadence, failure behavior, and the fact that the tool is free. This gives the agent a clear behavioral model of polling without contradicting 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?

The description is dense but every sentence carries operational value: usage context, return format, polling interval, completion routing, failure handling, cost, and exclusions. The most important purposestatement is front-loaded, and the structure flows naturally from when to use to what happens next.

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 an async polling tool with no output schema, the description fully compensates: it specifies statuses, response shape, special cases, polling timing, next steps, failure handling, cost, and synchronous-tool exclusions. Nothing critical for correct invocation or interpretation is missing.

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% and the schema already documents requestId and jobType in detail, including the mapping from jobType to the originating tool. The description reinforces that requestId comes from an async tool and that jobType must match, but it does not add substantial 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 opens with a specific verb and resource: 'Poll the status of an async job.' It also names the exact async tools that return requestId, which distinguishes it from siblings like get_job_result, check_payment_status, and await_result. The role of the tool 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 gives explicit when-to-use guidance: after calling an async tool that returns a requestId. It also states when NOT to use it (synchronous tools like generate_image and generate_text), gives a recommended polling interval, and spells out next steps for COMPLETED and FAILED statuses, including routing to get_job_result and avoiding automatic retries.

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 and idempotentHint=true. The description adds valuable behavioral context: the tool is free, does not require payment, explains the 'readyToUse' flag, mentions instant payment for most MCP clients, and details invoice expiration. No contradictions with 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 concise (5 sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, return fields, usage, expiry, and cost. No redundant or unnecessary 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?

For a simple one-parameter tool with full schema coverage and annotations, the description is nearly complete. It explains the return JSON, usage flow, expiry, and cost. However, it lacks error case handling (e.g., invalid paymentId) and could elaborate on the exact response shape, but these are minor 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 the parameter 'paymentId' already described as 'The paymentId returned by create_payment.' The description does not add additional parameter semantics beyond what the schema provides, so a 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 tool's purpose: 'Check whether a Lightning invoice has been paid.' It specifies the verb 'check' and the resource 'Lightning invoice payment status.' The return JSON fields are explicitly listed, distinguishing it from related tools like create_payment.

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 guidance: 'Call after create_payment to verify the user has paid before calling the target tool.' It also notes invoice expiry (10 minutes) and that a single check is usually sufficient, offering clear context for when and how to use the tool.

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 the full burden. It discloses the paid nature (7,500 sats), the prohibition of impersonation, the sample rejection upstream, and the return of a voice_id. It lacks details about asynchronous behavior or failure modes beyond sample rejection, but the key operational traits are covered.

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 somewhat long but each sentence adds essential information: core function, consent, sample requirements, modes, cost, and payment flow. It front-loads the main purpose and then provides necessary conditions. No fluff; structure is logical.

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 there's no output schema, the description explains the return value (voice_id). It covers payment prerequisites, sample constraints, and consent. It doesn't mention whether the operation is synchronous or where to fetch results if asynchronous, but the overall usage context is well covered for a paid cloning 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 schema already provides descriptions for all parameters (100% coverage), so a baseline of 3 applies. The description adds value by clarifying the payment flow (create_payment prerequisite) and the meaning of consent (ownership/permission attestation), which are not fully captured in the schema. It also reinforces sample requirements.

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 verb ('Clone') and resource ('a voice you own'), and clearly distinguishes from siblings like text_to_speech by noting it returns a reusable voice_id for TTS. It also differentiates from transcribe_audio and other voice tools by focusing on voice cloning.

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 provides explicit conditions: requires consent=true, sample requirements (format, duration, size, one speaker, no music), and payment via create_payment with toolName='clone_voice'. It implies when to use (when you need a reusable voice_id) but doesn't explicitly contrast with alternatives like text_to_speech or existing voice IDs. The preconditions are still clear enough.

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 provided, so description carries full burden. It discloses cost (5 sats), payment method (Bitcoin Lightning, no API key), and prerequisite step. Does not mention rate limits or time estimates, but otherwise 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?

Four concise sentences with front-loaded purpose. No unnecessary words; every sentence 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 annotations and no output schema, the description covers purpose, usage instructions, prerequisites, cost, and parameter details completely enough to use 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%, but description adds context: specifies that paymentId must be valid/paid, imageBase64 should be Base64-encoded grayscale/B&W image, and explains model_size enum and default.

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 explicitly states it colorizes black-and-white or grayscale photos, names the algorithm (DDColor), and highlights that it's impossible for text/vision LLMs, distinguishing it from siblings.

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 clear when-to-use guidance (colorizing B&W photos), mentions that it requires create_payment with toolName='colorize_image', and explains the pay-per-request model with Bitcoin Lightning.

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?

Discloses that no new payment is needed and that it returns a call_id for polling. Annotations only provide openWorldHint, so description adds behavioral context. Could be improved by mentioning that answers are optional and the tool will proceed as-is if omitted.

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?

Three well-structured sentences, each conveying essential information: action and context, prerequisite, financial implication, and return value. 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?

Despite no output schema, description specifies the return value (call_id for polling). It covers prerequisite, usage, financial impact, and next steps. Additional context like error handling would elevate but is not necessary 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?

Schema descriptions cover both parameters. Description adds value by explaining that 'answers' keys are question strings and values are answers, and that omitting them confirms as-is. This clarifies usage beyond 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?

Clearly states the action ('Confirm an AI call') and the context ('after reviewing push-back questions, optionally providing answers to missing info'). Distinguishes from sibling tool ai_call by specifying the prerequisite state 'pending_confirm'.

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 when to use: 'Required when ai_call returns state="pending_confirm"'. Also notes financial aspect ('Uses the original payment — no new payment needed') and subsequent polling step ('Returns call_id for polling with check_job_status(jobType="ai-call")').

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 the behavioral disclosure burden. It does well by disclosing the payment prerequisite, exact cost, output form (download URL), and quality preservation. Missing details like synchronous vs asynchronous execution and any file size limits slightly lower the score.

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 core capability and format examples, then efficiently covers payment, authentication, and output. The phrase 'Industrial-grade conversion engine' is slightly promotional but still conveys quality, and the rest of the sentences carry needed operational 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?

The description covers the main workflow preequisites and output but leaves gaps: it never states that a file input is mandatory through one of fileUrl/fileBase64, doesn't mention potential async behavior/job status, and gives no size or compatibility limitations. Since there is no output schema or annotations, these omissions leave an agent with only partial guidance for a complex paid conversion operation.

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 3 is the baseline. The description adds meaning beyond the schema by explaining that paymentId comes from create_payment with toolName='convert_file' and that conversion covers 200+ formats, giving context to extensionFrom/extensionTo. It could be more explicit that either fileUrl or fileBase64 must be supplied, but the schema already conveys that alternative.

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 verb and resource: 'Convert files between 200+ formats' and enumerates document, image, audio, and video categories. This clearly distinguishes it from more specialized siblings like merge_pdfs and epub_to_audiobook by scope and format coverage.

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 provides clear usage context: conversion costs 100 sats, requires a prior create_payment with toolName='convert_file', and requires no API key or account. However, it does not explicitly mention when to prefer specialized siblings such as convert_html_to_pdf over this generic converter, so it falls short of full routing 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 present, but description fully discloses return format (JSON with temporary URL, 1-hour validity), cost (50 sats), payment requirement (create_payment), and input support (HTML/CSS, base64 images). Transparent about all behavioral aspects.

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?

Description is informative but slightly verbose; could be tightened. However, it is well-structured and front-loaded with the core purpose.

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, description fully explains return format. Covers all essential aspects: input, format, output, cost, prerequisites, and alternatives. Complete for a tool with simple parameters.

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?

Although schema covers parameters 100%, description adds context: explains paymentId's origin, format options, and the purpose of html content. Also implies output structure beyond 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 converts HTML or Markdown to PDF, with specific use cases (invoices, reports) and distinguishes from sibling tool convert_file for existing file conversions.

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: generating documents, setting format='markdown' for Markdown. Also gives alternative: 'Use convert_file instead for converting existing files.'

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 the full behavioral burden and does so: 10-minute invoice expiry, one-payment-per-call semantics, price locking at payment time, and the enforcement rule that under-payment is rejected at execution (sometimes with refund). These are exactly the traits an agent cannot infer from the schema alone.

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?

Front-loaded with purpose, return shape, and flow before descending into the per-tool pricing table. It is long, and the pricing details partially duplicate the 100%-covered schema descriptions, but nearly every sentence conveys a constraint the agent must respect.

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 16-parameter payment tool with no output schema, the description supplies the return shape ({ paymentId, invoice, amount, expiresAt }), the lifecycle sequencing, and the pricing/enforcement model. An agent has enough to call it correctly without further exploration.

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 already 100%, so the baseline is 3, but the description adds genuine semantic value: modelId is optional with a default, quantity defaults to 1 and under-counting is rejected, and per-tool required params (prompt, text, phoneNumber, characterCount, durationMinutes) are tied to pricing formulas. It stops short of explaining every one of the 16 params (e.g. fileContext, generate_audio behavior is left to 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 first sentence names a specific verb and resource ('Create a Lightning invoice') and states its exact scope: paying for one AI service call. That scope cleanly separates it from sibling cost/estimate tools (get_cost_estimate, get_model_pricing) and from the actual work tools it fronts.

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?

Gives an explicit ordering ('list_models → create_payment → check_payment_status → call tool'), the cardinality rule ('call this once per operation'), and a per-tool map of which extra params must be supplied at payment time. It also names the failure mode when required params are missing.

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?

Even without annotations, the description discloses several behavioral traits: the underlying model (NAFNet), processing time (~2 min), payment model (110 sats, Bitcoin Lightning), and the need to call create_payment first. It doesn't explicitly mention async result retrieval, but it provides meaningful context beyond basic functionality.

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 but information-dense. It flows logically from purpose to model to usage guidance to pricing and prerequisites. Every sentence contributes value, though the density of the last two sentences about payment could be slightly restructured 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 tool's purpose, limitations, pricing, and required prerequisite (create_payment). It doesn't mention the return format or potential error cases, but given the lack of output schema, these omissions are minor. Overall, it provides sufficient context for an agent to decide whether to use the tool and how to invoke it.

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 all parameters already well-described (including enum meanings and defaults). The tool description adds no new parameter-level information but confirms the task_type options and data URI support, which is already in the schema. 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 uses a specific verb ('recover detail') and names the resource ('camera-shake and accidental motion blur'), and it distinguishes the tool from siblings by clarifying what it does and does not handle (e.g., not artistic motion blur). It also mentions a secondary use (denoising), which adds clarity.

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 ('handheld shake, bumped camera, whole-frame uniform blur') and when not ('intentional panning blur, bokeh/depth-of-field, artistic motion effects'). Also includes cost and payment requirements, giving clear context for practical use.

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, so description must cover behavior. It discloses cost (2 sats), payment flow, faster/cheaper than LLM, and returns label and boolean. Does not mention rate limits or destructive effects, but nothing contradictory.

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?

Concise paragraph front-loads core function, then adds pricing and payment details. No redundant sentences; every sentence 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?

With no output schema, description explains return values. Covers use case, pricing, payment flow, and image format. Complete for a simple two-param 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 both params. Description adds context: paymentId must be valid/paid, imageBase64 can be data URI or formats. Reinforces workflow requirement, adding marginal value beyond 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?

Description clearly states the tool classifies image safety into normal/suggestive/explicit, returns a label and boolean flag. It distinguishes itself from siblings like detect_objects by specifying NSFW detection and unique pricing.

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 use for content moderation pipelines and is cheaper/faster than LLM. Mentions payment requirement via create_payment. Lacks explicit when-not-to-use or alternative tools, but context is provided.

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 provided, so the description carries full burden. It discloses the model (Grounding DINO), the payment mechanism, and the type of output (bounding boxes, scores). However, it lacks detail on error handling, image size limits, or format restrictions beyond the schema.

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 front-loaded with the core purpose. Each sentence adds value, though the payment instruction could be slightly more integrated. 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?

The description covers the tool's purpose, output type, payment model, and prerequisites. It lacks explicit error scenarios but is fairly complete given good schema coverage and no output schema. Minor gaps in behavioral details.

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 adds natural language context for the query parameter but does not elaborate on box_threshold or text_threshold beyond the schema. 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 detects and locates objects by name, using Grounding DINO, and provides structured output (bounding boxes, confidence scores). This distinguishes it from sibling tools like 'analyze_image' or 'generate_image'.

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 explains the payment flow (5 sats per image, Bitcoin Lightning, no signup) and the prerequisite 'create_payment'. It contrasts with vision LLMs but does not explicitly mention sibling tools like 'analyze_image' as alternatives or specify when not to use this tool.

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 behavioral burden and does a solid job: it discloses the flat 200 sats price, that payment is per-request via Lightning with no API key/signup, the required payment precondition, and the return shape ('JSON with image URL'). It stops short of latency, failure/refund behavior, or input size limits.

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?

Front-loaded with the action, then capabilities, return, price, and payment flow in a logical order. The leaderboard-ranking clause is marketing filler that consumes a sentence without helping invocation, keeping it out of 5 territory.

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 7-param, no-output-schema, no-annotation tool, the description supplies the essentials an agent needs: what it returns, how to pay, and the required prerequisite call. It is not fully complete — no error/refund or input-size guidance — but nothing critical is missing for a 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?

Schema description coverage is 100%, so every parameter including the unusual 'resolution is ignored' note is already documented in the schema. The description adds no parameter-level detail beyond the schema (returnBase64/base64Image tradeoff is explained in the schema, not here), so the 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?

States a specific verb+resource ('Edit an image with natural language instructions') and immediately scopes the capability set (object addition/removal, style transfer, inpainting). This clearly separates it from siblings like generate_image, remove_object, upscale_image, and colorize_image.

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?

Gives a hard prerequisite ('Requires create_payment with toolName="edit_image"') and the pricing model, which tells the agent when the tool is callable. It does not, however, say when to prefer this over generate_image or remove_object for overlapping edits, so sibling routing is left to inference.

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 provided, so description carries full burden. It discloses side effects: finalizes billing, returns refund link for unused deposit, and returns final transcript. Good disclosure beyond basic action.

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 the main action, no unnecessary words. All information is essential.

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 one parameter and no output schema, the description adequately covers all needed information: what the tool does and what it returns.

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 a clear description for sessionId. Tool description adds no further detail 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 the verb 'Hang up', the resource 'Voice Bridge call', and additional actions like finalizing billing and returning refund link and transcript. It effectively distinguishes from siblings like 'open_voice_bridge'.

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?

Implied usage after starting a voice bridge call, but no explicit guidance on when not to use or alternatives. Could mention that polling might be needed before ending.

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 and does so richly: async behavior with jobId polling, expected 5-60+ min duration, minimum 500 sats cost, per-tier throughput (chars/sat), single-payment full-outcome model, and the requirement that payment must be completed first. This is exactly the operational context an agent needs before invoking.

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 first sentence front-loads the purpose and capabilities, followed by tier, pricing, async, and payment details in a logical order. It is dense and somewhat repetitive with the schema's own voice/tier text, but nearly every sentence carries operational 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?

For a complex 9-parameter, no-annotation, no-output-schema tool, the description covers the full lifecycle an agent must understand: prerequisite payment, async polling, timing bounds, cost floor, and voice-tier/translation constraints. Nothing essential for correct invocation is missing.

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 schema itself is extremely detailed about voice IDs, tier constraints, language vs translateToLanguage, and chapter indices. The description largely restates tier and payment facts rather than adding new parameter-level meaning, so it sits at the baseline for a fully documented 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?

States a specific verb and resource — converting EPUB/PDF/TXT books into full audiobooks — plus the differentiators (chapter detection, multi-voice narration, optional translation). It is clearly distinguishable from siblings like translate_epub and text_to_speech without opening any schema.

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?

Explains the invocation context well: payment is required first via create_payment with toolName='epub_to_audiobook', the call is async and must be polled, and no API key/signup is needed. It does not explicitly name alternative sibling tools or state when-not-to-use this one, so it falls 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 behavioral burden and does so excellently. It discloses the async turnaround time, that the API reply is only an acknowledgment, that polling is not needed, that the PDF is processed in memory and never stored, and that payment is via Bitcoin Lightning with no account or card.

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 compact and front-loaded with the primary purpose, then covers pricing, async behavior, privacy, and payment prerequisites in a logical order. Every sentence adds meaningful operational detail; there is no fluff or repetition.

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 paid, async, privacy-sensitive tool with no output schema, the description is remarkably complete. It covers what the tool does, the prerequisite payment step, expected delay, the acknowledgment-only reply, privacy handling, cost, and payment method. Nothing critical is missing for an agent to invoke it 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the flat 1000 sats pricing, the requirement to first create a payment with toolName='e_signature', and the expectation that the signed copy is emailed to the customer. It doesn't deeply elaborate every parameter, but the schema already does that.

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 verb and resource: send a document out for legally binding e-signature, with the signed copy emailed back. It clearly differentiates from siblings like send_email or send_fax by focusing on the signature workflow and provider-based fulfillment.

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 clear context on when to use the tool: for legally binding e-signatures with multiple signers and async delivery. It also names the necessary prerequisite create_payment with toolName='e_signature' and explicitly says there is nothing to poll. It does not name alternatives or when-not-to-use cases, but the use case is sufficiently distinct.

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 the full burden. It discloses cost (5 sats), payment method (Bitcoin Lightning), prerequisite (create_payment with toolName='estimate_depth'), and output formats. It does not mention error handling or side effects, but for a non-destructive compute API, 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 front-loaded with purpose, then output details, then cost/payment. It is concise but includes a bit of marketing (NeurIPS 2024, 3.8M+ runs) that is not strictly necessary, making it slightly verbose. Still well-organized.

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 explains the return (both raw and colour maps) and the primary use cases. It also covers payment prerequisites. It lacks details on error codes or image format limits, but those are often documented elsewhere, and the description is sufficient for a typical 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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning about the parameters—paymentId, model_size, or imageBase64—beyond what the schema 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?

Description states a clear verb+resource: 'Estimate per-pixel depth from a single photo.' It specifies the output (raw greyscale depth map and colour visualization) and distinguishes from siblings like analyze_image or detect_objects, which serve different analytical functions.

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 context on when to use: for ControlNet, AR, or 3D reconstruction pipelines needing structured geometry that vision LLMs cannot produce. However, it does not explicitly exclude cases or name alternative tools, so it falls short of explicit when/when-not 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 provided. Description discloses cost (10 sats/page) and payment flow, but lacks details on size limits, supported languages, error handling, or whether operation is destructive. Adequate but not exhaustive.

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?

Four sentences, front-loaded with purpose, then capabilities, cost, and prerequisite. No redundant 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?

Covers key aspects: purpose, capabilities, cost, payment prerequisite. Lacks output format detail (though Markdown is mentioned) and error handling. No output schema to compensate, but overall sufficient for typical 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 covers 100% of parameters with descriptions. Description adds value by explaining the paymentId must be obtained via create_payment and that documentBase64 is base64 encoded, beyond schema details.

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 extracts text from PDFs and images as clean Markdown, specifying handling of complex layouts, tables, handwriting, etc. This distinguishes it from siblings like analyze_image or convert_file.

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 mentions prerequisite payment via create_payment with toolName and quantity, and that no API key is needed. Does not compare to alternatives like convert_file for document extraction, but the context is clear.

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 exist, so the description carries the burden. It discloses the payment flow, pricing (25 sats/page), dual-model pipeline, and robustness claims. The caveat about hallucinated JSON for non-receipts is present in the schema but not in the description, so the description alone understates that risk.

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?

Five sentences, each information-dense: purpose, method, output, robustness, and pricing/payment. No filler or redundant phrases; 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?

Covers purpose, return JSON fields, payment prerequisite, and edge-case handling. Since there is no output schema, listing the fields compensates. The hallucination warning is in the schema, so overall the description is complete for a paid extraction tool, though it could have briefly noted non-receipt 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 baseline is 3. The description adds context for paymentId by referencing create_payment and hints at documentBase64 format via 'multi-page invoices' and 'crumpled receipts' — slightly beyond the schema's basic parameter description.

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 'Extract structured data from receipts, invoices, and financial documents' — a specific verb plus resource scope. It distinguishes itself from sibling tools like extract_document by narrowing to financial paperwork, and adds detail about the dual-model pipeline and output fields.

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 clear usage context: requires create_payment, pay-per-request with Lightning, and no API key needed. It does not explicitly name a sibling alternative or state when not to use this tool, but the purpose and prerequisite are well explained.

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 carries the burden. It transparently discloses async behavior ('Async — returns requestId, poll with check_job_status'), cost ('1600 sats per model'), and the authentication model ('no API key or signup needed'). It also names the underlying model (Tencent Hunyuan3D), adding significant behavioral context beyond the schema.

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 composed of six short, information-dense sentences: purpose, model/provider, async behavior, cost, payment method, and prerequisite. No fluff or repetition; every sentence 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 the tool's complexity (async, paid, multi-input) and lack of output schema, the description covers all essential aspects: input formats, output type, provider, cost, payment flow, and follow-up polling. It is sufficiently complete for an AI agent to invoke the tool 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 coverage is 100%, so the baseline is 3. The description adds payment context ('Requires create_payment with toolName='generate_3d_model'') relevant to the paymentId parameter, and reinforces the exclusive-or relationship between prompt and imageBase64, though this is already in the schema. This modest addition justifies a 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 opens with 'Generate a textured 3D GLB model from EITHER a photo OR a text prompt,' clearly stating the tool's function and output format. This distinguishes it from sibling 2D generation tools like generate_image and generate_video.

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 constraints ('provide exactly one, not both') and outlines the async workflow ('poll with check_job_status') and payment prerequisite ('Requires create_payment with toolName='generate_3d_model''). While it doesn't explicitly compare to alternative 3D tools, no other 3D generation tool exists in the sibling list, so the guidance is clear and actionable.

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 the behavioral transparency burden and does so thoroughly. It discloses the JSON return format, model-specific costs, default model behavior, img2img support, stable endpoints with automatic model upgrades, Bitcoin Lightning payment, and no API key/signup requirement.

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?

Although longer than many descriptions, every sentence earns its place: purpose and return type are front-loaded, then models/pricing, parameter nuances, pricing stability, and the payment prerequisite. The structure is dense without irrelevant 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?

For a paid, 5-parameter tool with no output schema and no annotations, the description is largely complete: it covers return shape, model selection, costs, defaults, img2img, aspect ratio effects, auth/payment, and stability guarantees. It only omits potential async/retrieval or error-handling behavior, which would make it fully 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?

The input schema already describes every parameter with high coverage, so the baseline is 3. The description adds meaningful extra context beyond the schema by providing model names, pricing, the default model default, aspect-ratio price neutrality, and the payment prerequisite, which helps an agent choose and invoke parameters correctly.

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: "Generate an image from a text prompt," and states the return value as JSON with an image URL. It is clear about text-to-image and img2img support, though it does not explicitly differentiate itself from sibling tools like edit_image or generate_text.

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 provides strong usage context: when to use the tool, model selection guidance, default model behavior, pricing tiers, and the prerequisite that create_payment must be called first. It does not give explicit exclusions or say when to choose an alternative sibling instead.

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 behavioral disclosure: it reveals pricing (5 sats/second), output format (44.1 kHz 16-bit stereo WAV URL), the silent lyric-dropping behavior on tag lines, and the payment binding requirement. No contradictions with annotations (none exist).

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 long but every sentence adds value: it covers purpose, modes, pricing, constraints, payment flow, and return format. It is front-loaded with the core action and then provides necessary details. Slightly dense but not bloated.

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 7 parameters, a payment dependency, and no output schema, the description is remarkably complete: it explains the return format, the tag syntax pitfall, pricing, duration limits, and the create_payment correlation. Nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description adds meaningful cross-parameter context such as the price binding to duration and the requirement that lyricsAddon also be sent to create_payment. This goes beyond the individual parameter descriptions in 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 a specific action ('Generate a full song') with distinct modes (vocals vs instrumental), and it differentiates itself from sibling generate_* tools by specifying music-specific outputs and the payment model. The verb and resource are 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?

Provides explicit instructions on when to use lyrics vs instrumental tags, when to enable lyricsAddon, and the required create_payment prerequisite with matching duration. It also covers the optional lyricsAbout flow, leaving no ambiguity about 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?

With no annotations, the description carries the full burden and does substantial work: it discloses per-character pricing, BTC-pegged rates re-quoted hourly, the 402 challenge as authoritative price, auto-upgrading models, and a no-API-key Lightning payment flow. It omits return-shape, latency, and failure behavior, so it is rich but not complete.

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?

Front-loads the core action and keeps the dense pricing/model/payment detail in a single tight paragraph. Given the tool's complexity the length is justified, though the parenthetical pricing and rate caveats add some density an agent could skim past.

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 an 8-parameter, no-annotation, no-output-schema tool, the description covers purpose, payment gating, model selection, and file context well. The notable gap is that with no output schema present, nothing describes what a successful response actually returns.

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, but the description adds real meaning to modelId by naming the models, their tradeoffs (context length, languages, best vs best value), and defaulting behavior, and it links fileContext to document Q&A. Other params are left entirely to 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?

States a specific verb+resource ('Generate text') and immediately narrows scope with model choices and capabilities (Q&A via fileContext). It explicitly separates itself from the image path by pointing at analyze_image, letting an agent distinguish it from siblings without opening the schema.

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?

Gives clear context (text completion, document Q&A), an explicit exclusion ('For images, use the analyze_image tool'), and a prerequisite workflow ('Requires create_payment with toolName="generate_text"'). It does not, however, distinguish this from other text-oriented siblings such as ai_call or multilingual_ask, which an agent must resolve on its own.

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?

Discloses async behavior (returns requestId for polling), payment requirement, and that audio is always on (no silent render). Explains retired resolution rungs and the constraint on reference_audio. This goes beyond the schema, which has no annotations, so the description fully carries behavioral transparency.

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?

While detailed, every sentence serves a purpose—pricing, async flow, parameter constraints, and behavioral notes. Structured logically from core purpose to specifics, with clear separate sentences per aspect. No 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?

Covers all necessary operational details: payment prerequisite, async polling, parameter constraints (audio requires image), resolution behavior, and retrieval flow. Given the complexity and absence of an output schema, the description is complete for an agent to invoke 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?

Adds crucial semantics for each parameter: resolution explains retired rungs and default, generate_audio is ignored, reference_audio requires a reference_image, and reference_image is for character consistency. The schema only lists definitions, so the description enriches meaning significantly.

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 and resource: 'Generate cinematic video from a text prompt.' Clearly distinguishes from siblings like generate_image and generate_music, and names the model (MiniMax H3) and key capabilities (native audio).

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 usage instructions: async operation requiring create_payment, the need to pass reference_audio with at least one reference_image, and how resolution and audio options behave. Also notes that generate_audio is ignored and that 2K is upscaled from 768p, giving practical when-to-use 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?

Annotations already set readOnlyHint=true and idempotentHint=true. Description adds 'No payment required, no side effects' which reinforces safety. Also describes return values (amount_sats, breakdown, currency). 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?

Four sentences, no filler. Front-loaded with purpose. Every sentence adds value: purpose, usage context, examples, return format, alternative behavior.

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?

Covers purpose, usage, examples, return fields, and behavior with/without params. No output schema but description mentions return structure. Could clarify that service must be a valid identifier from catalog, but that's minor.

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 param. Description adds real usage examples (service=text-to-speech&chars=1500) and explains that omitting params lists all services. This goes beyond schema details.

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 it provides an exact sat cost quote for a service before payment. Verb 'Get' and resource 'cost estimate' are specific. Distinguishes from sibling tools like create_payment, check_payment_status by focusing on pre-payment price checking.

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 'Useful for budget-aware agents to price-check before committing' which sets context. Provides example usage patterns (service=...). Does not explicitly state when not to use or alternatives, but context from sibling tools implies this is the estimation step.

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 readOnly and idempotent hints; the description adds 'No payment required' as extra behavioral insight, without contradicting 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 sentences: the first states the purpose with concrete examples, the second gives actionable usage guidance. No wasted words, front-loaded with key info.

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 provides purpose and usage guidance for a simple no-parameter tool; while it could detail the output format, the examples suffice for an agent to understand the expected result.

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?

No parameters exist, so schema coverage is complete; the description naturally has no need to explain parameters, meeting the baseline for 0-param tools.

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 explicitly states the tool retrieves a machine-readable catalog of error codes, with specific examples, clearly distinguishing it from sibling tools by focusing on error code retrieval.

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 advises branching on error_code over parsing text and notes no payment required, providing clear context for when to use this tool, though it does not explicitly exclude 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 already declare readOnlyHint and idempotentHint; the description adds significant behavior beyond them: premature calls error, temporary URLs expiring after about an hour, and that the tool is free. There is no contradiction with 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 purpose and usage guidance, and every remaining sentence earns its place: output shapes, URL expiry, free status, and sync-tool exclusion. The length is justified because no output schema exists.

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?

This is rich but incomplete: the jobType enum includes 10 values, yet the return-shape mapping covers only 5 buckets and omits video-fal-standard/video-fal-pro, transcribe-translate, and translate-epub. Since there is no output schema, those shape gaps are meaningful for an agent invoking those variants.

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 does not add parameter-level semantics beyond mapping jobType to return shape, while the schema already explains requestId, jobType, and paymentId. Thus the description neither needs to compensate heavily here.

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?

Starts with a specific verb and resource: 'Retrieve the final output of a completed async job,' which clearly separates it from status-checking and synchronous tools. It clearly identifies the tool as the result-fetch step in the async workflow.

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 the precondition: 'Call ONLY after check_job_status returns status="COMPLETED"' and warns that early calls return an error. It also says not to use it for synchronous tools, directly naming the alternative behavior.

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 and idempotentHint, and the description adds a valuable behavioral note: 'No payment required.' This goes beyond the safety profile, clarifying the endpoint will not incur a charge. 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 short sentences, both purposeful: the first states the core operation, the second provides a useful billing caveat. No filler words or redundancy. Front-loaded with the verb and object.

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 read-only, idempotent lookup with one fully documented parameter, the description notably covers the operation and an important behavioral caveat. The lack of return-format information is acceptable given the tool's simple nature and absence 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?

Schema description coverage is 100%, and the description does not add material meaning beyond 'by ID.' The schema already explains the modelId comes from list_models and that numeric strings are accepted. The description adds no new semantic detail.

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 clear action ('Get pricing') and resource ('for a specific model by ID'). It is distinct from sibling tools like get_cost_estimate, though it does not explicitly name alternatives to aid disambiguation.

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?

No guidance on when to use this tool versus alternatives such as list_models or get_cost_estimate. It implies usage through 'by ID' but provides no prerequisites, exclusions, or alternative routing. 'No payment required' does not explain when to choose this.

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?

Even with readOnlyHint and idempotentHint annotations already present, the description adds meaningful behavioral facts: it is free and requires no payment, it returns a JSON array with a specific shape, and models with isDefault=true affect create_payment when modelId is omitted. It also reassures that repeated calls are safe, extending the idempotent hint with practical guidance. No annotation is contradicted.

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 densely informative with a clear front-loaded purpose and a logical flow: what it returns, when to call it, how the default flag behaves, how to filter, and cost/safety notes. Each sentence contributes value, though 'free' and 'requires no payment' are mildly redundant and the default-model detail could be considered extra context for create_payment rather than list_models itself.

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 read-only tool with one optional parameter and no output schema, the description covers everything an agent needs: return format, exact fields, meaning of isDefault, category filtering, and cost/ree behavior. It fully prepares the agent to call correctly and interpret results, making further documentation unnecessary.

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% and the single optional category parameter is already described as a filter matching tool names. The description adds only a slight clarification that filtering narrows results to a specific tool, which is a near paraphrase rather than substantive new semantics. The schema carries the parameter heavy lifting, so a 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 uses a specific verb ('Discover') with a clear resource ('available AI models') and enumerates the exact attributes returned: numeric IDs, tier labels, capabilities, and per-call pricing. It distinguishes itself from siblings like get_model_pricing by framing the tool as the discovery/preparation step for create_payment. An agent can confidently understand what this tool does without ambiguity.

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 before create_payment to find the right modelId, and explains filtering by category to narrow results to a specific tool. It provides clear usage context but does not explicitly contrast with overlapping siblings such as get_model_pricing, so it stops short of a full when/when-not alternatives statement.

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 indicate readOnlyHint and idempotentHint. Description adds that it returns a sorted JSON array with specific fields, and that it's safe to call repeatedly, providing useful behavioral context 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?

Extremely concise: three sentences that front-load the purpose, then detail output and usage guidance. Every sentence 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 no parameters and no output schema, the description fully specifies the return format and behavior. No gaps remain for an agent to select and invoke this tool 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?

No parameters exist, so baseline is 4. Description adds value by explaining the output format and sorting, which helps an agent understand what the tool returns without needing parameter details.

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 uses specific verb 'List' and resource 'planned services' with current vote counts. It distinguishes from sibling tools like vote_on_service by clarifying this is for viewing, not voting.

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 no payment required, it's a free discovery tool, and directs to use the slug values with vote_on_service for casting votes. This clearly explains when to use this tool versus 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?

No annotations provided, so description fully carries the burden. It discloses bookmark preservation, temporary URL, cost, concatenation order, and payment requirement. Minor omission: no error handling details.

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?

Concise and well-structured: first sentence states purpose, each subsequent sentence adds critical details without redundancy. No 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?

Given no output schema and no annotations, the description fully explains return format, temporary URL, pricing, and alternative tool, making it sufficient 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?

Schema coverage is 100%, so baseline is 3. Description adds value by specifying base64 encoding, minimum files, and concatenation order, slightly improving clarity.

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 'Merge multiple PDF files into a single document' with specific verb and resource. It distinguishes from the sibling 'convert_file' by mentioning format conversion as an alternative.

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?

Explicit when-to-use: 'Use convert_file instead if you need format conversion'. Also provides constraints like 'Minimum 2 files, no maximum' and payment details.

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 the full behavioral burden, and it delivers: payment requirement, one-payment model, translation pipeline, LLM vs MADLAD-400 fallback tiers, uneven rare-language quality, published per-language quality, and pricing structure. It does not specify whether the answer returns synchronously or via a job/result mechanism, which is a minor gap.

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 long but information-dense and front-loaded with the core action, followed by important operational and pricing details. Every sentence contributes substantive context, though the structure is a bit sprawling with several clauses in quick succession.

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 paid endpoint with no output schema and meaningful dependencies, the description is quite complete: it covers the payment prerequisite, language coverage, fallback behavior, quality variability, and cost model. It could additionally explain the answer return format or whether the call is asynchronous, but the core information needed to invoke it correctly is present.

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, but the description adds meaningful cross-parameter semantics: the create_payment quote must match the chosen language and tier, the model choice must match that quote, and the rare-language path costs more. It also highlights that unsupported languages are rejected before payment, reinforcing the language parameter's validation behavior.

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 ('ask'), a specific resource (frontier AI), and the distinctive same-language behavior in the first sentence. It clearly differentiates itself from translation-only siblings like translate_text and translate_rare_language by framing the tool as question-answering, not translation.

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?

Clearly establishes when to use the tool (ask a question in your own language and get a frontier-model answer back in that language) and gives a strong prerequisite: create_payment must be called with toolName='multilingual_ask' and the intended language. It does not explicitly name sibling alternatives to exclude, 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?

Discloses major behavioral traits: not real-time, per-turn latency (2.5-4s), no completion signal, refund mechanics (with/without refundAddress), privacy (in-memory, 30-min GC, no audio persistence), deposit pricing, refuses premium/satellite ranges. Annotations only say openWorldHint, so the description carries full burden and excels.

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?

Dense but every sentence earns its place. Front-loads core workflow (how turns work), then warnings, use cases, exceptions, privacy, payment. Though long, it is structured logically and avoids 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 complex, high-stakes tool (payment, privacy, multiple modes), the description covers workflow, prerequisites (create_payment), refund, privacy, and constraints. No critical gaps found; output schema absent but return format is described via emitted signals.

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 covers 100% of params, so baseline is 3. Description adds meaning for key params (greeting recommendation, refundAddress benefits, duration deposit, codec default). Does not explicitly map all params but schema is complete.

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 specific purpose (open a call you drive turn-by-turn) and contrasts with ai_call (real-time agent) and place_call (one-shot). Distinguishes clearly from siblings.

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?

Explicit when-to-use (turn-paced, privacy-critical, refund, etc.) and when-not-to-use (real-time, one-shot, polling overhead). Names alternatives (ai_call, place_call) directly.

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 many behavioral traits: requires payment via create_payment, includes unverified-sender notice, consent is not established by answering, requests are screened, refund policies, data retention. It complements the destructiveHint annotation by explaining the process. No 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?

The description is a long block of text with extensive policy and legal details, making it not concise. It could be structured with headings and trimmed to the essential operational details.

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 and lack of output schema, the description covers many aspects like payment and consent, but it does not explain what the tool returns (e.g., call ID, status) or how to obtain the paymentId beyond mentioning create_payment. This is a gap for an agent to call it 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 descriptions cover all parameters at 100%. The description does not add significant meaning beyond the schema, only reiterates that message or audioUrl must be provided and durationMinutes required for audioUrl.

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 places an automated phone call to deliver a spoken message or play audio. It specifies the resource (phone call) and action (place). However, it does not differentiate from sibling tools like ai_call or confirm_ai_call, so it's not fully distinguished.

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 provides some usage context (notifying a human, delivering alerts) but does not explicitly state when to prefer this over alternatives. There is no mention of exclusions or 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?

No annotations provided, so description carries full burden. It mentions returns types (partial + final transcripts, system events) and payment, but lacks disclosure on side effects, idempotency, or safety (e.g., read-only nature). 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?

Three sentences: core function, return types, usage advice. No fluff, front-loaded with essential info.

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, description explains return types but not structure details or error handling. Parameter count low, usage guidance provided. Lacks depth on potential empty returns or system events composition.

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 100% with descriptions. Description adds default for cursor (0) and origin of sessionId. Text clarifies polling behavior and cursor usage, exceeding schema info.

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 specifies the verb 'Fetch', resource 'transcript events from an open Voice Bridge call', and scope 'since the last cursor'. It clearly distinguishes from sibling tools like voice_bridge_say and end_voice_bridge.

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 poll in a loop at ~500ms-1s interval and notes no additional payment. Provides clear usage context but does not mention when not to use or contrast with 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?

Despite only the 'openWorldHint' annotation indicating external interaction, the description richly discloses behavioral traits: 24-hour receive window, caller ID matching (last 10 digits), email delivery, optional OCR (+200 sats) with partial refund on failure, optional HMAC-signed webhook callback, and the no-refund policy to prevent squatting. Payment via Lightning is also noted. These details go well beyond the annotation's minimal information.

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 paragraph of ~120 words, efficiently covering the main purpose, constraints, optional features, and policies. It is front-loaded with the primary use case. While dense, every sentence adds necessary information, making it concise for the tool's complexity. Minor improvement could be bullet-style structure, but current form is clear.

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 effectively explains the delivery process (email, OCR, webhook) and constraints. It covers the immediate action (opening a window) and post-delivery behavior. However, it does not describe the immediate tool response (e.g., a confirmation or window ID), which may be needed for subsequent steps. Still, the description is fairly complete for a tool with offline delivery.

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 each parameter having a description. The description adds value by explaining the OCR add-on cost, the HMAC-signed webhook behavior, and the caller ID matching for fromNumber. It contextualizes the parameters within the use case. However, it does not add significant detail beyond the schema for email, paymentId, and callback_id, keeping the score just above baseline.

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: 'receive a fax' at a shared number, with delivery to email. It specifies the use case ('when expecting a fax back') and distinguishes from sending (sibling 'send_fax' exists). The verb 'receive' and resource 'fax' are specific, and the description contrasts with dedicated number rental, making 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?

The description provides explicit context for when to use the tool ('When you're expecting a fax back') and mentions the 24-hour window and no-refund policy. It does not directly state when not to use it, but the context is clear. Alternative tools (like send_fax) exist among siblings, but no explicit exclusion is given. The guidance is helpful but lacks explicit 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 fully carries the burden of behavioral disclosure. It covers cost (44 sats per image), payment method (Bitcoin Lightning, no API key), model stability (upgrades automatically), and output format (transparent PNG). It also notes the required payment flow. This is substantial transparency for a simple image operation.

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 front-loaded with the core purpose. It includes additional context on model quality, pricing, and payment prerequisites, all relevant to an agent's decision-making. Each sentence adds value, though the model benchmark could be considered non-essential; it is not verbose.

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 is simple, but with no output schema, the description should clarify how the transparent PNG is returned (e.g., base64 string, URL). It only says 'returning transparent PNG' without specifying the structure. The payment prerequisite is well-covered, but the lack of return-value encoding details leaves a moderate gap.

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 provides full descriptions for both parameters: paymentId and imageBase64, achieving 100% coverage. The description adds no additional parameter-level details beyond restating the payment requirement and image flexibility. With full schema coverage, 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 starts with a clear and specific statement: 'Remove background from any image, returning transparent PNG.' This verb-resource pair is unambiguous and differentiates it from sibling tools like remove_object or edit_image. The additional detail about handling complex edges further solidifies its purpose.

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 context for when to use the tool: any time you need background removal, especially for complex subjects like hair or glass. It also states the prerequisite of calling create_payment with toolName='remove_background'. However, it does not explicitly mention alternatives or when not to use it, only giving implied 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the underlying models (Grounding DINO and Bria Eraser), the cost (130 sats per image), the payment flow (Bitcoin Lightning, create_payment prerequisite), and the expected behavior (object erased and filled convincingly). This is substantial, though it does omit potential failure modes or output format.

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 core purpose and remains reasonably concise. It includes some technical details (e.g., 'Grounding DINO detection (ECCV 2024)') that are informative but not strictly necessary for an AI agent to select or invoke the tool. Overall, every sentence serves a function: purpose, model context, examples, pricing/auth, and prerequisite.

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 complexity (5 params, no output schema, no annotations), the description covers payment, usage, and cost well, but it does not explain what the tool returns or whether the operation is asynchronous (e.g., whether the agent must poll with await_result or get_job_result). This is a significant gap for an agent that needs to handle the result 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?

The input schema already covers all 5 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by giving concrete examples for the 'query' parameter ('person', 'car', 'watermark') and explicitly linking 'paymentId' to the create_payment tool. It does not address box_threshold or text_threshold, but these are already well-defined in 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 function: removing unwanted objects from images using natural language descriptions, with no mask needed. It specifies the action ('remove'), the resource ('objects from images'), and the input method ('describing what to remove'). This distinguishes it from sibling tools like remove_background, which targets the background rather than arbitrary objects.

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 usage context: describe the object to remove (with examples 'person', 'car', 'watermark'), pay via create_payment with toolName='remove_object', and no API key or signup needed. However, it does not explicitly contrast with alternative image-editing tools in the sibling set, such as edit_image or deblur_image, so the agent must infer when this tool is specifically appropriate.

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 the full burden and delivers an exceptionally detailed disclosure: deterministic layout with exact text fidelity, beat-by-beat reveal semantics ('text never shifts'), script/emoji rendering limits, signed-URL expiry (2 h, 'image is not inlined'), cap enforcement 'refused BEFORE payment', and Lightning pricing. This is a model disclosure profile for a paid render tool; there is no contradiction with any structured data.

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 clause earns its place: core capability first, then determinism, use cases, reveal behavior, font coverage, return shape, caps, and pricing — in that order. For a tool with 20 parameters, five variants, no annotations, and no output schema, the length is warranted density, not bloat. There is no filler or boilerplate.

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 and no annotations, the description covers the return shape ({ url, width, height, format, mime, expires_in_seconds }), the fetch-the-URL behavior, the payment prerequisite and price, validation caps, and font limits. An agent could invoke this tool correctly with only the description plus the already-descriptive schema; the only minor ellision is error-handling for invalid/expired payments.

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, and the description genuinely adds beyond the schema by composing parameters into patterns ('Lists and comparisons REVEAL one beat at a time (revealed:N / show_right:false)') and by tying paymentId to the create_payment prerequisite. The count/length caps are already encoded in the schema (1-6 items, 1-3 lines), making the description's cap mention partly redundant, so it stops short of a 5.

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 ('Render'), a specific resource (a typographic card with five named variants: headline, versus, list, stat, quote), and concrete output constraints (PNG/JPEG at 1920x1080 or 2560x1440). The 'no AI model... which no image generator can promise' line explicitly distinguishes it from sibling image-generation tools, so an agent can select it correctly without inspecting schemas.

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?

Names concrete use cases ('video title cards and slides, thumbnails, quote cards and social posts') and the required companion flow ('Requires create_payment with toolName='render_card''). The determinism contrast with image generators gives implicit when-to-use guidance, though no sibling tool is explicitly named as the alternative and there is no explicit when-not-to-use statement.

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 the full burden and succeeds. It discloses a side effect (sends email to operator), duplicate-detection behavior (returns existing LNURL instead of creating a duplicate), and the 30-day expiration of refund links. This goes well beyond basic expectations.

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 every sentence adds value. It front-loads the core purpose, then provides critical exceptions and warnings without redundancy. The structure is logical and scannable.

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 tool with 4 parameters, no output schema, and no annotations, the description covers the use case, exclusions, side effects, and expiry thoroughly. However, it doesn't specify what the agent should expect in the successful response for the normal manual ticket creation (e.g., a ticket ID), which is a minor gap given the absence 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?

Schema description coverage is 100%, so parameters are already fully documented. The description does not add additional parameter-specific meaning; it focuses on behavioral context. Baseline of 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?

The description clearly states the tool's purpose: 'Open a MANUAL 48-hour refund review ticket for a service that FAILED (error, timeout, wrong output).' It also distinguishes itself from automatic refunds by explicitly naming the sibling services (ai_call, voice_bridge) and instructing not to use this tool for those cases.

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 ('for a service that FAILED') and when-not-to-use guidance ('DO NOT call this for unused-minute refunds on metered services'). It also explains the fallback behavior for metered payments with pending LNURL refunds and includes the 30-day claim window, which is critical for agent decision-making.

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 several behavioral traits: adjustable fidelity, background enhancement, upsampling, stable endpoint with automatic model upgrades, and pricing. However, it does not mention the output format (e.g., base64 image, URL) or potential failure modes, which is a notable gap.

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 compact paragraph that front-loads purpose and then provides model info, adjustment options, and payment details. It is efficient, though the technical FID score and model citation add slightly more detail than strictly needed for agent selection.

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 purpose, key parameters, payment requirement, and model stability, which is good. However, with no output schema, it omits return value details (e.g., output image format or how to retrieve the result), which is essential for a tool that returns data.

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 covers all 6 parameters with clear descriptions (100% coverage). The description adds some high-level context for fidelity ('balance between quality enhancement and identity preservation') and mentions background/upscaling, but the schema already explains each parameter in detail, so the added value is marginal.

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: 'Restore blurry, damaged, or AI-generated faces to sharp, natural quality.' This clearly distinguishes it from sibling tools like deblur_image (general deblurring) and upscale_image (general upscaling) by emphasizing face-specific restoration.

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 provides clear context for when to use the tool (face restoration, background enhancement, upscaling) and the required payment flow via create_payment. However, it does not explicitly mention when not to use it or name alternatives, so it lacks 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?

The description adds meaningful operational behavior beyond annotations: no SMTP server, no domain verification, no API key/signup, plain-text-only content, character limits, 200 sats cost, and Lightning payment. Annotations already signal destructive/open-world behavior, and the description enriches that context 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?

Every sentence carries operational or usage information: use case, setup requirements, content constraints, cost, payment method, and prerequisite call. The description is dense but not bloated, with no filler or redundant restatement of the tool name.

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 paid external-communication tool, the definition covers recipient, subject, body, payment flow, cost, and setup requirements. The lengthy paymentId schema description supplies the review/hold/refund behavior, so together the tool definition gives an agent everything needed to invoke it 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating the cost (200 sats) and the required create_payment workflow with the exact toolName parameter. It also reinforces subject/body limits, though those are already in 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 identifies the resource as email ('Reach anyone with an email address') and gives concrete use cases: formal communication, reports, and contacting people outside chat. It doesn't explicitly distinguish from send_sms/send_fax siblings, but the email focus is unmistakable.

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 provides clear context for when to use the tool: formal communication, reports, or external contact. It also explains the prerequisite payment flow via create_payment with toolName='send_email'. It doesn't state exclusions or compare directly with SMS/fax alternatives, 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?

Discloses modes, language support, rejection behavior, pricing, max pages/size, and payment necessity. Annotations already indicate destructiveHint=true (consumes credit), and description adds context about what gets rejected pre-payment. Could mention retry or status behavior but overall 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?

Description is substantial but front-loaded with use cases. Every sentence adds value (pricing, limitations, mode details). Could be slightly more structured (e.g., bullet points) but is not verbose.

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 7 parameters, complex dual-mode behavior, language support, and pricing details, the description covers all necessary aspects. No output schema exists, but behavior and constraints are fully explained, enabling 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?

Schema covers all parameters with descriptions. Description adds value by specifying phone number format (E.164), explaining pages as quantity for create_payment, and clarifying mode differences (pdfUrl vs text). Provides more context than schema alone.

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 uses specific verb 'send' and resource 'fax', lists use cases (loan paperwork, signed contract, booking confirmation), and distinguishes two modes (pdf/text). Clearly differentiates from sibling receive_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?

Explicitly states when to use (need paper trail, worldwide), provides mode selection criteria, lists rejected content (RTL, emoji) before payment, details pricing and prerequisite paymentId, and directs to create_payment for proper invoicing.

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?

Going well beyond the openWorldHint/destructiveHint annotations, the description discloses irreversible and conditional behaviors: international numbers are delivered one-way via an alphanumeric sender ID with 'no error returned,' messages are screened after payment, 'held messages and calls are not sent,' refunds are not immediate, and answering a call does not establish consent. It also surfaces data-retention windows and de-identification caveats. Nothing contradicts the 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 core purpose, payment requirement, and matching constraint are efficiently front-loaded in the first few sentences. However, the back half becomes a near-privacy-policy (appeal costs, 24-hour context records, 30-day cleanup, de-identification limits) that is far more verbose than needed for an agent to select and invoke the tool correctly; it could be condensed significantly without losing invocation-relevant 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?

For a destructive, world-facing tool with no output schema, the description covers the payment prerequisite, delivery caveats, screening/hold behavior, refund rules, consent constraints, and data handling. The main gap is the lack of any description of the return value or how to confirm the send outcome (e.g., via check_payment_status), though no output schema exists to fill that void.

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 parameter basics are already documented, giving a baseline of 3. The description adds critical cross-tool semantics not in the schema: phoneNumber and message 'must match those used in create_payment,' and the billed segment count includes an appended signature line plus safety/stop link. This is meaningful value beyond the structured fields.

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 opening sentence, 'Reach a human via SMS when your task requires real-world coordination,' names a specific verb, channel, and purpose, and the claim of sending to 'any phone number worldwide' differentiates it from siblings like send_email, send_fax, and place_call. The tool's resource (SMS to a phone) is unambiguous, with no confusion about what it is for.

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?

'When your task requires real-world coordination' supplies a clear trigger condition, and the explicit prerequisite — 'Requires create_payment with toolName='send_sms' and phoneNumber+message at payment time' — gives a concrete preconditions. However, no sibling tool is named and there is no explicit 'use send_email instead when...' exclusion, so alternative routing is left to inference.

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 the full behavioral burden and does well: it discloses the return value (audio URL), the payment model (Bitcoin Lightning, no API key/signup), the prerequisite (create_payment with toolName='text_to_speech'), and per-tier throughput limits. It omits any mention of rate limits, failure modes, or async/latency behavior for long text, which keeps it short of a 5.

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?

Front-loads the three-tier model, then payment, then exclusions, then language routing — a sensible order. The tier character-limit figures are repeated from the schema descriptions, adding mild redundancy, and the tier list is dense, but no sentence is genuinely wasted.

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?

There is no output schema, so the description must state the result, and it does ('Returns audio URL'). The payment prerequisite and toolName value are given, and tier/language tradeoffs are covered. What is missing for a 7-parameter, 467-voice tool is guidance on voice vs. voice_description precedence and expected latency, but the core is 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 coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning: it ties tier selection to modelId, explains that language= is silently ignored on non-OmniVoice tiers, and states that rare-language coverage is achieved via the language= parameter rather than by picking a voice. That is more than the schema alone conveys.

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+resource (text-to-speech) and immediately differentiates the three internal tiers (OmniVoice Global, Inworld Premium, Minimax Studio) with languages, quality, and per-tier character economics. It also names the sibling tools it is not (place_call, ai_call, open_voice_bridge), so the agent can route without opening any schema.

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?

Explicit when-NOT-to-use section routes phone-call scenarios to place_call/ai_call/open_voice_bridge, and it gives a positive selection rule for rare/underserved languages (pick OmniVoice via language= because Inworld/Minimax do not cover them). Both conditions and alternatives are spelled out.

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 the full burden and does so well: it discloses async behavior returning a requestId, the polling lifecycle, the exact pricing (10 sats/min), the ephemerality/privacy guarantee ('never persisted'), the payment precondition, and the degraded-result behavior on partial failure. Nearly everything an agent needs to run this safely is spelled out.

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?

Dense but tightly packed with a clear front-loaded purpose statement followed by timestamps, engine, languages, limits, workflow, cost, and privacy. A few clauses (word-timestamp use cases, language enumeration) repeat the schema, but there is little true 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?

No output schema exists, and the description compensates by explaining the return shape (requestId) and that the agent must poll and fetch results. For a paid, asynchronous, mutation-style operation with 7 parameters, the coverage of cost, prerequisites, and lifecycle is 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 restates the timestamps:'word' use cases and the 13-language list, but this largely duplicates the enum and per-parameter descriptions already in the schema rather than adding new syntax or format guidance.

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 and resource with scope: transcribe audio to text with word- or segment-level timestamps, plus the underlying engine, language support, and file limits. It distinguishes the tool by what it produces (timestamps, not translation), though it never names transcribe_translate as the sibling an agent should choose instead when translation is needed.

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?

Gives a concrete operational workflow: create_payment with toolName='transcribe_audio' first, then poll via check_job_status(jobType='transcription'), then get_job_result. This is clear context for invoking it. What's missing is an explicit exclusion rule versus transcribe_translate or other audio 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?

Despite no annotations, description discloses async polling, payment requirement, auto-detection, and a warning about language inaccuracies. Covers key behaviors well.

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?

Front-loaded with main purpose, each sentence adds value, though slightly verbose. 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?

Covers prerequisites, async result handling, pricing comparison, and language limitations. Complete for a complex tool without 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?

Schema coverage is 100%, but description adds context: explains paymentId origin, lists allowed source language codes with warning, and clarifies target language 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?

Description clearly states it transcribes and translates audio from 13 source languages to 119 target languages, distinguishes from sibling tools transcribe_audio and translate_text by being a compound endpoint and cheaper.

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 clear use cases (WhatsApp voice messages, meeting recordings) and contrasts with separate calls, but lacks explicit when-not-to-use instructions.

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 behavioral burden and does so thoroughly. It discloses the async requestId flow, polling via check_job_status with jobType='translate-epub', temporary 6-hour download URLs, engine selection by language, per-character pricing, the create_payment prerequisite, re-pricing at execution, and short-pay refunds. This goes well beyond a basic summary.

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 every sentence earns its place: purpose, fidelity guarantees, language/price model, async flow, payment requirements, and edge-case refunds are all covered. The main action is front-loaded, and the rest follows a logical order from call to polling to payment details.

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 and no annotations, the description covers everything an agent needs to invoke the tool correctly: required inputs, async behavior, how to poll, where to fetch the result, how to pay, and what to do about re-pricing. The only minor omission is guidance on error handling, but the description is unusually complete for a complex paid async 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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by stating that paymentId must be a valid paid payment ID and that targetLanguage must equal the language used when creating the payment. It also ties the characterCount used in create_payment to the tool's pricing model, which helps the agent plan the payment step.

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 opening sentence, 'Translate a whole EPUB into another language and get an EPUB back,' states a specific verb, resource, and output, clearly distinguishing this tool from siblings like translate_text and epub_to_audiobook. The added detail about preserving markup, translating the TOC, and retargeting package language further pins down the exact scope.

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 makes the usage context clear: whole-book EPUB translation with markup preservation, async polling, and Lightning payment. It references translate_text only for rate comparison rather than explicitly saying 'use this instead of translate_text for EPUBs,' so it stops short of explicit when-not guidance, but the context is strong enough for an agent to select it correctly.

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 quality tiers (good/fair/unverified/experimental), model used (MADLAD-400), and that response includes the tier. No hidden behaviors.

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 thorough and well-organized, with key information front-loaded. A few minor redundancies (e.g., listing many languages) but generally every sentence 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 3 required parameters and no output schema, the description covers all essential aspects: quality, payment, prerequisites, and fallback tool. 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?

All three parameters have descriptions in the schema (100% coverage). The description adds value by clarifying text length limit, pricing formula per character, and acceptable language identifiers (codes or English names).

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 translates into rare languages, specifying 452 languages, many not supported by other chatbots. It explicitly distinguishes from mainstream translation tools and provides concrete language examples.

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 recommends using 'translate_text' for mainstream languages (cheaper, more fluent). Describes payment flow via Bitcoin Lightning. States unsupported languages are rejected before payment.

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 behavioral burden and performs well: it discloses engine selection (GPT-OSS default, Gemini when better), privacy/no data storage, exact pricing per character, minimum payment, and the requirement to call create_payment. It is missing some edge-case behavior like rate limits or explicit error handling, but it reveals substantially more than the schema alone.

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 central purpose and key behaviors like auto-detection and privacy. However, it is not concise: the 119-language list is a large block of tokens that largely duplicates the endpoint reference and schema note, and the pricing details are more verbose than necessary for calling 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?

The description covers a great deal: language coverage, engine selection, language formats, payment requirements, privacy, and pricing. But without an output schema, it never explicitly states the return value or how the translated text is delivered, and it omits guidance on choosing this tool over sibling tools. These gaps prevent it from being fully complete for a complex payment-gated 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 description coverage is 100%, so the baseline is 3, but the description adds meaningful context: it maps targetLanguage to engine selection, explains that text drives the per-character price, and details the create_payment workflow. It also reinforces the auto-detection behavior for omitted sourceLanguage, going beyond the schema's basic parameter descriptions.

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 'Translate text across 119 languages' with a specific verb and resource, so the tool's core function is unmistakable. It also mentions source auto-detection, which further clarifies the behavior. However, it does not explicitly distinguish itself from sibling translation tools like translate_rare_language, so it misses the differentiation needed for a 5.

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 usage context: it translates text, auto-detects the source language, and requires a payment created via create_payment. It also gives helpful instruction about omitting sourceLanguage and using language names or ISO codes. Yet it gives no explicit guidance on when not to use it versus sibling alternatives such as translate_rare_language or multilingual_ask.

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 fully discloses behavioral traits: it names the model (Real-ESRGAN), states it recovers real detail (not interpolation), mentions optional face enhancement, describes stable endpoint with automatic upgrades, and lists pricing (5 sats per image, pay-per-request with Lightning, no API key). 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?

The description is concise (~70 words) and front-loaded with the primary action. Every sentence adds value: purpose, technical details, payment requirement, and behavioral notes. 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?

For a tool with 4 parameters and no output schema, the description covers behavior, prerequisites, pricing, and model information. It does not describe the return format (e.g., base64 image), but given the context, 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 coverage is 100%, so the schema already documents all parameters. The description adds marginal value by noting the default scale (4x) and that imageBase64 can be a data URI. For a high-coverage schema, 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 upscales images 2x or 4x using neural super-resolution. It distinguishes itself from sibling tools like 'edit_image', 'generate_image', and 'restore_face' by focusing on resolution enhancement via machine learning.

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 requires a prior payment via 'create_payment' with toolName='upscale_image', which is a clear usage prerequisite. However, it does not specify when to use this tool over alternatives like 'edit_image' or 'restore_face', leaving some ambiguity.

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 only declare openWorldHint, so the description carries the load and does well: it discloses a real side effect (STT is auto-muted during injection so the agent doesn't hear itself), the billing behavior (covered by session deposit, no extra payment), and TTS fallback behavior with a warning on the reply. Missing only error/latency behavior to reach a 5.

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?

Front-loads the core action, then the two modes, then the side effect and cost note; every sentence contributes. It is somewhat dense (long clauses and parentheticals) but no sentence is 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?

For a 6-parameter mutation-style tool with no output schema and minimal annotations, the description supplies the essential operational context: prerequisite session, mode selection, side effects, billing, and fallback voice behavior. Only return-value/error detail is thin, which is acceptable given no 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?

Schema description coverage is 100% and the schema already labels text as '(mode 1)' and audioBase64/encoding as '(mode 2)', including enum values and the voiceDescription fallback caveat. The description's mode framing adds little beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.