Sats4AI - Bitcoin-Powered AI Tools

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

Annotations declare openWorldHint and destructiveHint, and the description goes well beyond them: exactly what is destroyed or retained (recording deleted without consent, payment retained during review, 24-hour refund eligibility, retention windows), the redial rules and billing behavior, do-not-contact consequences, and abuse screening. It does not contradict the destructive hint. A small amount of operational detail (return shape beyond 'transcript with structured analysis') is left implicit, keeping it just 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?

The purpose, redial policy, and 'When NOT to use' are front-loaded and well structured, but the back half is very long, stacking retention, de-identification, screening, and appeal details that are largely boilerplate for call selection. Much of it is compliance-relevant yet disproportionate to the invocation decision, diluting scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, multi-step, async, paid tool with no output schema, the description is complete: it covers the payment prerequisite, pending_confirm/confirm_ai_call path, polling via check_job_status, language handling, redial outcomes, and refund behavior. An agent has everything needed to invoke and follow up 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 enum, defaults, and formats are already documented. The description adds some workflow meaning — that paymentId must come from create_payment with toolName='ai_call', and that phoneNumber/durationMinutes are required — but does not add semantics beyond the schema for task, language, beginMessage, or refundAddress. 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?

The description opens with a specific verb and resource — send an AI voice agent to handle a phone call — and enumerates exactly the situations it covers (booking, negotiating, IVR navigation, business info). It explicitly differentiates itself from open_voice_bridge, place_call, and send_sms, so an agent can route correctly 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?

It gives explicit when-to-use framing, a dedicated 'When NOT to use' list naming three alternatives and the condition selecting each, and states the required prerequisite flow (create_payment with toolName='ai_call'). Exclusions and alternatives are fully enumerated rather than inferred.

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?

Annotations only declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond them: conditional streaming vs single-check behavior based on the Accept header, a ~4 minute per-call wait ceiling, the timed_out=true/status='IN_PROGRESS' retry contract, and that it is free with no payment. This is rich operational disclosure.

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 core action, then layered conditions (streaming vs single-check, timeout, retry) in a single dense paragraph where every sentence carries actionable information. No filler 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?

With no output schema, the description steps in to describe return behavior (final result, status='COMPLETED', status='IN_PROGRESS' with timed_out=true), and covers prerequisites, timeout, and retry. An agent has everything needed to call and re-call 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 by tying jobType to the async tools that emit requestId and by clarifying the paymentId refund-claim interaction, going beyond the schema's terse per-field text. It stops short of restating full enum semantics, so not 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 and resource ('wait for an async job to finish and return its result in ONE call') and explicitly positions itself against siblings by noting it is 'equivalent to check_job_status + get_job_result combined.' An agent can distinguish it from the polling/status siblings 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?

Explicitly names the async tools that produce the required requestId (generate_video, animate_image, generate_3d_model, transcribe_audio, epub_to_audiobook, ai_call), and gives the exact fallback protocol: call again until status='COMPLETED' or timed_out=true. No inference required.

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?

With only idempotentHint=true in annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the return shape and status values, extra progress fields for epub-audiobook, polling interval, failure behavior (error message, no automatic retry), and cost ('free, no payment'). Nothing here contradicts 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 front-loaded with purpose and usage, then adds return format, polling guidance, and exclusions. It is highly informative but somewhat long, with several sentences that could be combined without losing meaning, so it is structured well but not maximally tight.

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 minimal annotations, the description is complete enough for correct invocation: it explains the return values, status transitions, progress field for one job type, polling cadence, failure handling, and the follow-up tool to call. Nothing critical 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%, so both parameters are already documented in the input schema, including the enum mappings and fallback jobTypes. The description reinforces that requestId comes from async tools but does not add syntax, format, or constraints beyond what the schema provides, so 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?

The description opens with a specific verb and resource: 'Poll the status of an async job.' It explicitly names the sibling tools it follows (generate_video, animate_image, etc.) and distinguishes itself from get_job_result and synchronous tools, so an agent can tell what it does and where it fits without opening another 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?

It gives explicit when-to-use rules ('after calling any async tool that returns a requestId'), polling cadence ('every 5-10 seconds'), next-step routing ('call get_job_result' on COMPLETED, do not retry on FAILED), and a clear when-not-to-use warning ('Do NOT use for synchronous tools'). The alternatives and conditions are fully 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?

