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

No annotations exist, so the description fully discloses behavior: async polling via check_job_status, auto-retry on voicemail (up to 3), state='pending_confirm' requiring confirm_ai_call, cost range (~150-250 sats), languages, and payment method (Bitcoin Lightning). This is comprehensive.

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

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

The description is lengthy (multiple paragraphs) but front-loaded with key purpose and usage. Every sentence adds value, making it more informative than verbose. However, it could be slightly more concise without losing detail. Still, it is 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 no output schema and complexity (6 params, async, state machine, payment prerequisite), the description fully covers the workflow: async polling, required confirm_ai_call on pending_confirm, cost, languages, and exclusions. It leaves no critical 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%, baseline 3. The description adds value beyond schema for the 'language' parameter (explains guessing logic and override cases) and 'task' (what constitutes instructions). The 'beginMessage' is also clarified. However, the schema already describes parameters well; the description provides incremental context.

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

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

The description clearly states the tool's purpose: 'send an AI voice agent to handle the call' for human-interaction tasks like booking, negotiating, and IVR navigation. It distinguishes from sibling tools (open_voice_bridge, place_call, send_sms) by specifying when NOT to use each alternative.

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

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

Explicitly provides when-to-use (human-required tasks) and when-not-to-use scenarios, naming specific sibling tools as alternatives (open_voice_bridge, place_call, send_sms). Also mentions prerequisite create_payment. This is exemplary guidance.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses payment requirement, model used, and capabilities, but does not detail failure modes, rate limits, or whether the operation is read-only (assumed from analysis). The cost and model information are valuable 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?

The description is relatively concise (four sentences) and front-loaded with the core purpose. However, the sentence 'Uses Qwen VL — multimodal vision-language model with strong OCR, chart reading, and spatial reasoning.' could be slightly more concise without losing meaning. Overall, it efficiently communicates key 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 has 4 parameters (3 required) and no output schema, the description covers essential aspects: purpose, prerequisites (payment flow), model details, and parameter notes. It provides sufficient context for an AI agent to decide when and how to invoke the tool correctly, including the mandatory payment step.

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 parameters have descriptions). The description adds value beyond the schema by explaining the payment requirement for 'paymentId', noting that 'modelId' is optional, and mentioning the model's capabilities (Qwen VL) which helps interpret the 'prompt' parameter. This enhances understanding beyond the 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?

The description explicitly states the tool's purpose: 'Analyze and describe image content, answer visual questions, extract information from screenshots or photos.' It also specifies the underlying model (Qwen VL) and its capabilities (OCR, chart reading, spatial reasoning), making it distinct from sibling tools like 'detect_objects' or 'generate_image'.

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

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

The description clearly states the prerequisite: 'Requires create_payment with toolName='analyze_image'.' It also mentions cost (21 sats) and that no API key is needed. However, it does not explicitly differentiate when to use this tool versus other image-related tools (e.g., 'detect_objects', 'generate_image'), relying on the purpose to imply appropriate contexts.

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 discloses key traits: async polling, cost per second, duration range, Bitcoin Lightning payment, no API key needed. Lacks details on failure modes or image constraints, but covers major 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?

Three sentences, each providing distinct value: purpose, async nature, cost, and payment. No redundant or vague statements; highly 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?

Covers purpose, inputs, prerequisites, async behavior, cost, and duration. Lacks output format details (no output schema) and potential error conditions, but sufficient for an async tool with polling.

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 already has 100% description coverage; the tool description adds value by explaining payment flow (create_payment with toolName) and duration range. This extra context aids the agent beyond the schema.

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

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

The description clearly states the tool converts a still image to video with text guidance, using a specific model. It distinguishes from siblings like generate_video by specifying 'animate a still image' and preserving source fidelity.

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: async behavior, prerequisite create_payment, and payment method. Does not explicitly list when not to use or alternatives, but the context is sufficient for typical usage.

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?

Describes response format with statuses, progress for epub-audiobook, and that it is free. No annotation provided, so description carries full burden. Missing auth or rate limit details, but overall transparent.

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

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

Well-structured with purpose first, then usage details. Slightly verbose but each paragraph 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?

Complete for a polling tool: covers all job types, next steps, progress details for specific case. No missing information 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?

Adds significant meaning beyond schema: explains requestId comes from async tools and gives mapping for jobType enum to tool names. Schema coverage is 100%, description enhances usability.

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 'Poll the status of an async job' with specific verb and resource. Lists which tools are async, distinguishing from synchronous siblings.

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

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

Explicitly tells when to use (after async tools returning requestId), polling interval (5-10 seconds), and what to do on completion (get_job_result) or failure (do not retry). Also advises against use for synchronous tools.

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 return JSON structure, expiry behavior, and that the tool is free and non-destructive. No annotations to contradict.

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

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

Four concise sentences with no redundancy; first sentence states the core purpose immediately.

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

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

Despite no output schema, description fully explains return format, lifecycle context (expiry, follow-up steps), and tool cost; complete for a simple check 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 already describes the parameter fully (the paymentId from create_payment). Description adds minimal extra meaning beyond the schema, so 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?

Clearly states the tool checks if an invoice is paid, specifies return format with three statuses, and distinguishes from siblings by noting it is called after 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?

Provides explicit instructions: call after create_payment, before target tool; mentions 10-minute expiry and action if expired; notes instant payment in most clients.

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 bears full burden. Discloses pricing, payment requirement, output type, and quality modes. Lacks details on file format constraints, duration limits, or error conditions, which would improve transparency.

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

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

Three focused sentences: purpose/output, quality modes, pricing/payment. Every sentence adds value, no fluff, front-loaded with most important information.

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

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

Covers main purpose, inputs, modes, payment requirement, and output type. No output schema, but description mentions voice_id. Missing file format and size constraints, but overall adequate for a tool with 4 parameters and 100% schema coverage.

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 4 parameters described). Description adds context: explains paymentId must be paid, voiceFileUrl must be public, and model enum meanings. Goes beyond schema by explaining the 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?

Clearly states 'Clone any voice from a single audio sample' and describes the output as a reusable voice_id for text-to-speech. Distinguishes from sibling tools like text_to_speech by explicitly linking the output.

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?

