Sats4AI - Bitcoin-Powered AI Tools

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

Discloses multiple behavioral traits: auto-retry on voicemail (up to 3), returns transcript with structured analysis, possible pending_confirm state requiring confirm_ai_call, async polling via check_job_status, cost estimate, language support, and payment method. No annotations provided, but description covers all key behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but well-structured, with core purpose first, then features, usage guidance, and dependencies. Every sentence provides useful information. Slight room for tightening, but efficient overall.

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, the description covers return behavior (transcript, pending_confirm), async nature, payment requirements, cost range, languages, and alternatives. Thorough for a complex tool with 6 parameters and multiple behavioral aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds significant value beyond schema by explaining language guessing logic, voice auto-selection, bilingual region defaults, and the role of paymentId, task, and beginMessage. Provides practical guidance for parameter usage.

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 sends an AI voice agent to handle phone calls requiring human interaction, with specific verb and resource. It distinguishes from siblings like open_voice_bridge, place_call, and send_sms.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use (human-needed tasks), when not to use (own LLM, one-shot TTS, SMS), and lists alternative tools. Also states prerequisite create_payment with specific fields.

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 cost (21 sats), payment mechanism (Bitcoin Lightning), auth model (no API key), and prerequisite dependency. Omits whether operation is sync/async (siblings suggest async tooling possible) and what return value contains.

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 efficiently structured: functionality → model details → cost → auth → prerequisites. Front-loaded with core capability. Each sentence earns its place without redundancy, though dense with operational details.

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

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

Strong coverage of operational context (pricing, payment flow, model specifics) given good schema coverage. Missing output description (no output schema exists) and image format constraints, but prerequisites are clearly documented.

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 complete property descriptions. Description adds payment workflow context explaining how to obtain paymentId, but baseline 3 applies given schema already documents all parameters fully.

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?

Specific verbs (analyze, describe, extract, answer) with clear resource (image content/screenshots/photos). Explicitly distinguishes from siblings like generate_image or edit_image by detailing Qwen VL capabilities (OCR, chart reading, spatial reasoning).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite workflow ('Requires create_payment with toolName='analyze_image''), which is critical for invocation. Includes cost information (21 sats per image) that informs usage decisions. Lacks explicit 'when not to use' guidance regarding siblings like extract_receipt or detect_objects.

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, description carries full burden effectively: discloses async nature, return value (requestId), polling requirement, authentication model (no API key, Lightning payment), rate/cost structure, duration constraints, and preservation characteristics of the output.

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-dense with zero fluff. Front-loaded with purpose ('Animate a still image...'), followed by behavioral details, async instructions, pricing, and prerequisites. Slightly dense syntax (em-dash heavy single paragraph) but every clause 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?

Comprehensive for a complex paid async tool: covers input requirements (imageBase64, prompt), business logic (Lightning payment, 100 sats/sec), temporal constraints, async workflow (requestId return, polling), and output characteristics. No output schema exists but description adequately explains the immediate return value.

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% (baseline 3). Description adds critical workflow context for paymentId (must obtain via create_payment with toolName='animate_image') and reinforces duration constraints (3-15 seconds) mentioned in schema. Provides origin context for the payment parameter beyond schema's 'Valid payment ID'.

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 specific action (animate still image into video) and distinguishes from siblings like generate_video by emphasizing source image fidelity and camera movement on existing images. Specific technology (Grok Imagine Video) and motion characteristics are noted.

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 defines the required workflow: prerequisite call to create_payment with specific toolName parameter, and subsequent polling via check_job_status (sibling tool explicitly named). Mentions cost structure (100 sats/sec) and Lightning payment requirement. Lacks explicit comparison to when generate_video might be preferable.

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?

Since no annotations are provided, the description fully covers behavioral traits: return format (JSON with status, requestId, jobType, plus progress fields for epub-audiobook), free usage, and error handling. No contradictions or missing crucial info.

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 well-structured and every sentence contributes useful information. It could be slightly more concise, but the clarity and completeness justify the length.

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 is fully complete for a 2-parameter tool with no output schema. It covers all necessary behavioral and contextual details, including polling guidance and error handling, leaving no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters described), but the description adds significant value by explaining the mapping of jobType enum values to the originating async tools, going beyond the schema's 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 the tool's purpose: 'Poll the status of an async job.' It lists all the specific async tools that return a requestId, and explicitly distinguishes from synchronous tools, making it easy to understand when to use.

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 guidelines: when to use (after async tools), when not to use (synchronous tools), recommended polling interval (every 5-10 seconds), and next steps depending on status ('completed' → get_job_result, 'failed' → do not retry).

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

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

No annotations are provided, so the description carries full burden. It discloses return format, expiration (10 minutes), and that it's free. Could note idempotency or rate limits, but sufficient.

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. No fluff, but slightly longer than needed. Efficient overall.

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

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

For a simple one-param tool with no output schema, the description covers purpose, return format, usage sequence, expiration, and cost. Fully adequate.

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 has 100% coverage with description 'The paymentId returned by create_payment'. The tool description adds usage context but no new parameter semantics beyond schema. 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 clearly states the tool checks if a Lightning invoice is paid, with a specific verb and resource. It distinguishes itself from siblings like check_job_status and ties to create_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call after create_payment to verify the user has paid before calling the target tool.' Provides guidance on expiration and instant payment, covering when to use and when to recreate.

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?

Excellent disclosure given zero annotations: states cost per call (7,500 sats), payment method (Bitcoin Lightning), output persistence ('indefinitely'), and quality characteristics (tone, cadence, accent). Delineates Turbo vs HD behavioral modes. Minor gap: doesn't describe error conditions or file requirements.

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-dense but front-loaded with purpose and output. Each sentence delivers distinct value (capability, output, quality, cost, prerequisites). Slightly packed but no redundancy given complexity and lack of annotations/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?

Highly complete for a 4-parameter tool with no output schema and no annotations. Explicitly documents return value (voice_id), cost model, authentication method (no API key), prerequisite dependency, and sibling integration (text_to_speech). Covers all critical decision-making factors.

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%, establishing baseline 3. Description adds valuable context: 'single audio sample' clarifies voiceFileUrl constraints, and explicitly frames the model enum as speed-vs-quality tradeoff. 'Text validation accuracy' parameter remains unexplained (cryptic schema description), preventing 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?

Clear specific verb 'Clone' with resource 'voice'. Explicitly distinguishes from sibling text_to_speech by stating it returns a voice_id 'for text_to_speech', clarifying the workflow relationship.

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 prerequisite workflow 'Requires create_payment with toolName='clone_voice''. Names the consuming sibling tool (text_to_speech) for the output. Pricing information (7,500 sats) clarifies cost context.

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, description carries full burden and discloses payment requirements, model characteristics ('vivid, natural'), and input constraints. Minor gap: does not specify output format or error behavior, though purpose is clear.

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 dense sentences covering: 1) core function, 2) technical specs, 3) cost/capability distinction, 4) prerequisites. No redundancy; front-loaded with essential selection criteria.

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?