Annotations only declare readOnlyHint/idempotentHint; the description goes far beyond them by decoding the response contract (readyToUse meaning, 'next' guidance), enumerating the state machine (unpaid, paid, delivered, held, refund-open, claimed, expired), flagging the held/appeal_url condition, and warning that a successful SMS/fax send means 'accepted, not delivered' so the carrier outcome must be polled. It also states the cost profile (free, no payment required).

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 core purpose, then structured as return-value decoding, then usage guidance. Dense but nearly every clause carries operational meaning; the JSON field enumeration runs a little long as a single run-on sentence, which keeps it short of perfect.

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 and this tool's return values are complex and stateful, so the description must explain them — and it does, covering paid/readyToUse semantics, the full state enum, held-review behavior, and SMS/fax delivery caveats, plus expiry handling. Nothing needed to call or interpret it 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?

Only one parameter with 100% schema description coverage ('The paymentId returned by create_payment'), so the schema already carries the load; the description adds no format, length, or syntax detail beyond it. Baseline 3 is appropriate when the schema fully documents the parameter.

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: 'Check whether a Lightning invoice has been paid.' It is immediately distinguishable from siblings like create_payment (initiates payment), await_result/check_job_status (polls non-payment work), and request_refund.

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 explicit sequencing ('Call after create_payment to verify the user has paid before calling the target tool') and names the recovery path when the tool cannot help ('Invoices expire after 10 minutes — if expired, create a new payment'). It also pre-empts over-polling: 'Most MCP clients with a connected wallet pay instantly, so a single check is usually sufficient.'

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?

With no annotations, the description carries the burden and does well: it discloses cost (5 sats per image), the Bitcoin Lightning pay-per-request model with no API key/signup, and the retry path via resultKey on timeout. It does not describe the response shape (returned image data/URL) or any rate/time limits beyond the 5s claim, leaving a residual 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?