Specifies prerequisite: requires create_payment with toolName='clone_voice'. Mentions cost (7,500 sats) and payment method (Bitcoin Lightning). Provides context on model selection (Turbo vs HD) but does not explicitly state when not to use the tool.

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

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

No annotations provided, so description carries full burden. It discloses cost (5 sats), payment method (Bitcoin Lightning, no API key), and prerequisite step. Does not mention rate limits or time estimates, but otherwise transparent.

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

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

Four concise sentences with front-loaded purpose. No unnecessary words; every sentence adds value.

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

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

Given no annotations and no output schema, the description covers purpose, usage instructions, prerequisites, cost, and parameter details completely enough to use the tool.

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

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

Schema coverage is 100%, but description adds context: specifies that paymentId must be valid/paid, imageBase64 should be Base64-encoded grayscale/B&W image, and explains model_size enum and default.

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

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

The description explicitly states it colorizes black-and-white or grayscale photos, names the algorithm (DDColor), and highlights that it's impossible for text/vision LLMs, distinguishing it from siblings.

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

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

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

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

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

With no annotations, the description discloses that the tool reuses the original payment and returns a call_id for polling. However, it does not mention whether it is a read or write operation or what happens on failure, leaving some behavioral 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?

Three concise sentences cover action, prerequisite, payment implication, and return value with no wasted words. Each sentence serves a distinct 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?

The description explains the prerequisite, payment reuse, and return value for polling, which is sufficient given the tool's simplicity. It lacks details on error handling or alternative flows, but these are not critical.

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 minimal semantic value beyond the schema. It repeats the sessionId and answers descriptions but does not introduce new parameter details.

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

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

The description clearly states the tool confirms an AI call after reviewing push-back questions, specifying the resource (AI call) and verb (confirm). It distinguishes from sibling ai_call by indicating it is used when state='pending_confirm'.

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

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

The description provides explicit context for when to use (when ai_call returns pending_confirm) and notes that no new payment is needed. It also mentions polling with check_job_status, but does not explicitly state 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 are provided, so the description carries the full burden. It states the conversion engine preserves formatting and quality and returns a download URL, giving moderate behavioral context. However, it omits details like file size limits, processing time, or error behavior that could be important for an agent.

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 five sentences, front-loaded with the core purpose, and each sentence adds distinct information: supported formats, engine quality, output type, cost, and payment requirement. No redundancy or fluff.

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

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

Given 5 parameters, no output schema, and no annotations, the description provides a solid overall picture: purpose, payment flow, and output format. It lacks details on error handling and limits, but for a straightforward conversion tool with a well-known interface, it is largely 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% with all 5 parameters described. The description adds minimal parameter-level insight beyond the schema—it mentions paymentId requirement implicitly via '100 sats' but does not elaborate on fileUrl vs fileBase64 trade-offs. Baseline 3 is appropriate given high 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 converts files between 200+ formats, listing examples across document, image, audio, and video categories. It uses a specific verb-resource pair ('Convert files') and highlights the breadth of supported formats, but does not explicitly differentiate from sibling tools like convert_html_to_pdf.

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

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

The description explains the payment model (100 sats per request, Bitcoin Lightning, no account needed) and instructs the user to call create_payment with toolName='convert_file'. It does not provide explicit when-not-to-use guidance or contrast with alternatives, but the usage context is clear.

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

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

No annotations present, but description fully discloses return format (JSON with temporary URL, 1-hour validity), cost (50 sats), payment requirement (create_payment), and input support (HTML/CSS, base64 images). Transparent about all behavioral aspects.

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

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

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

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

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

Given no output schema, description fully explains return format. Covers all essential aspects: input, format, output, cost, prerequisites, and alternatives. Complete for a tool with simple parameters.

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

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

Although schema covers parameters 100%, description adds context: explains paymentId's origin, format options, and the purpose of html content. Also implies output structure beyond schema.

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

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

The description clearly states the tool converts HTML or Markdown to PDF, with specific use cases (invoices, reports) and distinguishes from sibling tool convert_file for existing file conversions.

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

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

Provides explicit when-to-use: generating documents, setting format='markdown' for Markdown. Also gives alternative: 'Use convert_file instead for converting existing files.'

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

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

No annotations provided, so description carries full burden. Discloses return JSON structure, invoice expiration (10 minutes), error behavior for missing required params, and pricing dependencies for each target tool. Completely transparent.

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

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

Well-structured with clear sections for purpose, return values, workflow, expiration, and per-tool requirements. Slightly long but all content is necessary; no filler.

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

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

Comprehensive coverage of all aspects: purpose, workflow, return values, expiration, error handling, and detailed conditional parameter requirements for each tool. No gaps given the complexity of 12 parameters and multiple dependent tools.

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 already has 100% description coverage for all 12 parameters. The description adds significant value by explaining why parameters are required (pricing formulas) and giving specific pricing rules per tool (e.g., generate_text price per char, generate_video modes with costs).

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 creates a Lightning invoice for one AI service call. Immediately distinguishes from sibling tools like get_cost_estimate and check_payment_status.

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 describes the typical workflow (list_models → create_payment → check_payment_status → call tool) and advises to call once per operation. Also details when extra parameters are required based on the tool being paid for.

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. It discloses cost (20 sats), processing time (~2 min), payment method (Bitcoin Lightning), and prerequisite (create_payment). Does not mention file size limits or invalid image handling, but overall thorough.

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 (3-4 sentences), front-loaded with the main purpose, and each sentence provides necessary context without redundancy. Highly 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 3 parameters, no output schema, and a payment workflow, the description covers the core usage, cost, timing, and dependency on create_payment. Missing output format details, but acceptable for a processing tool with no structured output.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining paymentId must be paid, specifying task_type defaults ('Image Debluring (GoPro)'), and clarifying the three options. This goes beyond the schema's enum 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 recovers detail from camera-shake and accidental motion blur, names the model (NAFNet), and lists both effective and ineffective scenarios, distinguishing it from sibling tools like 'upscale_image' or 'edit_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 when to use (handheld shake, bumped camera, whole-frame uniform blur) and when not to use (intentional panning, bokeh, artistic motion). Also mentions support for denoising and payment requirements, providing clear alternatives and prerequisites.

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

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