Strong coverage of unique payment integration and model specifics. Minor deduction for no output schema and lack of explicit return value description, though 'colorize' implies image output sufficient for tool selection.

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 has 100% coverage (baseline 3), but description adds critical workflow context explaining that paymentId comes from create_payment with specific toolName parameter—essential context not evident from 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?

States specific action ('Colorize black-and-white or grayscale photos'), identifies the underlying technology (DDColor), and distinguishes from siblings by noting this is 'Impossible for text/vision LLMs'—directly contrasting with ai_call and analyze_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?

Explicitly states prerequisites ('Requires create_payment with toolName='colorize_image''), cost model ('5 sats per image'), and payment method ('Bitcoin Lightning'). Provides clear workflow guidance absent from schema.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains payment behavior (reuses original), return value (call_id), and workflow integration (polling mechanism). It does not explicitly characterize the mutation nature or idempotency, but covers the critical behavioral traits for this workflow step.

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 with zero waste. Front-loaded with the core action (confirm), followed by trigger condition, payment clarification, and return value/next step. Every sentence delivers essential workflow 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?

Despite no output schema and no annotations, the description comprehensively covers the tool's role in the multi-step workflow, explains the return value (call_id), documents the payment behavior, and specifies the exact trigger condition from the sibling ai_call tool. Complete for a workflow orchestration 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?

While schema coverage is 100%, the description adds valuable semantic context: it clarifies that 'answers' are for 'missing info' (connecting to 'push-back questions' mentioned earlier) and implies sessionId originates from the ai_call response. This provides workflow context beyond the schema's structural definitions.

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 specific action (confirm an AI call) and resource (AI call), distinguishing it from the sibling ai_call tool by positioning it as the follow-up step required when ai_call returns state='pending_confirm'. It also differentiates from create_payment by noting no new payment is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly defines when to use the tool ('Required when ai_call returns state='pending_confirm''), when not to use alternatives ('Uses the original payment — no new payment needed'), and what to do next ('Returns call_id for polling with check_job_status'). Provides a complete workflow map.

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 return value ('Returns download URL'), cost ('100 sats'), quality characteristics ('preserves formatting and quality'), and auth model ('no API key, no account'). Does not mention rate limits or error 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?

Six information-dense sentences each earning their place: formats supported, quality claim, return value, cost, payment method, and prerequisite. No filler text; well front-loaded with capability overview.

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

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

Given no output schema, description compensates by stating return type (download URL). Adequately covers payment complexity and conversion scope. Minor gap: no mention of file size limits or async job handling (though 'check_job_status' sibling exists).

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?

Input schema has 100% description coverage, establishing baseline 3. Description adds implicit context about valid format values (e.g., 'pdf', 'docx') and cost context for 'paymentId', but does not add syntax details beyond what 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?

Description uses specific verb 'Convert' with resource 'files' and explicitly lists scope (200+ formats across documents, images, audio, video). It distinguishes from sibling 'convert_html_to_pdf' by emphasizing broad format support vs. single-format conversion.

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 prerequisite workflow: 'Requires create_payment with toolName='convert_file'' and payment context ('100 sats', 'Pay per request'). Clear context for when to use (after obtaining payment ID), though does not explicitly mention when to use sibling 'convert_html_to_pdf' instead.

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

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

Despite no annotations, the description fully discloses behavior: returns JSON with temporary URL (valid ~1 hour), costs 50 sats, requires payment via create_payment, and does not need API key. It covers output, limitations, and prerequisites.

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 yet comprehensive, front-loading the main action and output, then providing use cases, alternatives, and payment details without unnecessary 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?

Covers all essential aspects: input formats, output structure (JSON with url and validity), payment integration, and differentiation from similar tools. No gaps given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% parameter descriptions, but the description adds context: html can be HTML or Markdown, format defaults to html, paymentId must be paid. It explains the payment flow and the Markdown option beyond schema.

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

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

The description explicitly states 'Convert HTML or Markdown to a pixel-perfect PDF', providing a specific verb and resource. It distinguishes from sibling tools by mentioning 'Use convert_file instead for converting existing files'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when to use ('Great for generating invoices, reports...') and when not to ('Use convert_file instead for converting existing files'). Also specifies format parameter for Markdown input.

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 description carries full burden. Discloses invoice expiry (10 minutes), one payment per call, pricing logic dependent on parameters, return JSON, and error handling. Does not discuss authentication or rate limits but is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with core purpose and return type, then typical flow and parameter details. Every sentence adds value, though slightly long; still well-structured and efficient.

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

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

Given the complexity (12 params, multiple tools) and no output schema, the description covers return format, error handling, parameter requirements, and typical flow. Could mention idempotency or concurrency but overall complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions. The description adds significant value by grouping params per tool, explaining pricing dependencies (e.g., generate_text price = f(char count)), defaults (e.g., modelId optional, generate_audio default false), and missing param error 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 clearly states it creates a Lightning invoice for one AI service call, specifies the return JSON with paymentId, invoice, amount, expiresAt, and distinguishes it from siblings by describing the typical flow (list_models → create_payment → check_payment_status → call tool).

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 a typical flow and explains when to call this tool (once per operation). It details which parameters are required for which tools, and describes error behavior when required params are missing. Lacks explicit when-not-to-use but the context is 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?

No annotations provided, so description carries full burden. Discloses extensive behavioral traits: technical approach (NAFNet, ECCV 2022), cost (20 sats), latency (~2 min), auth model (Bitcoin Lightning, no API key), and workflow dependency (create_payment prerequisite). Also covers secondary capability (denoising).

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-dense with zero waste. Front-loaded with core capability ('Recover detail...'), followed by technical validation, use-case boundaries, alternative modes, pricing/timing, and prerequisites. Every sentence serves distinct purposes (capability, constraints, cost, workflow).

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

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

Given the complexity (payment workflow, async processing, multiple task types), description is complete. Covers cost, timing, prerequisites, and technical limitations. No output schema exists, but description implies return type (processed image) sufficiently for tool selection.

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%, establishing baseline 3. Description adds critical workflow context explaining that paymentId requires pre-calling create_payment specifically with toolName='deblur_image'. Also clarifies the denoising option in prose, reinforcing the task_type enum 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?

Specific verb ('Recover detail') + resource ('camera-shake and accidental motion blur') + clear scope. Distinguishes from siblings by explicitly stating 'NOT effective for: intentional panning blur, bokeh/depth-of-field, or artistic motion effects,' differentiating it from general image editing tools like edit_image or animate_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?

Explicit positive constraints ('Best for: handheld shake, bumped camera, whole-frame uniform blur') and negative constraints ('NOT effective for...'). Clear prerequisite stated: 'Requires create_payment with toolName='deblur_image'.' Provides complete 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?

With no annotations provided, the description carries the full burden and successfully discloses cost (2 sats/image), payment mechanism (Bitcoin Lightning), authentication model (no API key), and return format. Minor gap in not describing error states or rate 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?

Six sentences efficiently cover: function, provider/performance, return values, use case, pricing/auth, and prerequisites. No redundancy; information is front-loaded with the core classification purpose.

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

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

Despite no output schema existing, the description fully documents the return structure (label + boolean flag). Given the complexity of the payment workflow and 100% schema coverage, the description provides all necessary context for 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?