Purpose and prerequisite are front-loaded and each sentence carries actionable content. The marketing aside ('Impossible for text/vision LLMs', 'vivid, natural colorization') is filler that slightly dilutes an otherwise tight paragraph.

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 payment-gated tool with no annotations and no output schema, the description covers the payment and retry mechanics well but never says what the call returns (image payload vs. URL vs. job handle). That return-value ambiguity is a meaningful 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 the schema already documents paymentId, resultKey, model_size, and imageBase64. The description adds the payment-creation prerequisite and ties cost to the call, but adds nothing on model_size tradeoffs or image format beyond what the schema states, so it sits at the 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 leads with a specific verb+resource ('Colorize black-and-white or grayscale photos') and names the underlying model (DDColor, ICCV 2023), making the task distinct from siblings like edit_image or upscale_image. It stops short of explicitly contrasting with those siblings, so it's clear but not fully differentiated.

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 states a clear prerequisite flow: 'Requires create_payment with toolName="colorize_image"', which tells the agent exactly what must happen before invocation. It gives no explicit when-not or alternative tool guidance (e.g. vs upscale_image or edit_image), so the routing side is weaker than the prerequisite side.

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 burden and does substantial work: it discloses the return value ('Returns download URL'), the cost (100 sats), the auth model (Lightning pay-per-request, no API key/account), and the create_payment prerequisite. It omits operational traits such as file-size limits, expected duration, and whether execution is synchronous or async (the resultKey retry parameter hints at timeouts but the description never states 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?

Capability and format coverage are front-loaded, followed by pricing and the payment prerequisite, which is the right order for an agent deciding whether to call. There is some promotional padding ('Industrial-grade conversion engine — preserves formatting and quality') and mild redundancy in 'no API key, no account, no subscription needed', but no sentence is truly 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?

For a 6-parameter, no-output-schema, no-annotation tool, the description covers the essentials: what it converts, what it returns, what it costs, and what must happen first. The remaining gap is operational behavior around long-running conversions and failures, only faintly implied by the resultKey parameter.

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 every parameter including the fileUrl/fileBase64 mutual exclusivity and the resultKey retry semantics is already documented in the schema. The description adds no format syntax guidance (e.g., accepted extension strings) beyond what the schema states, so 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 and resource ('Convert files between 200+ formats') and enumerates concrete conversion families (PDF→JPG, MP3/WAV, MP4/AVI), so the agent knows exactly what capability this covers. It does not, however, differentiate itself from siblings that overlap in scope, notably convert_html_to_pdf, which the description implicitly claims (HTML→PDF) without saying which tool should win.

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 clear usage context and a hard prerequisite: 'Requires create_payment with toolName=\'convert_file\'', which tells the agent the ordering of calls. It stops short of explicit exclusions or naming alternatives (e.g., convert_html_to_pdf, merge_pdfs), so the boundary with siblings 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 zero annotations the description carries the full burden and does: it discloses the return shape and its key limitation ({ url }, temporary, ~1 hour), the cost model (50 sats per conversion), the payment/auth model (Bitcoin Lightning, no API key or signup), and the required upstream create_payment call. This is unusually complete disclosure of cost, ephemerality, and auth prerequisites for a mutation-ish 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?

Front-loads the core action and return value, then layers use cases, limits, cost, and prerequisite in a sensible order. Dense but every sentence carries operational information; the use-case enumeration ('invoices, reports, receipts') is the only mildly expendable clause.

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, prerequisite-gated conversion tool with no annotations and no output schema, the description covers return value, URL lifetime, cost, auth/payment path, capability limits (full HTML/CSS, tables, base64 or URL images, inline styles), and the alternative tool. Nothing needed 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. The description still adds meaning beyond the schema by tying `format='markdown'` to a concrete behavior and by establishing that paymentId originates from create_payment with a specific toolName argument. It does not elaborate on resultKey semantics, but the schema already documents 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?

States a specific verb and both resources ('Convert HTML or Markdown ... to a pixel-perfect PDF') and explicitly differentiates from the sibling convert_file, noting that one handles existing file formats like DOCX→PDF. An agent can route between the two without opening either 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 explicit when-to-use ('invoices, reports, receipts'), when-to-use-the-other-tool ('Use convert_file instead for converting existing files'), the Markdown switch ('set format=\'markdown\''), and the hard prerequisite ('Requires create_payment with toolName=\'convert_html_to_pdf\''). Nothing about invocation selection 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 burden and does so: it discloses the atomic validate-all-first behavior (one bad item refuses the whole cart with no invoice), that the error names the failing item by index, that paymentIds are irrecoverable and unrepeatable, that unused items are refunded after about an hour, and the exact success JSON shape.

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?

Purpose, limits, item construction, failure behavior, return shape, next steps, and exclusions arrive in that order with no filler. It runs long, but each sentence carries distinct operational information; the inline JSON return description is the densest part but is justified by the absence of an output 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?

This is a high-complexity, multi-item payment tool with no annotations and no output schema, and the description still covers item limits, sat cap, validation semantics, error reporting, return shape, paymentId handling, refund timing, and sibling routing. Nothing needed 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 the baseline is 3, but the description adds a cross-tool rule the schema only gestures at: each item is '{ toolName, ...the same inputs create_payment takes for that tool }', establishing that per-tool inputs and pricing mirror create_payment. Minor gap in that it doesn't restate per-field semantics, which the schema already covers.

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 states a specific verb and resource with scope: 'Pay for 2 to 10 calls with ONE Lightning invoice, up to 2,000 sats.' It explicitly distinguishes itself from the create_payment sibling and names the tool categories it accepts, so an agent can identify it without reading 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?

Usage is fully routed: use this for one-shot tools (text, translation, image, document, text_to_speech), use create_payment for calls/SMS/fax/email/video/music and other long jobs. The post-purchase workflow (pay the ONE invoice, then call each item's tool with that item's paymentId) is spelled out step by 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the return JSON shape, the 10-minute invoice expiry, price locking, rejection/refund behavior for under-declared audio or character counts, and error responses for missing fields. It does not cover authentication, idempotency, or what happens if an invoice expires before payment, which keeps it from 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?

The description is long but front-loaded: purpose, return value, call flow, and expiry come first, followed by parameter-specific pricing rules. Given 16 parameters and complex conditional pricing, the length is largely justified, though some schema-redundant detail could be trimmed.

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 payment tool with no output schema and no annotations, the description covers the essential flow, return contract, expiry, and the most failure-prone parameter rules. It is missing some operational context, such as idempotency and post-expiry behavior, so it is strong but not 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-parameter guidance beyond the schema: it maps requirements to tool names, clarifies modelId optionality, warns to quote generate_video/animate_image with the same duration and resolution as execution, and explains that some params affect price. It repeats some schema details, so it falls 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?

The description opens with a specific verb and resource: 'Create a Lightning invoice to pay for one AI service call.' It immediately distinguishes this tool from siblings by explaining the one-payment-per-tool-call model and the list_models → create_payment → check_payment_status flow.

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 states when to use this tool, how often ('once per operation'), and what to do before and after ('Call list_models first'; then 'check_payment_status → call tool'). It also names alternatives and conditions, such as omitting modelId to use the default and including extra params only for tools whose pricing requires them.

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 cost (110 sats per image), latency (~2 min processing), payment mechanism (Bitcoin Lightning, no API key/signup), and the required create_payment step. It stops short of describing the return format or failure behavior, which matters for an image-processing 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?

The paragraph is compact and front-loaded: purpose first, then model provenance, best-for/not-for, supported modes, and finally cost/payment details. Every sentence contributes 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?

Given four parameters with full schema coverage, no output schema, and no annotations, the description covers purpose, exclusions, cost, latency, and payment prerequisites thoroughly. It omits the return value shape and how results are delivered, which would complete the picture for a paid image-processing call.

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 all four parameters are already documented in the input schema. The description adds useful context that denoising is supported, but no syntax or format detail beyond what the schema provides, so the 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 states a specific verb and resource ('Recover detail from camera-shake and accidental motion blur') and names the underlying model (NAFNet). It clearly scopes what the tool is and is not for, though it never names a sibling tool to route against, leaving some ambiguity with upscale_image or restore_face.

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 'Best for' and 'NOT effective for' lists tell the agent exactly when to select and avoid this tool. It also explains the payment precondition via create_payment, leaving no inference needed for correct invocation.

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

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

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, the description carries the burden and does substantial work: flat 200-sat price, Lightning pay-per-request auth, no signup, and a stated return shape ('Returns JSON with image URL'). It omits sync-vs-async behavior and timeout/retry handling (only hinted at by the resultKey schema param), which keeps it from 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?

Purpose is front-loaded in the first sentence, followed by capability, return, and pricing in a logical order. The sentence about the model being 'ranked #3 on the Artificial Analysis leaderboard as of September 2026' is selection-irrelevant marketing and slightly dilutes an otherwise dense description.

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, unannotated, no-output-schema tool, the description covers what an agent needs: what it does, what it returns, what it costs, and the mandatory create_payment precondition. Remaining gaps (sync/async, timeout) are partially covered by the resultKey parameter documentation.

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 one of the 8 parameters is already documented, including the unusual 'resolution is ignored for compatibility' note and the returnBase64 context-cost tradeoff. The description adds no parameter-level meaning beyond reinforcing the payment requirement, 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 enumerates capabilities (object addition/removal, style transfer, inpainting), which implicitly separates it from single-purpose siblings like colorize_image, upscale_image, or remove_background. It stops short of naming those siblings, so an agent must infer routing rather than being told.

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 an explicit invocation prerequisite ('Requires create_payment with toolName=edit_image') and notes no API key/signup is needed, which is real usage context. However it never states when to prefer this over generate_image, remove_object, or restore_face, so alternative selection 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 and does well: it discloses cost (5 sats per image), payment mechanism (Bitcoin Lightning, pay per request, no API key/signup), the required create_payment prerequisite, and that both raw greyscale and color visualization outputs are returned. It omits latency/timeout behavior and input size limits, but covers the major behavioral traits.

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 core action and resource, then efficient supporting details about outputs, cost, and prerequisites. Slightly dense with promotional asides ('3.8M+ runs', 'Structured geometry a vision LLM cannot produce'), but every sentence contributes relevant 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?

With no output schema, the description correctly fills the gap by explaining both return values (raw greyscale depth map and color visualization) and the payment workflow. It is nearly complete for a paid, 4-parameter tool; only latency/timeout expectations are left implicit via the schema's resultKey hint.

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 schema already documents paymentId, resultKey, model_size, and imageBase64. The description adds no additional parameter meaning beyond what the schema provides; baseline 3 is appropriate when the schema does the heavy lifting.

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

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Estimate per-pixel depth from a single photo', naming the model (Depth Anything V2) and the exact output (per-pixel depth map). This clearly distinguishes it from siblings like generate_3d_model or analyze_image, which produce different artifacts.

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 usage context: 'what a ControlNet, AR or 3D reconstruction pipeline consumes' and 'Structured geometry a vision LLM cannot produce' implies when this beats generic vision tools. The payment prerequisite (create_payment with toolName='estimate_depth') is explicit, but there is no explicit exclusion or named alternative sibling 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?

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?

Discloses critical behavior beyond annotations: pricing at 5 sats/second, the 15-300 second duration range, the +25 sats lyrics add-on, Lightning payment without signup, and the silent shortening risk when words share a tag line. Also states the return format as a 44.1 kHz WAV URL.

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?

Information is front-loaded and every sentence carries operational value. It is somewhat dense and long, but not padded with irrelevant content.

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 the full call flow: payment prerequisite, duration/price coupling, prompt and lyrics structure requirements, optional lyric generation, and return format. For a complex paid generation tool without an output schema, this is complete enough 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?

With 100% schema description coverage, the schema already documents all parameters well. The description adds useful semantics beyond the schema, especially the price/duration binding and the requirement that paymentId and duration must match create_payment.

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_music' / full song) and clearly distinguishes vocal songs from instrumental beds. An agent can tell exactly what this tool produces from the first sentence.

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 both usage modes: provide lyrics for a vocal song, or send only structure tags for an instrumental. It also names the prerequisite create_payment call and the lyricsAddon alternative when the user does not want to write lyrics.

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?

Despite readOnly/idempotent annotations already covering safety, the description adds substantial behavioral context: per-jobType result shapes, truncation fallback with fullResultUrl, temporary ~1h URL validity, refund error codes (RESULT_NOT_AVAILABLE, L402_REFUND_ISSUED), and refund-claim flow via /recover. This goes well beyond what the annotations provide.

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 core rule and prerequisite, then organized by jobType. It is dense and long, with some redundancy in refund scenarios, but nearly every sentence carries actionable information for correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining return values, and it enumerates the shape per jobType, truncation handling, and refund cases. For a 3-param idempotent read tool, nothing an agent needs 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 would be 3, but the description adds real meaning: it maps jobType values to the output shapes they produce and explains the paymentId refund-claim behavior. It does not restate the enum-to-tool mapping already in the schema, but contributes useful conditional logic around paymentId.

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 precise verb+resource: retrieve the final output of a completed async job, and scopes it by naming the prerequisite sibling check_job_status and excluding synchronous tools. An agent can distinguish it from check_job_status and await_result without inspecting 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-to-use ('Call ONLY after check_job_status returns status=COMPLETED'), what happens when misused (error), and an exclusion ('Do NOT use for synchronous tools'). This is a complete routing rule with no inference required.

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?

With no annotations, the description carries the behavioral burden and does so well: it discloses the temporary return URL, roughly one-hour validity, minimum and maximum file counts, array-order concatenation, pricing, and Lightning payment requirements. It stops short of failure modes, file-size limits, or retry behavior for resultKey, so it is strong 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?

The description is front-loaded with the core operation and then efficiently layers in return behavior, limits, pricing, alternatives, and payment prerequisites. There is no wasted text, and each sentence contributes operational context.

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 annotations and an output schema, the description supplies the missing return-value, payment, cost, and file-ordering context that an agent needs. It is complete enough for correct selection and invocation, with only minor optional details like error formats omitted.

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 useful semantics beyond the schema by explaining that files are concatenated in array order and by tying paymentId to the create_payment flow, though it does not elaborate on resultKey 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?

The description states a specific verb and resource: merging multiple PDF files into one document. It also explicitly distinguishes the tool from convert_file, so an agent can identify its exact purpose without inspecting 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?

It names the relevant alternative, convert_file, and the condition that selects it: format conversion such as DOCX to PDF. It also states the create_payment prerequisite with toolName='merge_pdfs', giving clear contextual guidance for 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 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?

Annotations carry only openWorldHint, so the description bears the load and delivers: turn-based not full-duplex, ~2s turn latency with the ~0.8s natural target as a comparison, callee cannot interrupt, filler fires at ~3.5s and only once, unused deposit refunded automatically on hangup including callee-initiated, refund paid out irreversibly vs. held as an LNURL-withdraw claim, transcripts GC'd after 30 minutes, audio never persisted, and premium-rate/satellite ranges refused. This is exactly the behavioral context annotations don't provide.

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 core concept and the poll/say loop, and every paragraph is information-dense rather than filler. It is long, and the filler behavior plus refund mechanics are restated across the description and schema, which is some avoidable duplication for a definition this size.

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 10-parameter, annotation-thin, no-output-schema tool, the description covers payment setup, call loop, timing budget, refund path, privacy, and failure modes. An agent has everything needed to open the call, drive it, and close it out 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 baseline is 3, but the description adds real meaning beyond the schema: it tells the agent to call create_payment for the exact BTC-pegged figure rather than guessing a deposit, and it stresses 'never invent' a refundAddress and why (immediate, non-reversible payout). The filler and greeting semantics are mostly duplicated in the schema, so it earns one step above baseline rather than more.

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 states a specific verb and resource ('Open a phone call you drive one turn at a time') and immediately explains the mechanism: we dial, transcribe, and speak your text. It names the three loop partners (voice_bridge_say, poll_voice_bridge, end_voice_bridge) and contrasts itself with ai_call and place_call, so an agent can place it among siblings without opening a 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-to-use ('leaving a spoken message, navigating a voice-driven IVR, reading something out, a slow exchange') and an explicit 'When NOT to use' block naming ai_call for managed conversational calls and place_call for one-shot TTS/broadcast, plus the exclusion for cases where live polling adds no value. Prerequisites (create_payment with toolName='voice_bridge_open') are stated up front.

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 flag openWorldHint and destructiveHint; the description goes far beyond by disclosing the payment/screening pipeline, that the message plays before the spoken notice, opt-out mechanics, that payment is retained during review and not refunded for confirmed violations, and the retention windows for transcripts and context records. This is exactly the kind of behavioral detail an agent cannot get from structured fields.

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 purpose is front-loaded, but the body is a long wall of compliance and retention legalese (hourly cleanup, 30-day cleanup, token replacement, appeal pricing, de-identification caveats) that is disproportionate for tool selection and invocation. Much of this text does not earn its place in a tool description.

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, open-world, payment-gated tool with no output schema, the description covers prerequisites, screening behavior, and policy constraints thoroughly. The main omission is any indication of what the tool returns (job id, call status) or how to track the placed call.

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 message/audioUrl/paymentId/phoneNumber/durationMinutes are already documented. The description still adds value by exposing the cross-tool dependency (create_payment with toolName='place_call' and phoneNumber) and the constraint that the closing notice consumes part of the prepaid minutes.

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 — 'place an automated phone call to deliver a spoken message or play audio' — which is concrete and actionable. However, it never distinguishes itself from the sibling `ai_call`, `confirm_ai_call`, or `open_voice_bridge`, leaving ambiguity about which call-related tool to pick.

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 clear use case ('notifying a human, delivering alerts, or reaching someone who isn't online') and an explicit prerequisite (create_payment with toolName='place_call' and phoneNumber). It lacks any when-not guidance or named alternative, so the agent must infer the boundary with 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 full burden and does substantial work: it discloses the returned event types, the long-poll ceiling (max 25000), the definition of 'finished talking' (final transcript + quiet period or state change), that partials alone do not end the wait, and that there is no additional charge. It stops short of covering session-end behavior or error conditions, which keeps it from 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-loaded with the core action and return payload, then moves to the waitMs decision. It is slightly dense and repeats the wait/poll tradeoff that the schema also encodes, 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 4-parameter, no-annotation, no-output-schema tool this covers the essentials: what comes back, how to paginate with cursor, and how to block versus poll. Only edge cases (session termination, error surfaces) are left unspecified.

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 goes beyond by explaining the practical intent of waitMs (e.g. 20000) and the polling cadence to use when it is omitted. It reinforces cursor semantics as 'since the last cursor' in context of a polling loop rather than merely restating field types.

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 ('Fetch new transcript events from an open Voice Bridge call since the last cursor') and immediately enumerates what is returned (partial transcripts, final transcripts, system events). This clearly separates it from siblings like open_voice_bridge, voice_bridge_say and end_voice_bridge, which are named or implied elsewhere in the definition.

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 either/or: use waitMs to long-poll until the callee finishes speaking, or poll in a loop at ~500ms-1s and decide completion yourself. It even explains the motivation ('you do not answer in the middle of their sentence') and notes no extra payment, so the agent can choose a strategy without 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?

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?

No annotations, so the description carries the burden and does well: discloses cost (44 sats/image), auth model (Lightning payment, no API key/signup), output format (transparent PNG), and that the endpoint auto-upgrades models — a real behavioral-drift disclosure. Gaps: no latency/timeout expectations, failure handling, or image 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?

Purpose and return value are front-loaded, followed by capability and payment constraints — a sensible order. Some benchmark marketing ('Sm 0.901 on DIS5K', 'state-of-the-art') is borderline filler but arguably supports model-choice trust.

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 and no annotations, yet the description covers the return artifact (transparent PNG) and the payment prerequisite. It omits how the result is delivered (inline base64 vs URL) and what happens on timeout, leaving a small gap for an agent handling the response.

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 by explaining where paymentId comes from (create_payment with toolName='remove_background'), which the schema only calls 'Valid payment ID'. It says nothing about resultKey or accepted input formats beyond what the schema already documents.

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 (remove background) and a concrete output (transparent PNG), plus the underlying model (BiRefNet). It is clearly distinct from remove_object/edit_image by name and scope, though it never explicitly contrasts with those 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?

Gives the concrete prerequisite: 'Requires create_payment with toolName="remove_background"' before invocation, plus payment method detail. It does not explicitly say when to prefer this over remove_object or upscale_image, so it stops 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?

With no annotations, the description carries the burden well: it discloses the pricing model (130 sats per image, Lightning, no API key/signup), the payment prerequisite, and the underlying pipeline. Gaps remain on failure/refund behavior and what happens to the payment if detection finds nothing, which matters for a paid mutation.

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 and the no-mask differentiator, followed by the cost and payment prerequisite — good ordering. The 'Grounding DINO (ECCV 2024) with Bria Eraser inpainting' clause is closer to marketing than operational guidance, costing a point.

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, and the description never says what is returned (an erased image, presumably base64) or how resultKey replays a result after a timeout — that only lives in the schema. For a 6-parameter paid tool with no annotations and no output schema, this leaves a real 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?

Schema description coverage is 100%, so all six parameters including box_threshold and text_threshold are already documented in the schema. The description only reinforces the 'query' semantics with examples; it adds no syntax, format, or tuning guidance 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('remove unwanted objects from images') plus the key differentiator 'by describing what to remove — no mask needed', which separates it from remove_background, edit_image, and detect_objects in the sibling list. Concrete examples ('person', 'car', 'watermark') make the intent 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?

Gives a clear prerequisite chain: 'Requires create_payment with toolName="remove_object"', plus the free-text instruction ('just say ...'). It does not explicitly say when to prefer this over remove_background or edit_image, so it stops short of full when/when-not routing.

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, the description carries the full load and mostly succeeds: it discloses cost (25 sats/image), the payment model (Lightning, no signup/API key), that background enhancement and face upsampling happen by default, and that the model is upgraded server-side under a stable endpoint. It omits what is returned on success and what happens on failure or timeout, which is a notable gap for a paid, non-deterministic-generative call.

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 purpose is correctly front-loaded in sentence one, but several later sentences are marketing rather than decision-relevant ('NeurIPS 2022, state-of-the-art FID 32.65 on CelebA-Test', 'Stable endpoint — model upgrades automatically as SOTA evolves'). The benchmark score and venue do not help an agent decide or invoke.

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?

Seven parameters, two required, no output schema and no annotations means the description must be thorough. Payment prerequisites and cost are well covered, but the return value is never described and the resultKey idempotent-retry mechanism appears only in the schema, leaving the agent unprepared for async behavior.

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's fidelity sentence and 'also enhances background and upsamples' largely restate what the schema already documents for fidelity, background_enhance, and face_upsample, and it adds no practical guidance on choosing a fidelity value or a re-call strategy with resultKey.

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 ('Restore ... faces') plus the exact failure modes it targets (blurry, damaged, AI-generated), so the agent immediately knows what capability this is. It never mentions the near-duplicate siblings deblur_image or upscale_image, so the agent must infer the boundary itself.

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 gives a genuinely useful prerequisite: 'Requires create_payment with toolName="restore_face"', which tells the agent this cannot be called cold. But there is no when-to-use-vs-alternative guidance against deblur_image (non-face blur) or upscale_image (resolution only), which are the most confusable siblings in a 50+ tool catalog.

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

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

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?

Goes far beyond the openWorldHint/destructiveHint annotations: free pre-payment refusals vs. paid sends that re-check limits and refund in full, links added after payment being held and never sent, 24-hour refund eligibility handled by scheduled maintenance, signature line appended, and explicit retention windows (24h context records, 30-day transcripts, 25h max storage). This is exactly the operational detail an agent cannot derive from 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 purpose and payment prerequisite are front-loaded, but the remainder is an unstructured wall of legal, retention, and abuse-policy boilerplate (appeal pricing, de-identification methodology, provider record-keeping) that buries the operational rules an agent actually needs before invoking.

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 pay-per-use communications tool with no output schema, it covers prerequisites, refusal/refund outcomes, delivery timing ('a text to a US number can take a few hours'), and the appended signature. It is thin on how the send result is retrieved (async/queued status polling), which is a modest remaining 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?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by adding cross-parameter constraints the schema does not state: the phoneNumber must match the one used in create_payment, and the message must not require more SMS segments than were paid for.

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 the verb+resource ('Reach a human via SMS') and the triggering context ('when your task requires real-world coordination'), and the tool name confirms sending. It never names a sibling (send_email, send_fax, place_call, ai_call) to differentiate, so the agent must infer channel choice from the name alone.

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 strong hard prerequisite chain: 'Requires create_payment with toolName=send_sms and phoneNumber+message at payment time,' plus the rule that the phoneNumber must match the paid one. It also lists refusal conditions (no links, per-destination send limits, do-not-contact list), but offers no explicit comparison against alternative contact tools like send_email or place_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?

No annotations exist, so the description carries the full burden, and it does substantial work: discloses the Lightning payment model with no API key, states the return value (audio URL), the create_payment prerequisite, and a non-obvious failure mode (language is silently ignored on Inworld/Minimax rather than erroring). It does not state whether the call is synchronous or requires polling via check_job_status/await_result, which is a meaningful gap for a paid media-generation call.

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 tier comparison, then the exclusion list, then the prerequisite, so an agent can stop reading early if it only needs the routing decision. Dense but every clause carries information; the tier parentheticals are the only mildly noisy part given the modelId schema already repeats them.

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, fully-documented schema with no output schema, the description supplies the payment flow, return value, tier tradeoffs, and language caveat — nearly everything an agent needs. The main omission is execution mode (sync vs. must-poll), which matters given siblings like check_job_status and await_result and a paid call that can time out.

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 cross-parameter decision logic the schema cannot express: it maps tiers to modelId and ties language/voice selection together ('pick OmniVoice Global via language=', 'Minimax... voice cloning from reference clip'). That routing guidance is genuinely additive rather than restating field docs.

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 (text-to-speech) and immediately breaks it into three named tiers with differentiated quality/latency/cost (OmniVoice ~106 chars/sat, Inworld ~16, Minimax ~5) plus cloning capability. This is concrete enough that an agent can tell exactly what the tool does and which tier fits, distinct from siblings like generate_music or transcribe_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?

Explicit 'When NOT to use' section naming the three alternatives (place_call, ai_call, open_voice_bridge) and the condition that selects them. Adds rare-language routing ('pick OmniVoice Global via language=') and the hard prerequisite ('Requires create_payment with toolName=text_to_speech'). Nothing about when to use or avoid 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, so the description bears the full load and does so richly: pricing (10 sats/min, per-minute), ephemeral privacy guarantees, async requestId/polling flow, large-result truncation behavior with fullResultUrl, and degraded-result fallbacks. An agent knows cost, safety, and lifecycle before calling.

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 and the high-value timestamp distinction, then pricing, size limits, async flow, privacy, and payment. Dense but every sentence carries actionable information with no 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?

Async tool with no output schema, yet the description explains the return path (requestId, polling, get_job_result), truncation handling, and degraded outputs. Nothing an agent needs to call and consume results 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; the description adds value beyond the schema by noting 'names' is free and that word timestamps can trigger result truncation. Most parameter detail still lives in the schema, keeping it from 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 and resource ('Transcribe audio to text') and immediately differentiates its output modes (word-level vs segment timestamps). The sibling transcribe_translate is implicitly distinguished by the pure transcription framing.

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 explicit when-to-use for the 'word' timestamp mode (subtitle alignment, karaoke captions, cutting video) and describes the prerequisite workflow (requires create_payment, poll with check_job_status, then get_job_result). It does not directly contrast with the transcribe_translate sibling, so not a full 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?

No annotations are provided, so the description carries the full burden. It discloses async behavior (returns requestId, poll with check_job_status), payment prerequisite (create_payment with toolName), flat pricing, and a critical billing caveat: a wrong sourceLanguage hint yields a garbled transcript still billed as success. It also notes names are free and may degrade if refused.

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 compound purpose, then covers examples, async, pricing, and payment. Slightly repetitive on pricing ('flat price covers STT + translation' and 'cheaper than...'), but every sentence carries useful context.

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 the critical workflow, language limits, async polling, and billing caveats. It does not specify the final result shape or field names, leaving some retrieval ambiguity.

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 parameters are already well documented. The description repeats key constraints (auto-detect source, 119 target languages, names free) but adds no parameter syntax or semantics beyond what the schema 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?

States a specific compound operation: converts audio into both a transcript and a translation across 13 source and 119 target languages. Distinguishes from siblings by naming transcribe_audio + translate_text alternatives and the check_job_status/create_payment 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?

Provides clear use cases (WhatsApp voice messages, meeting recordings) and a comparative alternative (cheaper than separate calls for typical voice messages). Lacks explicit when-not-to-use exclusions, so not a full 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 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.