No annotations, so description must cover behavior. It discloses cost (2 sats), payment flow, faster/cheaper than LLM, and returns label and boolean. Does not mention rate limits or destructive effects, but nothing contradictory.

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

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

Concise paragraph front-loads core function, then adds pricing and payment details. No redundant sentences; every sentence adds value.

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

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

With no output schema, description explains return values. Covers use case, pricing, payment flow, and image format. Complete for a simple two-param tool.

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

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

Schema coverage is 100% with descriptions for both params. Description adds context: paymentId must be valid/paid, imageBase64 can be data URI or formats. Reinforces workflow requirement, adding marginal value beyond schema.

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

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

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

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

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

Explicitly states use for content moderation pipelines and is cheaper/faster than LLM. Mentions payment requirement via create_payment. Lacks explicit when-not-to-use or alternative tools, but context is provided.

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

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

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

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

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

The description is concise and front-loaded with the core purpose. Each sentence adds value, though the payment instruction could be slightly more integrated. No wasted words.

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

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

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

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds natural language context for the query parameter but does not elaborate on box_threshold or text_threshold beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool detects and locates objects by name, using Grounding DINO, and provides structured output (bounding boxes, confidence scores). This distinguishes it from sibling tools like 'analyze_image' or 'generate_image'.

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

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

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

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

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

No annotations provided; description covers model used, return format (JSON with image URL), and pricing. Missing details on error handling, input constraints, or reversibility.

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

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

Concise with essential information upfront, but could be more structured (e.g., separate sections for usage, pricing, parameters).

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?

Explains payment flow and resolution options, but lacks details on input image constraints, failure modes, and output schema. Adequate for a paid API tool with complex parameters.

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

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

Schema coverage is 100%; description adds context about payment requirement and pricing beyond schema, but other parameters like prompt and imageBase64 are already adequately described in 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 'Edit an image with natural language instructions' and lists specific capabilities (object addition/removal, style transfer, inpainting), distinguishing it from siblings like generate_image or 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?

Provides payment flow instructions and resolution-tiered pricing, but does not explicitly specify when to use this tool vs. alternatives like remove_object or colorize_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, so description carries full burden. It discloses side effects: finalizes billing, returns refund link for unused deposit, and returns final transcript. Good disclosure beyond basic action.

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

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

Two sentences, front-loaded with the main action, no unnecessary words. All information is essential.

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

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

With one parameter and no output schema, the description adequately covers all needed information: what the tool does and what it returns.

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

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

Schema coverage is 100% with a clear description for sessionId. Tool description adds no further detail beyond what the schema already provides.

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

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

The description clearly states the verb 'Hang up', the resource 'Voice Bridge call', and additional actions like finalizing billing and returning refund link and transcript. It effectively distinguishes from siblings like 'open_voice_bridge'.

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

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

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

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

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

With no annotations, the description covers behavioral traits: async polling, payment via Bitcoin Lightning, voice tier options with rates, and translation cost. It also specifies the need for a prior create_payment call. Minor omissions: no mention of error handling or failure modes beyond polling.

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, packing essential information into a few sentences. It front-loads the primary purpose and then elaborates on key details. Could be slightly tighter but remains 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 and lack of output schema, the description provides sufficient context for an agent to understand the workflow: asynchronous execution, polling, payment integration, and voice tier trade-offs. It does not cover all edge cases but is adequate for correct invocation.

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

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

Schema coverage is 100%, so parameters are well-documented in the schema. The description adds value by explaining voice tiers and payment integration but does not provide substantial new semantics for individual parameters beyond the schema.

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

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

The description clearly states the tool converts books (EPUB/PDF/TXT) into full audiobooks with features like chapter detection, multi-voice narration, and translation. It distinguishes itself from sibling tools like text_to_speech by offering a comprehensive conversion pipeline.

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 for creating audiobooks from text files and mentions payment requirements, but it does not explicitly state when to use this tool versus alternatives (e.g., text_to_speech) or provide constraints (e.g., file size limits).

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

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

No annotations provided. Description discloses cost (10 sats/page) and payment flow, but lacks details on size limits, supported languages, error handling, or whether operation is destructive. Adequate but not exhaustive.

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

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

Four sentences, front-loaded with purpose, then capabilities, cost, and prerequisite. No redundant information.

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

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

Covers key aspects: purpose, capabilities, cost, payment prerequisite. Lacks output format detail (though Markdown is mentioned) and error handling. No output schema to compensate, but overall sufficient for typical use.

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

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

Schema covers 100% of parameters with descriptions. Description adds value by explaining the paymentId must be obtained via create_payment and that documentBase64 is base64 encoded, beyond schema details.

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

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

The description clearly states it extracts text from PDFs and images as clean Markdown, specifying handling of complex layouts, tables, handwriting, etc. This distinguishes it from siblings like analyze_image or convert_file.

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

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

Explicitly mentions prerequisite payment via create_payment with toolName and quantity, and that no API key is needed. Does not compare to alternatives like convert_file for document extraction, but the context is clear.

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

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

No annotations are provided, so the description carries full burden. It discloses the dual-model pipeline (Mistral OCR + Kimi K2.5), capabilities (crumpled, faded, multi-page), pricing model, payment flow (requires create_payment), and authentication method (Bitcoin Lightning, no API key). This provides comprehensive behavioral insight.

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

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

The description is somewhat lengthy but each sentence adds value. It is well-structured with clear information about purpose, process, and requirements. A slight reduction in wordiness could improve conciseness without losing essential detail.

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

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

Given there is no output schema, the description explains the return format (JSON with merchant, date, line items, etc.) and the overall pipeline. It covers cost, payment method, and limitations. For a 2-parameter tool, this is highly complete and leaves minimal ambiguity.

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

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

Schema coverage is 100% with both parameters described. The description adds meaningful context: paymentId must be a valid paid payment from create_payment with toolName='extract_receipt', and documentBase64 is a base64-encoded image or PDF. This goes beyond the 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?