While schema coverage is 100%, the description adds crucial semantic context that the 'paymentId' parameter must be obtained via the 'create_payment' tool, clarifying the orchestration flow beyond the schema's 'Valid payment ID' string 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 opens with the specific action 'Classify image safety' and the discrete categories (normal/suggestive/explicit), clearly distinguishing this from the generic 'analyze_image' sibling tool. It also explicitly states the return values (classification label and is_nsfw flag).

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 prerequisite workflow ('Requires create_payment with toolName='detect_nsfw''), provides the use case context ('Essential for content moderation pipelines'), and contrasts with alternatives ('100x cheaper and faster than asking an LLM').

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, description carries full burden and discloses: cost per request, Bitcoin Lightning payment method, no API key requirement, prerequisite workflow (create_payment), and output format (bounding box coordinates and confidence scores). Omits rate limits or error behavior, but covers primary 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?

Five sentences, each earning its place: purpose, technology/I/O, differentiation, pricing/auth, prerequisites. Front-loaded with core action, no redundancy. Efficient density of operational, financial, and technical 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?

Comprehensive given medium complexity (payment integration, 5 params, no output schema). Compensates for missing annotations with payment workflow details and clarifies return values (bounding boxes) since no output schema exists. Minor gap in error handling or retry 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?

Despite 100% schema coverage (baseline 3), adds crucial semantic context: describes 'query' as accepting 'natural language' (Grounding DINO capability) beyond schema's 'Comma-separated' example, and clarifies 'paymentId' requires calling create_payment first. Adds value beyond raw schema definitions.

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

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

States specific verb+resource ('Detect and locate objects in an image') and identifies the technology (Grounding DINO). Effectively distinguishes from vision-based siblings by emphasizing 'Structured pixel data agents can't get from vision LLMs', clarifying this provides bounding boxes rather than descriptions.

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 prerequisite ('Requires create_payment with toolName='detect_objects''), cost structure ('5 sats per image'), and authentication model. Clear context on when to use versus vision LLMs (when structured pixel/bounding box data is needed), though it doesn't explicitly name sibling alternatives like analyze_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?

No annotations provided, but description discloses model (Nano Banana 2), output format (JSON with image URL), pricing tiers (1K/2K/4K with satoshi costs), and authentication method (Lightning vs API keys). Minor gap on error handling or rate 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?

Information-dense sentences covering capability, model, output, pricing, and prerequisites without redundancy. Front-loaded purpose followed by operational requirements.

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 paid mutation tool with no output schema and no annotations, the description adequately covers return values, pricing, authentication prerequisites, and model capabilities. Complete enough for agent invocation planning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds critical workflow context for 'paymentId' (requires create_payment call) and reinforces the pricing implications of 'resolution' choices within the overall payment flow.

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?

Specific verb-resource ('Edit an image') and scope (natural language instructions). Lists distinct capabilities (object addition/removal, style transfer, inpainting) that distinguish it from specialist siblings like 'remove_background' 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?

Explicitly names prerequisite tool 'create_payment' with specific parameters (toolName='edit_image', resolution). Clarifies payment model (Bitcoin Lightning, per-request) implicitly guiding against use without payment workflow.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it ends a call, finalizes billing, and returns a refund link and transcript. However, it lacks details on permissions, rate limits, error handling, or whether the action is reversible, which are important for a tool that likely involves financial transactions and call termination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the main action ('Hang up a Voice Bridge call') and efficiently lists additional outcomes. Every part earns its place by conveying essential information without redundancy or unnecessary details.

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

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

Given the complexity of a tool that handles call termination, billing, and refunds, with no annotations and no output schema, the description is somewhat complete but has gaps. It covers the core purpose and key outputs (refund link, transcript), but lacks information on error cases, response format, or dependencies, which could hinder an agent's ability to use it correctly in all scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining that the sessionId comes from 'open_voice_bridge', providing context beyond the schema's generic description. This helps the agent understand the parameter's origin and relationship to other 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 clearly states the specific action ('Hang up a Voice Bridge call'), the resource ('Voice Bridge call'), and distinguishes it from siblings by referencing 'open_voice_bridge' as the source of the sessionId. It also mentions additional outcomes like finalizing billing and providing a refund link, which sets it apart from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by referencing 'open_voice_bridge' for the sessionId, suggesting this tool should be used after opening a call. However, it does not explicitly state when to use it versus alternatives like 'poll_voice_bridge' or 'request_refund', nor does it provide exclusions or prerequisites beyond the sessionId requirement.

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, time range, payment requirement, and single-step outcome. No annotations provided, so description carries burden. Could mention error handling, but adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is moderately long but well-structured with key points separated by periods. Slightly verbose but informative.

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 workflow, voice tiers, translation, and payment requirement. No output schema, but implied result. Generally complete for a complex 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%, yet description adds value by explaining voice tiers, char rates, and translation details, going beyond 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 it converts books to audiobooks with specific features (chapter detection, multi-voice, translation). It distinguishes from siblings by being the only audiobook conversion tool.

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 guidance on async nature, polling, single payment, and prerequisite create_payment. Lacks explicit when-not-to-use but sufficient due to no similar siblings.

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

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

No annotations provided, so description carries full burden. Discloses technology (Mistral OCR), output format (hierarchical Markdown), cost structure (10 sats/page), and auth requirements (none needed). Minor gap: no mention of rate limits, error conditions, or maximum file 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?

Four dense sentences covering capability, technology, output format, and pricing/prerequisites. Zero redundancy. Front-loaded with primary action (Extract text...). Efficient use of em-dashes to combine related clauses without verbosity.

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?

Complete for a payment-gated OCR tool: explains the payment prerequisite (create_payment), cost calculation, supported input formats (PDF/image), output format (Markdown), and underlying technology. No output schema present, but description adequately characterizes return value (clean Markdown).

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% (baseline 3), but description adds critical workflow context: explains that multi-page PDFs require quantity=pageCount when calling create_payment, linking the paymentId parameter to the prerequisite payment workflow. Enhances understanding of documentBase64 relationship to page count.

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?

Explicitly states 'Extract text from PDFs and images as clean Markdown' with specific capabilities (tables, handwriting, math notation). Distinguishes from sibling extract_receipt by emphasizing complex layout handling and general document support rather than specific receipt 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?

Explicitly documents prerequisite workflow: 'Requires create_payment with toolName='extract_document' and quantity=pageCount for multi-page PDFs.' Also clarifies payment model (10 sats/page, Bitcoin Lightning, no API key) specific to when this tool should be invoked.

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 processing pipeline (Mistral OCR + Kimi K2.5), robustness features (handles crumpled/faded/multi-page), authentication model (no API key), and cost structure. Minor gaps: doesn't mention data retention, rate limits, or error scenarios (e.g., invalid payment).

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?

Well-structured with 6 sentences each earning their place: purpose, technical method, output specification, capabilities, pricing, prerequisites. No redundant filler, appropriately sized for complexity.

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-requiring OCR tool, covers purpose, prerequisites, cost, output structure (compensating for missing output_schema), and input capabilities. Could strengthen with error handling, rate limits, or data retention policy given the financial sensitivity.

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 clear descriptions ('Valid payment ID', 'Base64 encoded receipt/invoice image'). Description contextualizes parameters (document types supported, payment requirement) but doesn't add syntax/format details beyond the schema. Appropriate baseline 3 given schema completeness.

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?