The description clearly states 'Extract structured data from receipts, invoices, and financial documents' and lists specific output fields (merchant, date, line items, etc.). It distinguishes itself from siblings like 'extract_document' by focusing on financial documents and mentioning the dual-model pipeline.

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 usage context: handles crumpled receipts, faded text, and multi-page invoices. It also explains pricing (50 sats/page) and payment requirements. However, it does not explicitly tell when not to use this tool or compare with similar tools like 'extract_document'.

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 key behaviors: async operation (returns requestId), cost per model, payment requirement with Bitcoin Lightning (no API key needed), and the use of Seed3D technology. It does not cover error handling or rate limits, but the main behavioral traits are well specified.

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 (4 sentences) and front-loaded with the main action. Every sentence adds distinct information: purpose, technology, async nature, cost, payment method, and prerequisite. No wasted words, efficient and clear.

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

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

Given the tool's complexity (3 params, async, payment flow) and no output schema, the description covers the primary use case, async polling, cost, and payment prerequisite. It sets expectations for output (GLB model, requestId) but omits error handling details. Overall, it is sufficiently complete 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?

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema: it clarifies that paymentId must be a paid valid ID (referencing create_payment), that imageBase64 should be a single photo in valid formats, and that modelId can be omitted for default. This enriches parameter 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: 'Convert a single photo into a textured 3D GLB model.' It uses a specific verb (convert) and resource (photo to 3D model), and distinguishes from siblings by noting async behavior, cost, and payment requirement, which are unique among sibling 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 provides explicit context: when to use (to generate a 3D model from a photo), async nature (poll with check_job_status), cost (350 sats), and payment method (requires create_payment). It does not explicitly state when not to use or list alternatives, but given no similar sibling tools, the guidance is clear and actionable.

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

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

No annotations are provided, so the description carries full burden. It discloses return format (JSON with URL), model upgrade policy, payment mechanism, and img2img capability. Lacks error handling or rate limit info, but is reasonably transparent.

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

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

The description is compact with four sentences, each providing essential information without redundancy. The main action is front-loaded, and model details are efficiently listed.

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 4 params, no output schema, and no annotations, the description covers key aspects: models, costs, payment, img2img, and automatic upgrades. It could mention expected output structure or error cases, but is largely 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 meaning: it explains modelId choices (Grok, Seedream, Nano Banana with costs) and clarifies that imageBase64 enables img2img. It also notes that paymentId must be paid, which is not in the schema 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 begins with 'Generate an image from a text prompt,' clearly stating the verb (generate) and resource (image). It distinguishes from sibling tools like animate_image and upscale_image by specifying the output format and model options.

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: lists models with costs, mentions img2img, and explains payment requirement with explicit reference to create_payment. However, it does not explicitly state when to prefer this tool over siblings like generate_video or 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?

No annotations exist, but the description discloses key behaviors: uses Music-2.6 model, returns MP3 URL, costs 300 sats, requires prepaid payment via Bitcoin Lightning. It does not mention error handling or rate limits, but covers essential 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?

Four sentences front-load the purpose and key features, then cover pricing and payment flow. No wasted words; efficient 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?

The description covers purpose, model, output format, prerequisites, and cost. Missing error handling or async details, but for a direct generation tool with 9 parameters and no output schema, it is fairly 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% with good descriptions. The description paraphrases some parameters (e.g., 'Specify BPM, key, genre, mood in prompt') but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool generates full songs with natural AI vocals, BPM/key control, and section tags. It distinguishes from sibling tools like text_to_speech by specifying song generation with vocal and arrangement capabilities.

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 tells when to use (specify BPM, key, genre, mood) and requires a payment step, but does not compare to alternatives or state when not to use the tool. Usage context is implied, not explicit.

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. Discloses per-character pricing, model details, automatic upgrades, file/vision support, and payment requirements. Lacks failure modes or rate limits but is otherwise thorough.

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

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

Front-loaded with purpose and key details; packed with info but slightly long. Could benefit from more structured formatting (e.g., bullet points) but remains clear 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 8 parameters, no output schema, and moderate complexity, description covers core usage, model options, prerequisites (payment), and special features like vision. Lacks output format info but sufficient for agent invocation.

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

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

Schema coverage is 100% so baseline is 3. Description adds context: explains model selection (default best), fileContext/imageBase64 usage for Q&A/vision, and paymentId role. Enhances schema 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?

Specifically states 'Generate text using frontier AI language models' and lists distinct models with capabilities (document Q&A, vision), clearly differentiating from siblings like generate_image or transcribe_audio.

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

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

Explicitly requires create_payment with toolName='generate_text' and exact prompt, and mentions no API key needed. Provides clear usage context but doesn't explicitly exclude scenarios or compare with siblings beyond listing features.

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 effectively conveys key behavioral traits: async execution (returns requestId, poll with check_job_status), pricing per second, duration constraints, and dependency on payment. It does not cover error handling or full output format, but adds substantial value beyond the schema.

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

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

The description is a single, dense paragraph that front-loads the core function. It covers purpose, features, async, pricing, and dependencies in about 5 sentences with no redundancy. Could benefit from bullet points for readability, but remains concise.

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 params, async, no output schema), the description covers input constraints, pricing, and async polling. However, it does not describe the output format or error codes, leaving an incomplete picture. The polling hint partially mitigates, but a full output description is needed.

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, so baseline is 3. The description enhances parameter semantics by explaining pricing implications of duration and mode, and noting that modelId is optional with a default. It also clarifies the payment flow via create_payment.

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

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

The description clearly states 'Generate a video from a text prompt', specifies the model (Kling v3), and mentions key features like quality modes, audio, and async nature. It distinguishes from sibling tools like generate_image or animate_image by focusing on video generation from 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?

The description provides clear context: when to use (for generating videos from text), payment prerequisites (requires create_payment), and polling (check_job_status). However, it lacks explicit comparisons to alternatives or exclusions, leaving some ambiguity against similar tools like animate_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, so description carries full burden. It states 'No payment required, no side effects' and 'Returns { amount_sats, breakdown, currency },' fully disclosing behavior and return value.

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 serving a purpose: purpose, use case, examples, return value, and omitting behavior. No redundancy, fully front-loaded.

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 format, side-effect safety, and parameter usage patterns. For a query-only tool, this is complete.

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

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

Schema description coverage is 100%, but description adds value by explaining parameter combinations (e.g., 'chars for TTS and translate') and the 'omit to list all' pattern, going beyond the schema.

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

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

The description clearly states 'Get an exact sat cost quote for a service BEFORE creating a payment.' It specifies the verb, resource, and purpose, distinguishing it from sibling tools like create_payment.

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

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

The description explicitly says 'Useful for budget-aware agents to price-check before committing.' It provides concrete examples (e.g., 'Pass service=text-to-speech&chars=1500') and notes that omitting params lists all services. It lacks explicit when-not-to-use but is clear enough.

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

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

No annotations are provided, so the description carries the full burden. It discloses that no payment is needed and the return type (machine-readable catalog). However, it does not mention potential side effects, caching behavior, or performance implications. For a simple read-only tool, this is acceptable but not exhaustive.

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

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

The description is a single sentence that immediately states the purpose, followed by examples and usage guidance. Every word adds value, with no fluff.

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

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

Given the tool has no parameters and no output schema, the description is complete: it explains what the tool returns (a catalog of error codes with examples) and how to use the output (branch on error_code). No additional context is necessary.

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

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

The tool has zero parameters, and the schema coverage is 100% (by default, as no parameters exist). The description does not need to add parameter semantics, so baseline 4 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 retrieves a machine-readable catalog of all error codes the API can return, with specific examples (TIMEOUT, CONTENT_FILTERED, etc.). It distinguishes itself from any sibling by focusing solely on error code retrieval.

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

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

It advises agents to branch on error_code rather than parsing free-text messages, which is a clear usage directive. It also notes that no payment is required. However, it doesn't explicitly mention when not to use this tool or compare to 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?

Discloses error on non-completed jobs, URL expiry (~1 hour), free usage, and return shape per jobType. With no annotations, the description fully covers 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?

Concise (6 sentences), front-loaded with purpose, no redundancy. Every sentence adds unique value. 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?

Fully covers return types, error conditions, URL lifespan, and free status despite no output schema or annotations. 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 covers both parameters (100%). Description adds value by clarifying requestId's origin and mapping jobType to specific async tools, going beyond schema.

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

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

The description clearly states 'Retrieve the final output of a completed async job' and distinguishes from synchronous tools. It specifies the verb (retrieve), resource (final output), and precondition (job must be completed).

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

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

Explicit when to use: after check_job_status returns completed. States error if called early. Also excludes synchronous tools. Provides clear context for correct invocation.

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

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

With no annotations, the description carries full burden. It states it's a read operation and requires no payment, which is sufficient for a simple retrieval but lacks details like caching or authentication.

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, 11 words, front-loaded with purpose. Every word earns its place with no redundancy.

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

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

For a simple retrieval tool with one parameter and no output schema, the description is adequate. It does not explain return format but the context is clear.

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

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

Schema coverage is 100% and the schema already describes 'modelId'. The description adds no extra meaning beyond 'by ID', so 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 verb 'Get' and the resource 'pricing for a specific model by ID', distinguishing it from siblings like 'list_models' and 'get_cost_estimate'.

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 when pricing info is needed and notes 'No payment required', but provides no explicit when-to-use or alternative guidance.

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

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

No annotations are provided, so the description bears full responsibility. It clearly states the tool is free, requires no payment, and is idempotent—safe to call repeatedly. It also describes the output format. This fully informs the agent of 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?

The description is concise at 4 sentences, front-loads the purpose, and uses a clear example of the output format. Every sentence adds essential information with no wasted words.

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

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

Despite no output schema, the description provides a full example of the return format. It covers the purpose, usage, filtering, isDefault behavior, and safety aspects. Given the tool's simplicity (one optional parameter), the description is complete.

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

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

Schema coverage is 100% with the category parameter described. The description adds the context that filtering narrows results 'to a specific tool', which clarifies the enum values correspond to tool names, adding value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Discover available AI models with numeric IDs, tier labels, capabilities, and per-call pricing in sats.' It distinguishes from sibling tools like create_payment and get_model_pricing by specifying its role in selecting a modelId and noting it is free and idempotent.

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 advises calling this tool before create_payment to find the right modelId, and explains how the isDefault flag works. It also mentions filtering by category. While it doesn't explicitly compare to other tools like get_model_pricing, the guidance is clear and practical.

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 idempotence, safety, and no payment required. Also mentions sort order. No annotations provided, so description carries the full burden and does so adequately.

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 focused sentences, front-loaded with purpose, then output format, then guidance. No 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?

With no required params and no output schema, the description covers output format, usage guidance, safety, and idempotence fully. It is complete for a simple list 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?

No parameters exist, schema coverage is 100%. Description adds value by explaining output format and usage, which goes beyond the empty 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?

Explicitly states it lists planned services with vote counts, returns a JSON array with specific fields, and differentiates from sibling vote_on_service by indicating that the slug values can be used with that 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 clear usage guidance: no payment required, free discovery tool, and how to use results with vote_on_service. Lacks explicit when-not-to-use but is implied by the free nature.

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

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

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

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

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

Concise and well-structured: first sentence states purpose, each subsequent sentence adds critical details without redundancy. No fluff.

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

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

Given no output schema and no annotations, the description fully explains return format, temporary URL, pricing, and alternative tool, making it sufficient for correct invocation.

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

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

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

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

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

The description clearly states 'Merge multiple PDF files into a single document' with specific verb and resource. It distinguishes from the sibling 'convert_file' by mentioning format conversion as an alternative.

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

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

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

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

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

Discloses session lifecycle (speak, poll, end), refund mechanism, privacy policy (transcripts in memory, 30-min GC, no audio persistence), and payment method (Bitcoin Lightning). All critical behavioral traits covered despite no annotations.

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

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

Long but justified given complexity; front-loaded with purpose and usage, then details. Every sentence adds value, no waste. Could slightly condense, but effective.

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

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

Covers prerequisites, payment, refund, privacy, and interaction pattern. No output schema, but description sufficiently explains the tool's role in a multi-step process. Missing explicit return value, but minor.

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

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