Clear specific verb ('Extract structured data') and resource ('receipts, invoices, and financial documents'). Distinguishes from sibling 'extract_document' by specializing in financial documents and specifying JSON output fields (merchant, date, line items, etc.).

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 prerequisite workflow ('Requires create_payment with toolName='extract_receipt''), payment method (Bitcoin Lightning), and cost model (50 sats/page). Minor gap: doesn't explicitly contrast when to use vs sibling 'extract_document' (financial vs general docs).

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 async nature, model provider (Tencent Hunyuan3D), quality (high-fidelity geometry, PBR materials), cost (350 sats), payment method (Bitcoin Lightning, no API key), and prerequisite (create_payment with specific toolName). 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?

Two sentences, no fluff. First sentence defines core function and inputs. Second packs in model info, async, cost, payment, and prerequisites.

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 covers essential aspects: inputs, async polling, cost, payment. It could mention the expected result format (GLB file URL) but references check_job_status for retrieval, so it's mostly 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%, and the description adds critical meaning: mutual exclusivity of prompt and imageBase64, that paymentId must be paid, and implicitly the async return via 'returns requestId, poll with check_job_status'.

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 specifically states 'Generate a textured 3D GLB model' and clarifies two input modes (photo or text prompt) with 'EITHER...OR', distinguishing it from sibling tools like generate_image or 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 explains input constraints (provide exactly one, not both), async behavior with polling via check_job_status, and payment requirements. It could be more explicit about when not to use (e.g., real-time needs), but overall provides clear usage context.

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 output format ('JSON with image URL'), cost structure (100/150/200 sats per model), payment mechanism (Bitcoin Lightning), and model lifecycle ('upgrade automatically as SOTA evolves'). Minor gap: does not clarify if operation is synchronous or requires polling via check_job_status sibling.

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?

Highly information-dense yet readable. Front-loaded with core purpose. Each sentence conveys distinct critical information: output format, model pricing tiers, img2img support, endpoint stability, and payment prerequisites. No wasted words despite covering complex payment and model selection logic.

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 lack of annotations and output schema, description comprehensively covers payment integration, model selection criteria with costs, return format, and input variations. Minor gap: does not indicate if operation is async (relevant given check_job_status sibling exists) or mention rate limits/content restrictions.

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 has 100% coverage (baseline 3). Description adds semantic value by mapping modelId numbers to specific models (Grok Imagine, Seedream 4, Nano Banana 2) with cost and quality attributes. Clarifies imageBase64 purpose ('img2img'). References paymentId via prerequisite workflow explanation.

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?

Specific verb 'Generate' + resource 'image' + source 'text prompt'. Distinguishes from sibling tools like edit_image, upscale_image, and colorize_image by specifying creation from prompt. Also clarifies img2img capability, further differentiating it from pure generation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite workflow 'Requires create_payment with toolName='generate_image'' and clarifies access method ('no API key or signup needed'). Does not explicitly guide on when to use specific models (Grok vs Seedream) or when to use img2img versus text-only generation.

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 duration limit, BPM/key accuracy, model version, style mixing, cost, and return format. No annotations provided, so description carries full burden; missing rate limits or 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?

Four sentences, front-loaded with key capabilities. Slightly verbose in listing section tags but overall concise and structured.

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 payment flow, output format, duration, model, style. With 9 parameters and no output schema, description is fairly complete; schema handles remaining parameter 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 has 100% description coverage, setting baseline at 3. Description adds context for prompt and paymentId but does not elaborate on other parameters 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 tool generates full songs with AI vocals, BPM/key control, and precise arrangement. Distinct from siblings like generate_image or generate_text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on payment requirement (create_payment), prompt contents, and no signup needed. Lacks explicit when-not-to-use or comparison to similar tools like text_to_speech.

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 pricing (per-character, no minimum), model upgrade policy, and payment requirement. However, it lacks details on rate limits, error handling, or response format, which would be helpful given the tool's complexity.

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 relatively concise but packs a lot of information. It front-loads the main purpose and payment model. Could benefit from structured formatting (e.g., bullet points) for the model list, but overall efficient.

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 8 parameters and no output schema, the description covers core aspects (models, pricing, prerequisites). It could elaborate on the fileContext usage and error scenarios, but it is largely sufficient for an agent to use 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 significant value beyond the schema: explains modelId omits default models, fileContext for Q&A, imageBase64 limited to best model, and paymentId must be paid. The model details (speed, languages, context) enrich understanding.

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 as generating text using frontier AI models, lists specific models with IDs and capabilities, and distinguishes from sibling tools (e.g., image, audio, translation) by focusing solely on text generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit prerequisites (create_payment with exact prompt), model selection guidance (omit modelId for default), and mentions file Q&A and vision analysis use cases. However, it does not explicitly contrast with alternatives like 'translate_text' or 'generate_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, description carries full behavioral burden and succeeds comprehensively: discloses async execution pattern (returns requestId, requires polling), specific cost structure (300-550 sats/sec with audio premium), authentication model (Bitcoin Lightning, no API key), duration constraints (3-15s), and specific model characteristics (Kling v3 capabilities). Zero contradictions with implicit safe defaults.

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-dense but efficient multi-sentence structure organizes by: capability (what it does), model specs (Kling v3), quality modes, async behavior, pricing, payment method, and prerequisites. Every clause provides actionable information (pricing tiers, polling instructions, parameter mappings). Minor density could benefit from line-break separation but no extraneous content present.

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?

Exceptionally complete for a complex paid async service despite no output schema. Covers the full operational lifecycle: payment creation prerequisites → invocation cost structure → async polling pattern → result retrieval. Addresses economic constraints (sats/sec pricing), temporal constraints (3-15s), and integration requirements (Lightning payment) that would otherwise be opaque.

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 has 100% coverage establishing baseline 3, but description adds critical semantic context linking parameters to workflow: specifies paymentId comes from create_payment tool, elaborates that mode maps to quality/cost tiers ('standard and pro quality modes'), adds pricing implication for generate_audio ('adds 100 sats/sec'), and clarifies duration affects cost calculation. Meaningfully augments schema definitions.

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 opens with specific verb+resource ('Generate a video from a text prompt') and clearly distinguishes from sibling tools by specifying Kling v3 model, cinematic quality, and unique pay-per-request Bitcoin Lightning method. Explicitly differentiates from generate_image and generate_music by describing video-specific features like 'consistent motion' and 'physics-aware rendering'.

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 excellent prerequisite guidance: explicitly states 'Requires create_payment with toolName='generate_video' and duration, mode, generate_audio params' identifying the exact sibling tool and parameter mapping needed before invocation. Also clearly documents async pattern ('returns requestId, poll with check_job_status') establishing the correct workflow sequence with check_job_status sibling.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key traits: it's a read-only operation ('no payment required, no side effects'), returns specific data ({ amount_sats, breakdown, currency }), and has conditional behavior (omit params for catalog). However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some behavioral aspects uncovered.

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 efficiently structured with front-loaded key information (purpose and usage), followed by parameter examples and return format. Every sentence serves a distinct purpose: stating the tool's function, its utility, behavioral traits, parameter usage, and output. There is no wasted text, making it highly concise and well-organized.

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

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

Given the complexity (6 parameters, no output schema, no annotations), the description does a strong job by covering purpose, usage, behavior, and parameter semantics. It explains the return format ({ amount_sats, breakdown, currency }), compensating for the lack of output schema. However, it doesn't detail error handling or authentication, leaving minor gaps in completeness.

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 value by explaining parameter usage with examples ('Pass service=text-to-speech&chars=1500') and clarifying semantics ('Omit params to see the full catalog'), which helps the agent understand how to combine parameters meaningfully beyond the schema's individual 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 the tool's purpose with specific verbs ('Get an exact sat cost quote') and resources ('for a service'), distinguishing it from siblings like 'create_payment' or 'get_model_pricing' by emphasizing it's for pre-commitment pricing without payment. It explicitly mentions what it does (quote) and what it doesn't do (no payment, no side effects).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('BEFORE creating a payment', 'Useful for budget-aware agents to price-check before committing') and when not to use it ('No payment required'), with clear alternatives implied (e.g., use 'create_payment' for actual payment). It also specifies context ('omit params to see the full catalog'), offering comprehensive usage instructions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that no payment is required, which is useful behavioral context. However, it lacks details on rate limits, authentication needs, or response format, leaving gaps for a tool that agents might rely on for 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?

The description is highly concise and front-loaded, with two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value, and there is no redundant or wasted text.

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 simplicity (0 parameters, no annotations, no output schema), the description is mostly complete. It explains what the tool does and when to use it. However, without an output schema, it could benefit from clarifying the return format (e.g., JSON list, structure), which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description adds no parameter information, which is appropriate here. A baseline of 4 is given since no parameters exist, and the description doesn't need to compensate for any gaps.

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: to retrieve a catalog of error codes for the API. It specifies the verb ('Get') and resource ('machine-readable catalog of all error codes'), and distinguishes itself from siblings by focusing on error handling rather than core operations like image generation or text processing.

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 states when to use this tool: 'Agents should branch on error_code rather than parsing free-text messages.' It also clarifies when not to use it ('No payment required'), distinguishing it from payment-related siblings like create_payment or check_payment_status.

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

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

With no annotations, the description fully discloses behavior: returns error if called prematurely, output shape depends on jobType, URLs are temporary (~1 hour), and no payment required. No contradictions or omissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-organized paragraph, front-loaded with the core purpose, followed by conditions and output details. Every sentence provides necessary information without unnecessary words.

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

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

Given the absence of an output schema, the description thoroughly specifies the return shape for each of the 6 job types, including URL expiry warnings. It covers all necessary context for correct invocation and handling of results.

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 both parameters 100%, but description adds value by mapping jobType enum values to the corresponding async tool names, which is not in schema. For requestId, it repeats schema text, so minimal extra value. Overall, slight improvement over baseline 3.

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 retrieves the final output of a completed async job, specifies the precondition (after check_job_status returns completed), and distinguishes from synchronous tools. The verb 'retrieve' and resource 'final output of completed async job' are specific and 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?

Explicitly instructs to call only after status='completed', warns of error otherwise, and clarifies not for synchronous tools. Also states the tool is free, providing comprehensive usage guidance.

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

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

With no annotations provided, the description carries full disclosure burden. It successfully communicates the cost-free nature ('No payment required') and implies read-only behavior via 'Get'. However, it omits return format details, rate limiting concerns, or whether pricing is real-time vs cached, which are important given the transactional context of sibling tools like 'create_payment' and 'check_payment_status'.

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 efficient two-sentence structure. First sentence delivers the core purpose immediately; second sentence provides the critical behavioral constraint regarding payment. No redundant words or tangential 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?

Appropriate for a simple single-parameter lookup tool. Covers the essential 'what' and 'cost' aspects. Given the lack of output schema, it could benefit from hinting at return structure (e.g., 'returns pricing details'), but the name makes the return value obvious enough for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the single 'modelId' parameter already well-described as 'The AI model database ID'. The description references 'by ID' but adds no additional semantic context (e.g., 'obtained from list_models' or expected ID format) beyond what the schema provides. Baseline score appropriate for high-coverage 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?

Clear verb-resource combo ('Get pricing for a specific model by ID'). Distinguishes from sibling 'list_models' by focusing on pricing retrieval for a specific entity vs. general listing. However, 'model' domain (AI vs 3D) isn't explicitly clarified in the description text itself, though the parameter schema clarifies it refers to 'AI model database ID'.

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?

Includes 'No payment required' which provides prerequisite guidance (can be called without initiating payment). However, lacks explicit guidance on when to use this vs. 'list_models' or 'check_payment_status', and doesn't indicate if this should be called before 'ai_call' or as a standalone lookup.

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?

In the absence of annotations, the description fully discloses the tool is free, requires no payment, is idempotent, and safe to call repeatedly. Also describes the return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient with no redundant sentences, but the information could be even more compact. Still, 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 the simplicity of the tool (listing models), the description covers purpose, usage, safety, return format, and parameter filtering. No gaps remain for a read-only, no-payment 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 single parameter (category) already has a clear enum and description in the schema. The description adds context by saying it narrows results to a specific tool, which is helpful but not essential.

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 discovers AI models and lists their attributes, tying directly to finding a modelId for create_payment. It distinguishes from sibling tools like get_model_pricing by its 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?

Explicitly advises calling before create_payment and notes the tool is free, no payment required, and idempotent. Lacks explicit 'when not to use' but provides clear context.

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 covers behavior: idempotent, safe to call repeatedly, returns JSON array with specified fields sorted descending. No payment needed. 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?

Three concise sentences with front-loaded key info. Every sentence adds value, no redundancy. Perfectly structured.

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 or parameters, the description fully explains return format, sorting, idempotency, and free nature. It references the related sibling tool, making the context 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?

No parameters exist; baseline is 4 per rules. The description adds no extra parameter info but explains output semantics, which is valuable but not strictly parameter-related.

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 lists all planned services with vote counts, return format, and sorting order. It distinguishes itself from the sibling vote_on_service by noting the slug usage for 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?

It explicitly says when to use (to discover free planned services) and provides context: no payment required, use slugs with vote_on_service for voting. It effectively guides the agent on subsequent actions.

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 all behavioral traits: preserves bookmarks/links/formatting, returns JSON with temporary download URL (1 hour), concatenates in array order, cost 100 sats, no API key needed, payment via Bitcoin Lightning. Since no annotations exist, description carries full burden and meets it completely.

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?

Very concise: single paragraph covers purpose, details, constraints, cost, alternative, and prerequisite. No extraneous words, logically ordered.

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, description fully explains input (base64, min 2, no max), output (JSON with url, temporary), payment model, cost, and alternative. Leaves no gaps for an AI agent to misuse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but description adds context: 'base64-encoded', 'minimum 2', and 'no maximum' for files, plus paymentId is explained via payment process. Provides marginal value beyond schema by reinforcing constraints.

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 'Merge multiple PDF files into a single document' with specific verb and resource. Also distinguishes from sibling 'convert_file' by pointing out alternative use case.

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 (PDF merging) vs when not (format conversion via convert_file). Includes constraints like minimum 2 files, no maximum, and payment prerequisite requiring create_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?