Schema covers 100% of parameters, baseline 3. Description adds context for paymentId (from create_payment), phoneNumber format, durationMinutes as deposit, refundAddress for refund, and language/codec options, raising usefulness.

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 'Open a Voice Bridge session: a live phone call where YOUR LLM is the brain.' with specific verb (open) and resource, and distinguishes from siblings ai_call and 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 (privacy, drive turns), when not to use (managed calls, TTS broadcasts, low-value polling), and prerequisites (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?

No annotations provided, so description carries full burden. Mentions payment via Bitcoin Lightning and no account needed, but lacks details on failures, call duration behavior, or return status. Adequate but not thorough.

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

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

Three sentences: catchy intro, use case, prerequisite. No fluff, front-loaded with purpose. Excellent conciseness.

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 of return value (e.g., call ID, status). For a tool with payment and telephony, expected output is important for agent workflow.

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

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

Schema covers 100% of parameters with descriptions; description adds no new param details beyond restating message/audio choice. Baseline 3 justified.

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

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

Clearly states the action: place an automated phone call to deliver spoken message or play audio. Distinguishes from siblings like ai_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?

Provides explicit use cases (notifying humans, alerts, reaching offline) and prerequisite: requires create_payment. Does not explicitly state when not to use but gives 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?

No annotations provided, so description carries full burden. It mentions returns types (partial + final transcripts, system events) and payment, but lacks disclosure on side effects, idempotency, or safety (e.g., read-only nature). Adequate but not comprehensive.

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

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

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

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

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

Given no output schema, description explains return types but not structure details or error handling. Parameter count low, usage guidance provided. Lacks depth on potential empty returns or system events composition.

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

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

Schema coverage 100% with descriptions. Description adds default for cursor (0) and origin of sessionId. Text clarifies polling behavior and cursor usage, exceeding schema info.

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

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

Description specifies the verb 'Fetch', resource 'transcript events from an open Voice Bridge call', and scope 'since the last cursor'. It clearly distinguishes from sibling tools like voice_bridge_say and end_voice_bridge.

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

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

Explicitly says to poll in a loop at ~500ms-1s interval and notes no additional payment. Provides clear usage context but does not mention when not to use or contrast with alternatives.

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

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

With no annotations, the description fully explains behaviors: 24h window, caller ID matching, email delivery, optional OCR with cost and partial refund on failure, callback webhook, no refund if no fax arrives, and Bitcoin Lightning payment. No contradictions with schema.

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

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

The description is several sentences long but every sentence adds value, covering use case, mechanism, optional features, and policy. It is well-structured and informative, though could be slightly more concise.

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 an output schema, the description explains the outcome (fax delivered to email, optional OCR file, webhook) but does not specify the immediate return value of the tool (likely a job ID or status). It covers all key aspects for a receive 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?

All 6 parameters are described in the schema (100% coverage), and the description adds significant additional meaning: explains fromNumber matching, OCR cost and failure handling, callback_url for webhook, and paymentId prerequisite. This goes well beyond the schema 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 is for receiving faxes, using a specific shared number with a 24-hour window. It distinguishes itself from sibling tools like send_fax by focusing on inbound reception.

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

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

The description explicitly says when to use (expecting a fax back) and provides context like caller ID matching and email delivery. It does not explicitly exclude other use cases or recommend alternatives, but the scenario is clearly defined.

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 model (BiRefNet), capabilities (hair, fur, glass, complex edges), stability, automatic upgrades, cost, and payment method. No annotations provided, so description fully covers 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?

Description is fairly concise with 6 sentences, each adding value (purpose, model, handling, stability, cost, prerequisite). Slightly verbose but no fluff.

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

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

For a tool with 2 parameters and no output schema, the description covers input constraints, model details, output format (transparent PNG), cost, and prerequisite. Fully adequate for agent understanding.

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 both parameters are described adequately in the schema. The description adds no additional meaning to the parameters, so baseline score 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?

Clearly states the verb 'remove' and resource 'background from any image' with a specific outcome 'returning transparent PNG'. Distinct from siblings like 'remove_object' and 'edit_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 details the prerequisite payment process: 'Requires create_payment with toolName='remove_background''. Provides context like pay-per-request and no signup, but no explicit when-not-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?

No annotations provided, so description carries full burden. It discloses use of Grounding DINO and Bria Eraser, cost of 15 sats, pay-per-request with Bitcoin Lightning, no API key/signup needed, and requirement for create_payment. However, it doesn't mention image limitations or response 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 three sentences plus a payment instruction. It is concise but packs necessary details. Could be slightly tighter, but overall well-structured and front-loaded.

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?

Tool has 5 parameters but no output schema. The description does not mention what the tool returns (likely base64 image) or if there is a job ID. Error handling and rate limits are absent. Given the complexity, more detail on return value and potential errors would be beneficial.

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%. Description adds value by giving examples for 'query', stating default thresholds of 0.25, and explaining that paymentId must be paid. This supplements the schema 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 'Remove unwanted objects from images' with specific verb and resource. Examples like 'person', 'car', 'watermark' illustrate usage. It distinguishes from sibling tools like 'remove_background' by specifying text-based removal without masks.

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 when to use: 'just describe what to remove', and mentions no mask needed. It also explains pricing and payment flow. However, it does not explicitly state when not to use it (e.g., for complex edits) or compare with alternatives like 'edit_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 are provided, so the description carries the full burden. It discloses that the tool sends an email to the operator, has a 48-hour review period, and detects pending LNURL refunds to avoid duplicates, offering thorough behavioral context.

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

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

The description is concise and front-loaded with the main purpose in the first sentence. The remaining sentences add crucial usage guidelines and behavioral quirks without redundancy, but could be slightly more 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 no output schema and no annotations, the description provides comprehensive context: purpose, usage boundaries, alternative options, and unexpected behavior (duplicate detection). It fully equips the agent to use 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 description coverage is 100%, so the schema already documents all four parameters fully. The description does not add new parameter-level meaning beyond what the schema provides, thus baseline score 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 opens a manual 48-hour refund review ticket for failed services, specifying the action and resource. It distinguishes from metered service refunds, providing clarity on 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 states when to use (for failed services with error/timeout/wrong output) and when not to use (unused-minute refunds on metered services). Provides clear alternative: the LNURL withdraw link from the service's response, and explains duplicate detection behavior.

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

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

Without annotations, the description carries full burden. It discloses the underlying model (CodeFormer), adjustable fidelity, background enhancement, upsampling, stability, automatic upgrades, pricing, and payment process. This is comprehensive.

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

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

The description is eight sentences, all adding value. It front-loads the main purpose and efficiently covers multiple aspects without redundancy.

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

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

Given no output schema and no annotations, the description covers purpose, usage, pricing, and payment. It lacks details on return format or limitations (e.g., max image size) but is sufficient for a paid 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%, so baseline is 3. The description mentions fidelity and enhancements but does not add new parameter meaning beyond the schema.

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

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

The description specifies 'restore blurry, damaged, or AI-generated faces to sharp, natural quality,' using a clear verb and resource. It distinguishes from siblings like deblur_image and upscale_image by focusing on faces.

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

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

The description explains the payment requirement and fidelity adjustment. It implies use for face restoration but does not explicitly state when to avoid it or compare with alternatives. Sibling context is provided but not leveraged.

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

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

The description discloses plain text only, max lengths (10k body, 200 subject), cost (200 sats), payment method (Bitcoin Lightning), no SMTP/domain needed, and the prerequisite of create_payment. With no annotations, this provides good behavioral context.

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

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

The description is concise, front-loaded with purpose, then constraints, then payment details. Every sentence adds value without redundancy.

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

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

The description covers prerequisites, constraints, and use cases, but does not mention return values or error handling. No output schema exists, so more context on expected output or errors would improve 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 coverage is 100% with clear descriptions. The description adds context about the payment flow (requires create_payment with toolName='send_email') and reiterates limits, but does not significantly enhance parameter meaning beyond the schema.

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

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

The description clearly states that the tool sends an email ('Reach anyone with an email address') and specifies its use for formal communication, reports, and contacting people outside chat, distinguishing it from siblings which are mostly multimedia 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?

It explicitly mentions when to use this tool (formal communication, reports, contacting outside chat) and implies that it's for email, but does not exclude alternatives or explain when not to use it. Given no other email tool exists, this is adequate.

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: two modes, pricing (500 sats up to 10 pages, +50 per extra page), max limits (350 pages/50 MB), payment requirement via create_payment, and payment method (Bitcoin Lightning). It also clarifies no fax machine or phone line needed.

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 paragraph. It front-loads purpose and use cases, then logically covers modes, cover page, pricing, limits, and payment. Every sentence adds value with no redundancy.

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

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

Given 7 parameters, two modes, payment dependency, and no output schema, the description is complete. It covers when to use, how to use, pricing, limits, required parameters, and references the sibling create_payment tool for payment.

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 meaning beyond the schema: clarifies the two modes, optional cover page usage, that pdfUrl must be a public HTTPS URL, and that pages is used for pricing and must match create_payment's quantity.

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 sends a fax with two modes (pdf/text), optional cover page, and worldwide destination. It distinguishes from sibling tools like send_email and send_sms by emphasizing the need for a paper trail.

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 concrete examples of when to use (loan paperwork, signed contract, booking confirmation) and states it works worldwide. However, it does not explicitly state when not to use 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 bears full burden. It discloses delivery speed ('seconds'), no need for telecom accounts, payment via Bitcoin Lightning, and the auto-appended disclaimer. Missing details like error handling or delivery confirmation, but adequate for the tool's simplicity.

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 at several sentences, each adding unique information. It front-loads the primary purpose and flow, followed by constraints. No redundant or vague statements.

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 3 required parameters, no output schema, and no annotations, the description covers the workflow, prerequisites, and key constraints (matching values, disclaimer). It does not describe return values, but that is acceptable without an output schema. Overall, it sufficiently informs an AI agent for correct invocation.

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

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

Schema coverage is 100%, so each parameter has a description. The description adds value by clarifying that paymentId must be paid, phoneNumber/message must match create_payment, and the message length includes an appended disclaimer. This goes beyond the schema docstrings.

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 sends SMS messages for real-world coordination, distinguishing it from other communication tools like send_email or send_fax. The verb 'Reach a human via SMS' is specific and the resource is unambiguous.

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

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

The description provides clear context on when to use (real-world coordination) and prerequisites (create_payment with matching parameters). However, it does not explicitly state when not to use or name alternatives, though the sibling list implies the tool is specialized for SMS.

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 thoroughly discloses behavioral traits: three tiers with specific capabilities (chars/sat, language support), adjustable speed range, return type (audio URL), and payment process (Bitcoin Lightning, no API key). Covers all critical 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 extremely verbose, containing extensive lists of voices and languages that could be referenced via schemas or separate tool calls. While well-structured with paragraphs and headers, it sacrifices conciseness for completeness.

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 (7 parameters, no output schema), the description is complete: covers all tiers, parameter usage, payment, return value (audio URL), and provides exclusion criteria against sibling tools. A user can fully understand tool behavior without external references.

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 immense value beyond the 100% schema coverage by explaining the three tiers and how they relate to parameters, providing a massive enumerated list of voices with detailed descriptions (gender, age, style), and listing all 646 language ISO codes with full names. The description enriches parameter understanding significantly.

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

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

The description clearly states the tool converts text to speech with three distinct tiers, each described with unique features (language coverage, voice cloning, speed). It distinguishes from sibling tools like place_call and ai_call in the 'When NOT to use' section.

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 guidance on when to use each tier (e.g., OmniVoice for rare languages) and when not to use the tool, with references to alternative tools (place_call, ai_call, open_voice_bridge). Includes payment prerequisites.

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, payment flow, ephemeral data, language support, file size/duration limits, and privacy. This provides comprehensive behavioral insight.

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 reasonably concise and front-loaded with purpose. Every sentence adds value, though it could be slightly tighter 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 the complexity (async, payment, multiple languages, file limits), the description covers all essential aspects including how to retrieve results and privacy. No output schema exists, but the workflow is fully explained.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by linking paymentId to create_payment and listing supported languages, but does not elaborate on audio format requirements.

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

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

The description clearly states the tool transcribes audio to text with timestamps, using a specific verb and resource. It does not explicitly differentiate from sibling tools like 'transcribe_translate', but the purpose is unambiguous.

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

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

The description explains when to use the tool (transcription with timestamps) and includes context on async workflow and payment. However, it lacks explicit exclusions or alternatives, leaving the agent to infer 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 provided, but the description discloses async behavior (returns requestId, poll with check_job_status), flat pricing covering STT and translation, payment requirement, and source auto-detection. It could mention file size limits or supported audio formats, but overall transparency is high.

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

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

Front-loads key information (compound endpoint, use case). Some redundancy (e.g., 'Pay with Bitcoin Lightning — no API key or signup needed' could be shorter), but overall efficient 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?

No output schema, but description explains return type (requestId) and how to retrieve result (poll). Covers payment, async nature, source/target languages, and cost comparison. Missing details on output format (e.g., transcript structure) but given complexity, it's reasonably complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value: explains paymentId requires a paid payment, audioBase64 is base64-encoded, targetLanguage supports English name or ISO-639 (119 languages), sourceLanguage is optional with auto-detection and lists the 13 supported languages. This is meaningful enrichment.

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 is a compound endpoint that transcribes audio in 13 source languages and translates to 119 target languages. It distinguishes itself from siblings like transcribe_audio and translate_text by highlighting the combined offering and cost savings.

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 concrete examples (WhatsApp voice messages, meeting recordings), notes auto-detection of source language, async polling via check_job_status, cost comparison to alternatives, and prerequisites (create_payment). This gives explicit guidance on when and how to use.

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

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

Discloses model (Qwen3-32B), auto-detection of source language, privacy (no data stored), and pricing (1 sat per 1000 chars, min 1 sat). Without annotations, description carries full burden; these details are sufficient. Could mention if synchronous or result format, but still strong.

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

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

The description is front-loaded with purpose and key details, but it redundantly lists all 119 languages already present in schema enums. This makes it verbose. Overall structure is logical otherwise.

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 primary aspects: function, payment flow, parameters, supported languages, privacy, pricing. Missing output description and potential limitations (e.g., max text length). No output schema exists, so description should mention return format.

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: explains source language is optional (auto-detect), paymentId from create_payment, modelId optional. Also notes that language params accept English names or ISO codes, which is not in 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 'Translate text across 119 languages' with high accuracy, specifying the model and auto-detection. It distinguishes from siblings like transcribe_translate (audio translation) and generate_text (text generation) by focusing solely on text-to-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?

Provides guidance on when to use: privacy-preserving, pay-per-request with Bitcoin Lightning, no signup. Mentions prerequisite step (create_payment). However, does not explicitly compare to alternative translation tools or state 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?

With no annotations provided, the description fully discloses behavioral traits: it names the model (Real-ESRGAN), states it recovers real detail (not interpolation), mentions optional face enhancement, describes stable endpoint with automatic upgrades, and lists pricing (5 sats per image, pay-per-request with Lightning, no API key). No contradictions.

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

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

The description is concise (~70 words) and front-loaded with the primary action. Every sentence adds value: purpose, technical details, payment requirement, and behavioral notes. No redundancy.

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

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

For a tool with 4 parameters and no output schema, the description covers behavior, prerequisites, pricing, and model information. It does not describe the return format (e.g., base64 image), but given the context, it is reasonably complete.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds marginal value by noting the default scale (4x) and that imageBase64 can be a data URI. For a high-coverage schema, baseline 3 is appropriate.

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

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

The description clearly states the tool upscales images 2x or 4x using neural super-resolution. It distinguishes itself from sibling tools like 'edit_image', 'generate_image', and 'restore_face' by focusing on resolution enhancement via machine learning.

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

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

The description explicitly requires a prior payment via 'create_payment' with toolName='upscale_image', which is a clear usage prerequisite. However, it does not specify when to use this tool over alternatives like 'edit_image' or 'restore_face', leaving some ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: automatic STT muting during injection, coverage by session deposit, and the two modes. It does not cover potential errors or side effects, but the main behaviors are 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?

The description is very concise: five sentences with no filler. The first sentence states the purpose, then the two modes, then the STT muting, then payment. 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 6 parameters, no output schema, and no annotations, the description covers the core functionality well. It explains modes, muting, and cost. It could be more complete by mentioning error handling (e.g., invalid session) but is adequate for an agent.

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

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

All parameters have schema descriptions (100% coverage). The description adds significant context by explaining the two modes and how parameters relate (e.g., text vs audioBase64+encoding), which goes 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?

Description starts with a clear action verb ('Inject audio into an open Voice Bridge call') and specifies two distinct modes (TTS or custom audio). It differentiates from sibling tools like open_voice_bridge and end_voice_bridge by focusing on injecting audio into an existing 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?

The description explains that STT is muted automatically and that no extra payment is needed. However, it does not explicitly state when to choose mode 1 vs mode 2, nor does it provide any 'when not to use' guidance or alternatives. Usage is implied but not fully specified.

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

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

No annotations provided, so description carries full burden. It discloses cost ('1 sat per vote'), behavior ('multiple votes allowed'), return format ('Returns JSON: { success, slug, newVoteCount }'), and prioritization logic ('Highest-voted services get prioritized'). Could add error handling details, but overall strong.

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 succinct sentences. First sentence states action and return, second covers cost and allowance, third covers prerequisite and outcome. No fluff, 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 two required params, no enums, no output schema, the description covers all necessary context: payment flow, slug discovery, return structure, and voting rules. It is fully adequate 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?

Schema coverage is 100% but description adds context beyond schema: for slug it adds 'from list_planned_services', for paymentId it adds '1 sat, must be paid'. This aids correct usage beyond the schema's basic 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?

Description clearly states 'Vote for a planned service to be built next' with a specific verb (vote) and resource (planned service). It distinguishes from sibling 'list_planned_services' by mentioning it as a prerequisite, and no other sibling tool duplicates this 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?

Explicitly says to 'Call list_planned_services first' for valid slugs and vote counts, and 'Requires create_payment with toolName='vote_on_service''. 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.