Discloses privacy (transcripts in memory, GC after 30 min, audio never persisted), payment via Lightning without signup, refund of unused deposit, and the required flow (create_payment first). No annotations provided, so description carries full burden and meets it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but each sentence contributes meaningful information. Could be split into sections for improved readability, but not overly 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 no output schema and 8 parameters, the description thoroughly covers the initiation flow, related tools (voice_bridge_say, poll_voice_bridge, end_voice_bridge), privacy, payment, and refund. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by explaining the refund mechanism, the need for specific toolName in paymentId, phone number format, and deposit rates. Slightly above baseline 3.

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 opens a Voice Bridge session, a live phone call with the LLM as the brain. It distinguishes from siblings like ai_call and place_call by detailing the composable primitives and self-driven interaction.

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 (privacy, self-driven turns) and when not to use (for fully-managed agent calls use ai_call, one-shot broadcasts use place_call, when polling adds no value). Provides clear alternatives.

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

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

No annotations provided, so description carries full burden. Discloses payment model (Bitcoin Lightning, no KYC) and prerequisite payment flow, but omits behavioral details like failure modes, retry logic, whether the call is blocking/async, or irreversible cost consumption.

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: purpose definition, usage context, and prerequisites. Every sentence earns its place with zero waste. Front-loaded with specific action ('Bridge the digital-physical gap').

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?

Lacks output schema and description doesn't explain return values (job ID? status?), leaving agent uncertain about invocation results. Prerequisites are well-covered, but post-invocation behavior is undocumented given the async/job-checking siblings available.

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?

Despite 100% schema coverage (baseline 3), description adds crucial semantic context explaining that paymentId must originate from create_payment with specific parameters (toolName='place_call' and phoneNumber), which schema alone doesn't convey.

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?

Specific verb-resource combination ('place an automated phone call to deliver a spoken message or play audio') clearly defines the scope. Distinguishes from siblings like send_email, send_sms, and ai_call by emphasizing physical phone delivery and offline reach.

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 ('notifying a human, delivering alerts, or reaching someone who isn't online') and provides clear prerequisite workflow ('Requires create_payment with toolName='place_call''). Lacks explicit naming of alternatives (e.g., 'use send_sms instead for short digital alerts').

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a polling operation with a recommended interval, returns incremental data based on a cursor, and includes a cost note ('No additional payment'). However, it doesn't detail error handling or rate limits, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by usage instructions and behavioral notes in three concise sentences. Each sentence adds essential information (e.g., polling loop, cost implication) without redundancy, making it highly efficient and well-structured.

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 (polling with state management) and no output schema, the description is largely complete: it covers purpose, usage, behavior, and parameters. However, it lacks details on output structure (e.g., format of transcripts/events) and error cases, which could aid the agent in handling responses.

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 both parameters ('cursor' and 'sessionId'). The description adds minimal value beyond the schema by implying the cursor's role in fetching 'since the last cursor,' but it doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Fetch new transcript events') and resource ('from an open Voice Bridge call'), distinguishing it from siblings like 'open_voice_bridge' (which initiates) and 'end_voice_bridge' (which terminates). It specifies the scope ('since the last cursor') and return types ('partial + final transcripts + system events'), making the 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 explicitly provides usage guidance: it instructs the agent to 'poll in a loop (~500ms-1s)' for ongoing updates, and it references a prerequisite ('sessionId from open_voice_bridge'), indicating when to use this tool (after opening a call). It also distinguishes from non-polling tools by emphasizing incremental fetching.

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

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

With no annotations, the description carries full burden and excels: it discloses the 24-hour window, caller ID matching, email delivery, optional OCR with cost, callback webhook, no-refund policy, partial refund on OCR failure, and payment method. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise and front-loaded with the primary purpose. Every sentence adds value, though it is a single dense paragraph that could benefit from slight restructuring. No wasted words.

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

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

Given no output schema, the description fully explains the delivery process (email, optional OCR file, webhook) and key policies (refund, failure handling). It is complete for a fax reception tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value beyond the schema: e.g., 'matched by caller ID (last 10 digits)' for fromNumber, 'returns a searchable text file' for OCR, 'HMAC-signed webhook' for callback_url. It also explains refund policies related to parameters.

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: opening a 24-hour receive window at a shared number to receive a fax. The verb 'receive' and resource 'fax' are explicit, and it naturally distinguishes from its sibling 'send_fax'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'When you're expecting a fax back — bank confirmation, court filing, signed document'. It does not explicitly state when not to use or list alternatives, 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?

With no annotations provided, the description carries full behavioral disclosure burden and excels: covers cost (5 sats), payment mechanism (Bitcoin Lightning), auth model (no API key), output format (transparent PNG), model evolution (automatic SOTA upgrades), and prerequisite workflow. No contradictions with 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?

Six sentences each serving distinct purposes: core function, technical validation, capability scope, operational stability, pricing/auth, and invocation prerequisite. Front-loaded with the essential 'what it does', zero redundancy despite information density.

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 payment workflow complexity and lack of output schema/annotations, the description provides complete invocation context: input expectations, cost, authentication method, prerequisite steps, and return format. No critical gaps remain for an agent to successfully invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (paymentId and imageBase64 fully described), establishing baseline 3. The description adds crucial workflow semantics explaining that paymentId must be obtained via create_payment with specific toolName parameter, which elaborates on the prerequisite relationship beyond the schema's standalone 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?

Opens with specific verb-resource-result trio ('Remove background from any image, returning transparent PNG') and distinguishes from siblings via technical specifics (BiRefNet model, transparent PNG output) that contrast with generic 'edit_image' or object-focused 'remove_object'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite invocation pattern ('Requires create_payment with toolName='remove_background''), which is critical for successful use. While it doesn't explicitly contrast with 'remove_object' or 'edit_image', the detailed capability list (hair, fur, glass handling) effectively signals when to select this specific tool.

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

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

With no annotations provided, the description carries full behavioral disclosure burden effectively. It reveals cost (15 sats), payment method (Bitcoin Lightning), authentication model (no API key), technical implementation (Grounding DINO + Bria Eraser), and inpainting behavior ('filled convincingly').

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 efficiently structured sentences: (1) core capability and differentiator, (2) technical implementation and examples, (3) pricing and prerequisites. Zero redundancy; every clause adds distinct 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?

Comprehensive for a payment-integrated tool, covering functionality, cost, and prerequisites. Minor gap: no mention of return value format (edited image data), though this is somewhat inferable. Strong coverage of the unique payment workflow compensates.

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?

Despite 100% schema coverage, the description adds valuable context: concrete query examples ('person', 'car', 'watermark') illustrate the query parameter, and the payment workflow explanation contextualizes the paymentId requirement beyond the schema's 'Valid payment ID' text.

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

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

The description uses specific verb 'Remove' with clear resource 'objects from images' and distinguishes from siblings like remove_background (background vs objects) and detect_objects (detection vs removal). The phrase 'by describing what to remove' clarifies the interaction model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite workflow 'Requires create_payment with toolName=remove_object' and clarifies 'no mask needed' (differentiating from mask-based alternatives). Lacks explicit 'when-not-to-use' or sibling comparisons, but the payment requirement provides clear usage boundaries.

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 explains that the tool sends an email to the operator, opens a ticket, and detects existing LNURL refunds to avoid duplicates. This covers key behavioral traits but could mention the return value or confirmation step.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two paragraphs. The first sentence is a strong purpose statement, followed by guidance on non-usage and a note on duplicate handling. No extraneous information.

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

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

Given the tool's complexity (4 params, no output schema), the description is fairly complete. It covers when to use, when not, and edge cases. However, it doesn't specify what the tool returns (e.g., a ticket ID or confirmation), which might be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the description adds little extra parameter meaning. It does clarify that 'invoice' can be a Lightning address or bolt11 invoice, which is already in the schema. The baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: opening a manual 48-hour refund review ticket for failed services. It specifies the conditions (error, timeout, wrong output) and distinguishes itself from automatic refunds for metered services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when-to-use (failed services) and when-not-to-use (unused-minute refunds on metered services, which are automatic). Also explains the fallback behavior for duplicate calls on metered payments, giving clear guidance on 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 provided, the description carries full disclosure burden and succeeds in documenting cost ('5 sats per image'), payment mechanism ('Bitcoin Lightning'), model behavior ('upgrades automatically as SOTA evolves'), and the fidelity trade-off concept. It misses only output format details and rate limiting 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?

Information-dense but well-structured, progressing from function to technical specs to cost/prerequisites. The CodeFormer citation is specific enough to establish capability without excess. Only the payment details sentence is slightly packed with multiple facts.

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 lack of output schema, the description should ideally specify the return format (base64 image, URL, etc.) and whether the operation is synchronous. The input side is thoroughly covered, but the output side remains ambiguous despite the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema coverage is 100% (baseline 3), the description adds valuable semantic context for the fidelity parameter ('balance between quality enhancement and identity preservation') and explicitly links the payment workflow to the paymentId parameter requirement, elevating it above pure schema repetition.

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 combo ('Restore... faces') and clearly scopes the input types ('blurry, damaged, or AI-generated'). It distinguishes itself from sibling tools like upscale_image or deblur_image by specifying face-specific restoration using CodeFormer technology.

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 workflow guidance by stating the prerequisite 'Requires create_payment with toolName=restore_face' and explains the authentication model ('no API key or signup needed'). However, it lacks explicit comparison to siblings like upscale_image or deblur_image regarding when to choose face restoration versus general image enhancement.

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, but description carries substantial weight: discloses cost ('200 sats'), payment method ('Bitcoin Lightning'), auth model ('no API key or signup needed'), format constraints ('Plain text', char limits), and infrastructure requirements ('No SMTP server'). Minor gaps on rate limits or retry behavior.

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?

Six information-dense sentences with zero filler. Front-loaded with purpose and use cases, followed by constraints, pricing, and dependencies. Efficient telegraphic style ('200 sats.') appropriate for the domain.

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?

Excellent coverage of payment workflow and format constraints for a tool with no output schema. Missing explicit description of return value (likely job ID given check_job_status sibling), but prerequisite documentation provides sufficient workflow context.

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% (baseline 3). Description adds critical workflow context for paymentId ('Requires create_payment', cost amount) and intent for 'to' ('Reach anyone'). Repeats char limits already in schema but compensates with payment 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?

Specific verb ('Reach') and resource ('email address') with clear scope. Use cases ('formal communication, sending reports, or contacting someone outside chat') distinguish it from chat/SMS siblings (send_sms, place_call).

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 ('formal communication', 'contacting someone outside chat') and prerequisites ('Requires create_payment with toolName='send_email''). Lacks explicit 'when not to use' vs SMS/voice 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 exist, so description bears full responsibility. It discloses two operating modes, pricing formula, maximum pages (350) and size (50 MB), payment flow via Bitcoin Lightning, and cover page behavior. However, it does not mention retry policies, error handling, or delivery timelines.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: opens with use-case motivation, then explains modes, pricing, limits, and payment integration. Every sentence serves a purpose, with 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?

Despite no output schema and no annotations, the description covers necessary usage context, parameter details, pricing, and inter-tool dependencies (create_payment). It is fully sufficient for an 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%, and the description adds value beyond schema descriptions. It explains mode differences, the relationship between 'pages' and create_payment, and that coverText is mode=pdf only and adds a page. This contextual enrichment helps correct parameter selection.

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 sends faxes worldwide with two modes ('pdf' and 'text'), clearly distinguishing it from siblings like send_email or send_sms. Specific use cases ('loan paperwork', 'signed contract', 'booking confirmation') reinforce purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance with concrete examples and contextual signals (paper-trail requirement). Pricing, limits, and integration with create_payment are explained, but no explicit when-not-to-use scenarios are given.

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 fully carries the burden. It discloses that messages are delivered in seconds, no phone plan needed, pay with Bitcoin Lightning, no API key, and constraints like max 126 chars with auto-appended disclaimer. This is good coverage for a send 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?

The description is two sentences plus a prerequisite note. It is largely concise but could be slightly streamlined without losing information.

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

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

Given no output schema or annotations, the description covers purpose, prerequisites, payment flow, and constraints adequately. It is complete for a simple send SMS tool, though it could mention expected response or error 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% with descriptions for each parameter. The description adds context beyond the schema by noting the payment prerequisite and character limit, enhancing understanding of parameter constraints.

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 specific verbs ('Reach a human via SMS') and identifies the resource ('SMS'). It clearly distinguishes from siblings like send_email and send_fax by focusing on real-world coordination and unique prerequisites.

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 states the tool is for real-world coordination and mentions the prerequisite of using create_payment with matching parameters. It implies when to use but does not explicitly exclude use cases or mention 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 provided, the description fully bears the burden. It details behavioral traits: three tiers with character-per-second rates, adjustable speed (0.5-2.0x), return of an audio URL, Bitcoin Lightning payment, and the need for a paid payment ID. It also covers language support breadth and voice cloning capabilities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy due to inline voice and language lists, but it is well-structured: overview in first paragraph, usage guidance in second, payment details in third. Every sentence adds value, though the inline lists could be referenced as just 'see parameter schema' for brevity. Still, the structure aids readability.

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 (7 parameters, no output schema, no annotations), the description covers all essential aspects: tier selection, language coverage, voice options, speed control, payment prerequisite, and alternatives for phone calls. Missing details like exact return format (just 'audio URL') are acceptable for a TTS tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds immense value beyond the schema. It explains the three model tiers in detail, provides a full language catalog (646 languages with ISO codes and names), and lists all 467 voices with descriptions (gender, age, style). It also clarifies parameter relationships (e.g., voice_description only for OmniVoice, language enum scope).

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

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

The description clearly states that the tool converts text to speech, outlines three distinct tiers (OmniVoice, Inworld Premium, Minimax Studio) with specific capabilities, and distinguishes itself from sibling tools by explicitly stating when not to use it (for phone calls).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each tier (e.g., OmniVoice for rare languages, Inworld for highest quality) and when not to use the tool (for phone calls, directing to specific sibling tools like place_call, ai_call, open_voice_bridge). It also mentions the payment requirement via create_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, the description fully discloses async polling, ephemeral data, payment requirement, and file limits. It adds context beyond basic functionality, though it does not cover failure scenarios.

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 that front-loads the main purpose and efficiently covers key details. It is concise but could benefit from structured bullet points.

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

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

The description covers purpose, usage steps, payment, privacy, and limitations. It lacks output format details but is sufficient for a tool without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with basic descriptions. The tool description adds value by explaining the payment flow, language list, and file constraints, complementing the schema.

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

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

The description clearly states the tool transcribes audio to text with timestamps, using Mistral Transcription. It implies a distinction from sibling transcribe_translate by focusing on transcription without 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?

The description outlines the workflow (create payment, call, poll, get result) and limitations (60 min, 500 MB, 13 languages). However, it does not explicitly state when to use this tool versus alternatives like transcribe_translate, nor when not to use it.

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 description carries full burden. It discloses async behavior, auto-detection of source language, flat pricing, and payment flow. Minor gap: doesn't mention maximum file size or timeouts.

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 but packs many details. Could be slightly more structured with line breaks, but overall efficient and informative.

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 or annotations, description explains most key aspects: purpose, workflow, pricing, and payment. Missing some edge-case behaviors (e.g., failure modes) but 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 coverage is 100%, but description adds value by explaining auto-detection for sourceLanguage and providing example language formats for targetLanguage. Could further clarify audioBase64 format constraints.

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's a compound endpoint that produces both transcript and translation from audio, distinguishing it clearly from siblings like transcribe_audio and translate_text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit example use cases (WhatsApp voice messages, meeting recordings), compares pricing favorably to separate calls, and explains async workflow (poll with check_job_status). Also notes Bitcoin Lightning payment requires create_payment first.

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 bears full responsibility. It discloses the model (Qwen3-32B), auto-detection of source language, privacy policy ('no data stored'), pricing (1 sat per 1,000 characters, minimum 1 sat), and required payment workflow. It does not mention latency, rate limits, or maximum text length, but the disclosed details are comprehensive for a translation 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 description is a single coherent paragraph that front-loads key information: purpose, model, auto-detect, privacy, pricing, language format, then lists all 119 languages, and ends with payment prerequisite. While the language list is lengthy, it is necessary for completeness. The structure is logical and efficient.

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

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

The tool has no output schema, so the description should explain what the translation result looks like. It does not mention the return format (e.g., object with translated text, language detection, etc.). It also lacks error handling or limitations (e.g., maximum text length). Given the complexity (5 params, payment workflow), the description covers most functional aspects but misses output description.

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% (all 5 parameters documented in schema), so baseline is 3. The description adds value by explaining that language parameters accept both English names and ISO-639 codes/locale tags, and clarifies that sourceLanguage is optional (auto-detect). This goes beyond the schema's enum lists and 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 high accuracy,' specifying the verb ('Translate') and resource ('text') with a specific scope (119 languages). It distinguishes itself from sibling tools like 'transcribe_translate' (audio transcription+translation) and 'generate_text' (text generation) by focusing solely on text 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?

The description provides clear context: it mentions the prerequisite of creating a payment via 'create_payment' with specific parameters, and implies usage when translation is needed. However, it does not explicitly state when NOT to use this tool or compare it with alternatives like 'transcribe_translate' or 'generate_text', leaving some ambiguity for the agent.

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, yet description carries full burden excellently. Discloses model identity (Real-ESRGAN), performance metrics (PSNR 32.73dB), upgrade policy ('model upgrades automatically'), pricing ('5 sats per image'), payment method (Bitcoin Lightning), and authentication model ('no API key').

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?

Efficiently structured: core function (sentence 1), technical credibility (sentence 2), quality differentiation (sentence 3), features (sentence 4), reliability (sentence 5), pricing/auth (sentence 6), prerequisites (sentence 7). Zero redundancy; every sentence adds distinct 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?

Comprehensive for a paid image processing tool without output schema. Covers input format (Base64), cost, prerequisites, and optional features. Minor gap: does not specify return format (Base64 image? URL?), though this is somewhat mitigated by the 'Stable endpoint' reliability claim.

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 coverage, baseline is 3. Description adds value by contextualizing paymentId within the create_payment workflow requirement, reinforcing scale enum values (2x/4x), and clarifying face_enhance as 'Optional face enhancement' rather than just a boolean flag.

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?

Opens with specific verb-resource combination ('Upscale images 2x or 4x') and technical method ('neural super-resolution'). The 'not interpolation' phrase distinguishes from basic resizing tools, while 'Real-ESRGAN' and scale factors clearly differentiate from sibling enhancement tools like deblur_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?

Explicitly states the prerequisite workflow ('Requires create_payment with toolName='upscale_image''), which is critical for invocation. Defines input suitability ('low-resolution images'). Lacks explicit comparison to siblings like deblur_image, though technical specs implicitly guide selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic STT muting during injection, no additional payment (covered by session deposit), MVP limitations on audio formats, and the two operational modes. It doesn't mention error handling, rate limits, or authentication requirements.

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 efficiently structured with zero wasted sentences. It front-loads the core purpose, then explains the two modes, behavioral details, and cost implications in a logical flow. Every sentence adds essential information.

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

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

For a tool with 6 parameters, no annotations, and no output schema, the description provides good contextual completeness. It covers the tool's purpose, operational modes, behavioral constraints, and cost implications. The main gap is lack of information about return values or error responses, which would be helpful 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?

With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds some context about the two modes mapping to parameters, but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Inject audio into an open Voice Bridge call' with two specific modes (text-to-speech and pre-rendered audio). It distinguishes itself from sibling tools like 'text_to_speech' by focusing on injection into an active call rather than standalone TTS generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: during an open Voice Bridge call. It explains the two modes and their requirements, but doesn't explicitly state when NOT to use it or compare it to alternatives like 'text_to_speech' or 'place_call' for different scenarios.

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?

Without annotations, the description fully discloses behavioral traits: costs 1 sat per vote, multiple votes allowed, requires payment, returns success slug newVoteCount, and mentions prioritization of highest-voted services. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, each serving a purpose: primary action, return format/cost, prerequisite and incentive. No wasted words.

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

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

Given the tool has 2 parameters, no output schema, and moderate complexity, the description covers return values, payment requirement, discovery prerequisite, and voting logic. It is complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover both parameters completely. The description adds valuable context: slug is from list_planned_services, paymentId is a valid paid 1-sat payment. This adds meaning beyond schema but is not exhaustive.

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 'Vote for a planned service to be built next' with a specific verb and resource. It also describes the return value and distinguishes from its sibling tool list_planned_services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to call list_planned_services first to discover valid slugs, states the cost (1 sat per vote), allows multiple votes, and requires create_payment with toolName='vote_on_service'. This provides clear when/to-use and prerequisites.

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