Sats4AI - Bitcoin-Powered AI Tools

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

With no annotations provided, the description carries full disclosure burden and succeeds comprehensively: specifies retry logic (3 voicemail attempts), cost structure (~150-250 sats), return states (pending_confirm), async polling requirement, payment method (Bitcoin Lightning), and output format (transcript with structured analysis).

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?

Eight information-dense sentences cover a complex multi-step workflow (payment → execution → potential confirmation → polling). While lengthy, every sentence delivers essential operational context (cost, languages, prerequisites, async pattern). Logical flow moves from purpose → behavior → edge cases → logistics.

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

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

For a complex async tool with no output schema, the description thoroughly covers return values (transcript, structured analysis, state flags), error/edge-case handling (pending_confirm), cost estimation, and the complete prerequisite chain. No gaps remain for safe 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%, establishing a baseline of 3. The description adds significant value by specifying the payment prerequisite workflow—namely that create_payment must be called with specific parameters (toolName='ai_call', phoneNumber, durationMinutes) to obtain the valid paymentId, which is critical context not inferable from 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 opens with a clear trigger condition ('When your task hits a wall that requires a human') and specific use cases (booking, negotiating, IVR navigation). It precisely defines the resource (AI voice agent) and action (handle the call), distinguishing it from simple notification calls through emphasis on 'two-way conversation' and autonomous task completion.

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

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

Provides excellent 'when to use' context (human-required tasks) and explicitly names critical workflow dependencies: create_payment for prerequisites, confirm_ai_call for pending_confirm states, and check_job_status for async polling. Lacks explicit contrast with sibling 'place_call' to clarify 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, so description carries full burden. Discloses cost (21 sats), payment mechanism (Bitcoin Lightning), auth model (no API key), and prerequisite dependency. Omits whether operation is sync/async (siblings suggest async tooling possible) and what return value contains.

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

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

Five sentences efficiently structured: functionality → model details → cost → auth → prerequisites. Front-loaded with core capability. Each sentence earns its place without redundancy, though dense with operational details.

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

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

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

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

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

Schema coverage is 100% with complete property descriptions. Description adds payment workflow context explaining how to obtain paymentId, but baseline 3 applies given schema already documents all parameters fully.

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

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

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

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

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

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

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

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

With no annotations provided, description carries full burden effectively: discloses async nature, return value (requestId), polling requirement, authentication model (no API key, Lightning payment), rate/cost structure, duration constraints, and preservation characteristics of the output.

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

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

Information-dense with zero fluff. Front-loaded with purpose ('Animate a still image...'), followed by behavioral details, async instructions, pricing, and prerequisites. Slightly dense syntax (em-dash heavy single paragraph) but every clause earns its place.

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

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

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

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

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

Schema coverage is 100% (baseline 3). Description adds critical workflow context for paymentId (must obtain via create_payment with toolName='animate_image') and reinforces duration constraints (3-15 seconds) mentioned in schema. Provides origin context for the payment parameter beyond schema's 'Valid payment ID'.

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

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

Description clearly states the specific action (animate still image into video) and distinguishes from siblings like generate_video by emphasizing source image fidelity and camera movement on existing images. Specific technology (Grok Imagine Video) and motion characteristics are noted.

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

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

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

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

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

Discloses return values (queued/processing/completed/failed) and special epub-audiobook behavior (progress percentage/chapter-level detail), which adds value beyond the schema. However, with no annotations provided, lacks operational details like read-only nature, idempotency, or error handling patterns.

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 efficient sentences with zero redundancy. First sentence covers purpose, scope, and general return values; second details the special case. Well front-loaded, though could benefit from explicit structure like 'Use this when...'

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?

Adequately documents return values (compensating for missing output schema) and supported job types. However, omits the important sibling relationship with 'get_job_result' and doesn't clarify the polling pattern expected for async jobs.

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

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

Despite 100% schema coverage, description adds semantic value by mapping enum values to human-readable job names in prose (e.g., 'generate_video' for 'video' enum), clarifying the relationship between the jobType parameter values and their corresponding operations.

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

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

Description uses specific verb 'Check' with resource 'status' and clearly distinguishes from sibling creation tools by listing the specific async jobs it monitors (generate_video, animate_image, etc.). Scope is precisely defined.

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?

Implies when to use by referencing 'async job' status checking, but fails to explicitly distinguish from sibling 'get_job_result'—a critical distinction for async workflows where users might confuse status polling with result retrieval.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It partially satisfies this by disclosing the return values ('paid/pending status'), which hints at the possible output states. However, it fails to declare whether this is a read-only operation, whether it requires specific permissions, or if there are rate limits for checking status.

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

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

The description consists of exactly two efficient sentences with zero waste. The first sentence front-loads the core purpose, while the second sentence immediately follows with the return value information. Every word earns its place.

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

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

For a tool with one parameter, no output schema, and no annotations, the description covers the basic operation and return values. However, it lacks completeness regarding the relationship to create_payment (how to obtain the paymentId), safety characteristics (read-only nature), or the full structure of the response beyond the status strings.

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

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

With 100% schema description coverage for the single 'paymentId' parameter, the schema already fully documents the input requirements. The description adds no additional parameter-specific semantics (format constraints, examples, or sourcing information), warranting the baseline score of 3.

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

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

The description uses a specific verb ('Check') and resource ('Lightning payment'), and mentions the return values ('paid/pending'). It implicitly distinguishes from sibling tools like check_job_status by specifying 'payment' instead of 'job', and from create_payment by using 'Check' versus 'Create'. However, it does not explicitly contrast with these siblings or clarify the Lightning Network context for users unfamiliar with the term.

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 no explicit guidance on when to use this tool versus alternatives (e.g., 'Use this after create_payment to verify completion'), nor does it mention prerequisites or conditions. The usage is only implied by the verb 'Check', requiring the agent to infer this is for querying existing payments rather than creating new ones.

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

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

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

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

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

Information-dense but front-loaded with purpose and output. Each sentence delivers distinct value (capability, output, quality, cost, prerequisites). Slightly packed but no redundancy given complexity and lack of annotations/output schema.

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

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

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

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

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

Schema coverage is 100%, establishing baseline 3. Description adds valuable context: 'single audio sample' clarifies voiceFileUrl constraints, and explicitly frames the model enum as speed-vs-quality tradeoff. 'Text validation accuracy' parameter remains unexplained (cryptic schema description), preventing a 5.

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

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

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

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

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

Explicitly states prerequisite workflow 'Requires create_payment with toolName='clone_voice''. Names the consuming sibling tool (text_to_speech) for the output. Pricing information (7,500 sats) clarifies cost context.

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

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

With no annotations provided, description carries full burden and discloses payment requirements, model characteristics ('vivid, natural'), and input constraints. Minor gap: does not specify output format or error behavior, though purpose is clear.

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

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

Four dense sentences covering: 1) core function, 2) technical specs, 3) cost/capability distinction, 4) prerequisites. No redundancy; front-loaded with essential selection criteria.

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

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

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

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

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

Schema has 100% coverage (baseline 3), but description adds critical workflow context explaining that paymentId comes from create_payment with specific toolName parameter—essential context not evident from schema alone.

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

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

States specific action ('Colorize black-and-white or grayscale photos'), identifies the underlying technology (DDColor), and distinguishes from siblings by noting this is 'Impossible for text/vision LLMs'—directly contrasting with ai_call and analyze_image.

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

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

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

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

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

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

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

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

Three well-structured sentences with zero waste. Front-loaded with the core action (confirm), followed by trigger condition, payment clarification, and return value/next step. Every sentence delivers essential workflow information.

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

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

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

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

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

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

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

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

The description clearly states the specific action (confirm an AI call) and resource (AI call), distinguishing it from the sibling ai_call tool by positioning it as the follow-up step required when ai_call returns state='pending_confirm'. It also differentiates from create_payment by noting no new payment is needed.

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

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

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

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

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

No annotations provided, so description carries full burden. It discloses return value ('Returns download URL'), cost ('100 sats'), quality characteristics ('preserves formatting and quality'), and auth model ('no API key, no account'). Does not mention rate limits or error behaviors.

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

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

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

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

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

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

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

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

Input schema has 100% description coverage, establishing baseline 3. Description adds implicit context about valid format values (e.g., 'pdf', 'docx') and cost context for 'paymentId', but does not add syntax details beyond what schema provides.

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

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

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

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

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

Provides clear prerequisite workflow: 'Requires create_payment with toolName='convert_file'' and payment context ('100 sats', 'Pay per request'). Clear context for when to use (after obtaining payment ID), though does not explicitly mention when to use sibling 'convert_html_to_pdf' instead.

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

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

With no annotations provided, the description carries full disclosure burden and succeeds in documenting: return type ('Returns download URL'), cost ('50 sats'), payment mechanism ('Bitcoin Lightning'), authentication model ('no API key or signup needed'), and dependency chain ('Requires create_payment'). No contradictions present.

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 efficiently structured: capability statement, use case elaboration, and payment/prerequisite details. Zero redundancy. Front-loaded with core function. Every sentence earns its place.

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

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

Comprehensive given no output schema exists: describes return value (download URL), explains business model, and documents prerequisites. Could mention error behaviors or file retention, but adequately complete for a payment-required utility 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?

Although schema coverage is 100% (baseline 3), the description adds crucial semantic context for paymentId parameter by explaining the payment flow (50 sats, Lightning, requiring create_payment first) that raw schema cannot convey. Also adds quality descriptor ('pixel-perfect') implying output characteristics.

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

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

The description opens with specific verb-resource combination ('Convert HTML or Markdown to a pixel-perfect PDF') that clearly distinguishes this from sibling convert_file and generate_image tools. It precisely identifies both input formats and output type.

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

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

Provides excellent explicit context with specific use cases ('invoices, reports, receipts, or formatted documents') and critical prerequisite instruction ('Requires create_payment with toolName='convert_html_to_pdf''). Lacks explicit 'when not to use' or alternative comparisons, but the prerequisite guidance is exceptionally 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 provided, so description carries full burden. Discloses 'Each payment covers exactly one output', pricing calculations (sats/sec, character count), and payment locking ('locked to payment'). Minor gap: doesn't describe the returned invoice structure or payment flow completion.

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

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

Dense single paragraph with multiple conditional clauses. All content earns its place (pricing rules, tool-specific requirements). Slightly long but warranted by 12-parameter polymorphic complexity. Could benefit from structured formatting (bullet points for tool-specific rules).

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

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

Excellent coverage of complex input requirements across 8 different service types. Addresses the polymorphic nature of the tool (different params for different services). Minor deduction: no output schema provided, and description doesn't clarify what invoice/payment details are returned.

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

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

Despite 100% schema coverage, description adds critical conditional logic: which parameters are required for which toolName values (e.g., duration for generate_video, resolution for edit_image). Includes pricing context (100 sats/sec, 200 sats for 1K) that explains parameter significance beyond 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?

Clear specific verb 'Create' + resource 'Lightning invoice' + scope 'one AI service call'. Explicitly distinguishes from sibling execution tools (generate_text, send_sms, etc.) by explaining this is the payment prerequisite for those services.

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

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

Explicit prerequisite 'Call list_models first'. Clear conditional instructions: 'For generate_text, you must provide...', 'For ai_call, also provide...'. Explains optional vs required parameters (modelId optional for default, phoneNumber required at payment time for specific 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?

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

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

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

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

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

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

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

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

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

Schema coverage is 100%, establishing baseline 3. Description adds critical workflow context explaining that paymentId requires pre-calling create_payment specifically with toolName='deblur_image'. Also clarifies the denoising option in prose, reinforcing the task_type enum semantics.

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

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

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

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

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

Explicit positive constraints ('Best for: handheld shake, bumped camera, whole-frame uniform blur') and negative constraints ('NOT effective for...'). Clear prerequisite stated: 'Requires create_payment with toolName='deblur_image'.' Provides complete when-to-use guidance.

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

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

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

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

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

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

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

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

Despite no output schema existing, the description fully documents the return structure (label + boolean flag). Given the complexity of the payment workflow and 100% schema coverage, the description provides all necessary context for invocation.

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

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

While schema coverage is 100%, the description adds crucial semantic context that the 'paymentId' parameter must be obtained via the 'create_payment' tool, clarifying the orchestration flow beyond the schema's 'Valid payment ID' string description.

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

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

The description opens with the specific action 'Classify image safety' and the discrete categories (normal/suggestive/explicit), clearly distinguishing this from the generic 'analyze_image' sibling tool. It also explicitly states the return values (classification label and is_nsfw flag).

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

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

Explicitly names the prerequisite workflow ('Requires create_payment with toolName='detect_nsfw''), provides the use case context ('Essential for content moderation pipelines'), and contrasts with alternatives ('100x cheaper and faster than asking an LLM').

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

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

With no annotations, description carries full burden and discloses: cost per request, Bitcoin Lightning payment method, no API key requirement, prerequisite workflow (create_payment), and output format (bounding box coordinates and confidence scores). Omits rate limits or error behavior, but covers primary behavioral traits.

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

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

Five sentences, each earning its place: purpose, technology/I/O, differentiation, pricing/auth, prerequisites. Front-loaded with core action, no redundancy. Efficient density of operational, financial, and technical information.

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

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

Comprehensive given medium complexity (payment integration, 5 params, no output schema). Compensates for missing annotations with payment workflow details and clarifies return values (bounding boxes) since no output schema exists. Minor gap in error handling or retry behavior.

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

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

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

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

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

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

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

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

Provides explicit prerequisite ('Requires create_payment with toolName='detect_objects''), cost structure ('5 sats per image'), and authentication model. Clear context on when to use versus vision LLMs (when structured pixel/bounding box data is needed), though it doesn't explicitly name sibling alternatives like analyze_image.

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

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

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

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

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

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

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

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

For a 6-parameter paid mutation tool with no output schema and no annotations, the description adequately covers return values, pricing, authentication prerequisites, and model capabilities. Complete enough for agent invocation planning.

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

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

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

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

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

Specific verb-resource ('Edit an image') and scope (natural language instructions). Lists distinct capabilities (object addition/removal, style transfer, inpainting) that distinguish it from specialist siblings like 'remove_background' or 'generate_image'.

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

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

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

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

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

No annotations provided, yet description comprehensively covers: processing duration (5-60+ minutes), cost structure (~1 sat per 90 chars, minimum 500 sats), output format (ZIP of MP3s), authentication model (no API key), and prerequisite workflow. Fully discloses behavioral traits beyond structured data.

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

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

Seven information-dense sentences with zero waste. Front-loaded with core conversion purpose, followed by quality claims, output format, pricing, timing, payment method, and prerequisites. Each sentence earns its place in logical progression.

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?

Complex async file-conversion tool with payment requirements and no output schema. Description fully covers return values (ZIP of MP3s), processing model (async with time estimates), cost structure, and prerequisite tools. Sufficient for agent to orchestrate complete 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 coverage is 100% (baseline 3). Description adds crucial workflow context explaining paymentId origin ('Requires create_payment') and voice parameter implications ('varies by voice model'). Adds meaningful semantics for epubBase64 (implied as book source) without冗余 repetition of 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?

Specific verb+resource combination ('Convert... EPUB book into... audiobook') with clear scope distinguishing it from sibling text_to_speech by emphasizing 'entire EPUB book', 'consistent voice across chapters', and 'ZIP of chapter MP3s' output format.

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 prerequisite stated ('Requires create_payment with toolName='epub_to_audiobook''), payment method specified (Bitcoin Lightning), and clear indication of async workflow vs synchronous alternatives. Contrasts with simpler text_to_speech by highlighting book-length processing.

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

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

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

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

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

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

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

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

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

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

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

Schema coverage is 100% (baseline 3), but description adds critical workflow context: explains that multi-page PDFs require quantity=pageCount when calling create_payment, linking the paymentId parameter to the prerequisite payment workflow. Enhances understanding of documentBase64 relationship to page count.

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

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

Explicitly states 'Extract text from PDFs and images as clean Markdown' with specific capabilities (tables, handwriting, math notation). Distinguishes from sibling extract_receipt by emphasizing complex layout handling and general document support rather than specific receipt fields.

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

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

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

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

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

No annotations provided, so description carries full burden. Discloses processing pipeline (Mistral OCR + Kimi K2.5), robustness features (handles crumpled/faded/multi-page), authentication model (no API key), and cost structure. Minor gaps: doesn't mention data retention, rate limits, or error scenarios (e.g., invalid payment).

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

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

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

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

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

For a payment-requiring OCR tool, covers purpose, prerequisites, cost, output structure (compensating for missing output_schema), and input capabilities. Could strengthen with error handling, rate limits, or data retention policy given the financial sensitivity.

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

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

Schema coverage is 100% with clear descriptions ('Valid payment ID', 'Base64 encoded receipt/invoice image'). Description contextualizes parameters (document types supported, payment requirement) but doesn't add syntax/format details beyond the schema. Appropriate baseline 3 given schema completeness.

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

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

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

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

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

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

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

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

With no annotations provided, the description carries full disclosure burden and succeeds comprehensively: it states the async pattern, polling mechanism, exact cost (350 sats), payment method (Bitcoin Lightning), authentication model (no API key), and dependency chain. It explains what happens behaviorally (returns requestId) and the commercial terms.

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

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

Six sentences, each delivering distinct essential information: purpose, technology details, async workflow, pricing, payment/auth mechanics, and prerequisites. No redundancy or filler. Information is front-loaded with the core purpose first, followed by operational constraints.

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 lacking an output schema, the description explicitly documents the return value ('returns requestId'). It comprehensively covers the commercial (pricing, payment), technical (Seed3D, GLB format), and operational (async polling) aspects necessary for an agent to successfully orchestrate this paid service.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds critical workflow context for paymentId (linking it to create_payment) and clarifies the image input constraint ('single photo'). It does not elaborate on modelId, but the schema handles this optional parameter adequately.

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 core action ('Convert a single photo into a textured 3D GLB model'), identifies the technology (Seed3D), and specifies the output format (GLB). It clearly distinguishes this from sibling generation tools like generate_image or generate_video by emphasizing 3D geometry generation from a single 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?

Provides explicit prerequisites ('Requires create_payment with toolName'), workflow guidance ('Async — returns requestId, poll with check_job_status'), and cost information ('350 sats per model'). It names the specific sibling tools (create_payment, check_job_status) required for the full workflow, leaving no ambiguity about invocation sequence.

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

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

No annotations provided, so description carries full burden. Discloses output format ('JSON with image URL'), cost structure (100/150/200 sats per model), payment mechanism (Bitcoin Lightning), and model lifecycle ('upgrade automatically as SOTA evolves'). Minor gap: does not clarify if operation is synchronous or requires polling via check_job_status sibling.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Strong disclosure given no annotations: explains pricing (100 sats), payment infrastructure (Bitcoin Lightning), output format (MP3 URL), model version (Music-1.5), and quality characteristics. Minor gap: doesn't clarify if operation is synchronous or async despite presence of check_job_status siblings.

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

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

Dense but well-structured: opens with core function, follows with technical specs (Music-1.5), then input requirements, output format, pricing, and prerequisites. Every sentence delivers unique, non-redundant information essential for a paid service tool.

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

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

Highly complete for a complex paid service tool with no output schema. Covers the full transaction lifecycle (payment → generation → delivery), auth requirements, and cost model. Slight deduction as it doesn't reference the sibling job status tools that might be needed for 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?

With 100% schema coverage, description adds crucial workflow context for paymentId ('Requires create_payment...'), maps prompt to 'style description', and clarifies lyrics as optional. Explicitly links the payment prerequisite to the parameter requirement, adding semantic value beyond the schema's 'Valid payment ID' 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?

Excellent clarity with specific verb 'Generate' + resource 'full song' + scope 'AI vocals, instrumentation, and arrangement'. Distinguishes from siblings like text_to_speech or generate_audio by emphasizing full song composition vs. simple audio generation.

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

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

Explicitly states prerequisite workflow: 'Requires create_payment with toolName='generate_music''. Provides cost context ('100 sats per song') and authentication method ('no API key or signup needed'), clearly establishing when/how to use vs. 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?

Strong disclosure given zero annotations: explains Bitcoin Lightning payment flow, per-character pricing model, automatic model upgrades ('Stable endpoints — models upgrade automatically'), and that no API key is required. Lacks explicit rate limits or async/sync status, but covers the critical business workflow.

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

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

Dense but efficient. Front-loads the core capability, then logically flows through pricing, model specs, features (file/vision), infrastructure notes, and prerequisites. Every clause conveys operational requirements; no marketing fluff. Slightly information-dense but appropriate for the tool's complexity.

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

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

Comprehensive for a tool with 8 parameters and no output schema/annotations. Covers the full user workflow (create_payment → generate), model capabilities (context windows, vision support), and input types (text, files, images). Missing technical constraints like file size limits or supported image formats.

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

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

Schema has 100% coverage (baseline 3). Description adds concrete use cases: 'document Q&A via fileContext' and 'vision analysis via imageBase64 (best model)', plus the requirement to match the prompt exactly in the payment call. This contextualizes the raw schema definitions effectively.

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?

Excellent specificity: declares the verb (generate), resource (text), and mechanism (frontier AI models). It implicitly distinguishes from siblings like generate_image, generate_music, and ai_call by focusing on text generation with specific language model options (Kimi, GPT-OSS, Qwen).

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

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

Provides explicit prerequisites ('Requires create_payment with toolName='generate_text'' and the exact prompt') and model selection guidance (default best, reasoning vs value options). Missing explicit differentiation from the 'ai_call' sibling tool, which appears to have overlapping functionality.

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

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

With no annotations provided, description carries full behavioral burden and succeeds comprehensively: discloses async execution pattern (returns requestId, requires polling), specific cost structure (300-550 sats/sec with audio premium), authentication model (Bitcoin Lightning, no API key), duration constraints (3-15s), and specific model characteristics (Kling v3 capabilities). Zero contradictions with implicit safe defaults.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining parameter usage with examples ('Pass service=text-to-speech&chars=1500') and clarifying semantics ('Omit params to see the full catalog'), which helps the agent understand how to combine parameters meaningfully beyond the schema's individual descriptions.

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

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

The description clearly states the tool's purpose with specific verbs ('Get an exact sat cost quote') and resources ('for a service'), distinguishing it from siblings like 'create_payment' or 'get_model_pricing' by emphasizing it's for pre-commitment pricing without payment. It explicitly mentions what it does (quote) and what it doesn't do (no payment, no side effects).

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

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

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

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

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

No annotations are provided, so the description carries the full burden. It discloses that no payment is required, which is useful behavioral context. However, it lacks details on rate limits, authentication needs, or response format, leaving gaps for a tool that agents might rely on for error handling.

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

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

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

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

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

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

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

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

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

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

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

The description clearly states the tool's purpose: to retrieve a catalog of error codes for the API. It specifies the verb ('Get') and resource ('machine-readable catalog of all error codes'), and distinguishes itself from siblings by focusing on error handling rather than core operations like image generation or text processing.

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

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

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

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

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

No annotations provided, so description carries full burden. It establishes this is a read operation for completed jobs, but lacks disclosure on error behavior (what happens if called on incomplete job?), result persistence (how long are results available?), or consumption patterns (idempotent vs destructive read).

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, zero waste. First sentence front-loads purpose. Second sentence provides essential prerequisite. Every word earns its place with no redundant 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?

Given 2 parameters with full schema coverage and no output schema, the description adequately covers invocation requirements. Missing details on error cases, result format variations by jobType, or result expiration, though the polymorphic nature of 'job' may limit specificity.

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

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

Schema has 100% description coverage with 'Request ID from the async operation' and 'Type of job'. The description adds contextual framing ('async job', 'completed') but does not add syntax, format details, or semantic relationships beyond what the schema already provides. Baseline 3 appropriate for high schema coverage.

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

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

Description uses specific verb 'Get' with specific resource 'final result of a completed async job'. Clear scope distinguishes it from sibling check_job_status by focusing on result retrieval versus status checking.

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

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

Explicit sequencing constraint 'Call only after check_job_status returns completed' provides clear when-to-use guidance and establishes prerequisite relationship with sibling tool. Effectively communicates the async workflow requirement.

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

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

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

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

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

Extremely efficient two-sentence structure. First sentence delivers the core purpose immediately; second sentence provides the critical behavioral constraint regarding payment. No redundant words or tangential information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations provided, the description carries full behavioral disclosure burden. It successfully documents stable numeric IDs, the isDefault=true mechanism for omitted modelId values, and the return payload structure. Minor gap: no mention of pagination or rate limiting.

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 with zero waste: core function, usage guideline, ID stability detail, default behavior, and filtering capability. Logical progression from what → when → how it behaves.

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?

Rich description compensates for missing output schema by detailing return fields (IDs, tiers, descriptions, pricing). Explains relationships to payment flow and default model selection. Complete for a discovery tool with optional single parameter.

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

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

Schema has 100% coverage (baseline 3), but the description elevates this by semantically connecting the category parameter to sibling tool names ('see models for a specific tool'), helping the agent understand the enum values map to available service categories.

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

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

The description clearly states the specific verb (List) and resource (AI models) plus detailed scope (IDs, tiers, descriptions, pricing). It distinguishes from sibling `get_model_pricing` by focusing on discovery and explicitly references `create_payment` as the downstream consumer.

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 temporal guidance ('Call this before create_payment to discover models') and explains the filtering purpose ('Filter by category to see models for a specific tool'), giving the agent clear context on when to invoke versus other discovery 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?

No annotations provided, so description carries full burden. It successfully discloses sorting behavior ('sorted by vote count, most-voted first') and billing/permission context ('No payment required'). Minor gap in not describing return structure, pagination, or empty-state behavior.

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

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

Four sentences that are all front-loaded and purposeful: purpose statement, billing constraint, usage guideline with sibling reference, and sorting behavior. Zero redundancy or filler content.

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

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

Given zero parameters and no output schema, the description adequately covers what the tool returns (services with vote counts), how results are ordered, and how to consume the output (slugs for voting). Minor gap in not describing the data structure or field types of the returned services.

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?

Tool has zero parameters with 100% schema coverage (empty properties object). Per guidelines, 0 params = baseline 4. Description correctly requires no additional parameter semantics since there are no inputs to document.

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 provides specific verb ('List') + resource ('planned services') + key attribute ('current vote counts'). It clearly distinguishes from sibling tool 'vote_on_service' by stating this is for discovering slugs to use with that tool, not for casting votes itself.

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

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

Explicitly states when to use ('discover what services are coming') and explicitly names the sibling alternative ('vote_on_service') for the actual voting action. Also clarifies cost constraint ('No payment required') which helps differentiate from payment-requiring siblings like '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. Discloses: output format (download URL), preservation behavior (bookmarks/links/formatting retained), cost (100 sats), and authentication model (no API key needed). Missing only minor details like rate limits or file size constraints.

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 efficient sentences: purpose statement, behavioral guarantee, output specification, and payment/auth requirements. No redundancy. Front-loaded with core function. Every sentence provides essential information not duplicated in structured fields.

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?

Compensates for missing output schema by specifying 'Returns download URL'. Explains complete payment lifecycle prerequisite. With no annotations and complex paid workflow, description provides sufficient context for successful invocation, though size limits or error conditions could enhance further.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds critical workflow context: paymentId must come from create_payment call with specific toolName, and files are consumed via base64 encoding (implied by context). Adds meaningful usage semantics beyond raw schema definitions.

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

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

Clear specific verb (Merge) + resource (PDF files) + output format (single document). Distinguishes from sibling tools like convert_file or extract_document by specifying the merge/combine operation.

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

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

Explicitly states prerequisite workflow: 'Requires create_payment with toolName='merge_pdfs''. Clear payment model (100 sats, Bitcoin Lightning, no account needed). Could improve by mentioning when to use alternatives (e.g., convert_file for format conversion).

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

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

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

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

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

Three well-structured sentences: purpose definition, usage context, and prerequisites. Every sentence earns its place with zero waste. Front-loaded with specific action ('Bridge the digital-physical gap').

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

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

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

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

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

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

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

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

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

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

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

Explicitly states when to use ('notifying a human, delivering alerts, or reaching someone who isn't online') and provides clear prerequisite workflow ('Requires create_payment with toolName='place_call''). Lacks explicit naming of alternatives (e.g., 'use send_sms instead for short digital alerts').

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

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

With no annotations provided, the description carries full behavioral disclosure burden and excels: covers cost (5 sats), payment mechanism (Bitcoin Lightning), auth model (no API key), output format (transparent PNG), model evolution (automatic SOTA upgrades), and prerequisite workflow. No contradictions with structured data.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three efficiently structured sentences: (1) core capability and differentiator, (2) technical implementation and examples, (3) pricing and prerequisites. Zero redundancy; every clause adds distinct value.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations provided, description discloses manual review process, 48-hour processing timeline, and prerequisite eligibility checks. Lacks detail on failure modes or cancellation policies.

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 tightly-constructed sentences, front-loaded with purpose. Each sentence delivers distinct value covering prerequisites, parameters, process, and billing. 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?

Comprehensive for a submission tool given 100% schema coverage: covers prerequisites, processing expectations, and parameter usage. Absence of output schema is partially mitigated by explaining the manual review process, though return value semantics remain unspecified.

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

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

Schema coverage is 100%, providing complete parameter documentation. Description adds directional semantics ('where the refund should be sent') but largely reinforces schema content rather than adding significant semantic value beyond it.

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

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

Clear specific verb ('Request') + resource ('refund') + scope ('for a failed service'). Explicitly distinguishes from payment creation tools and relates to sibling 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 states prerequisite condition ('Only works if...refundAllowed=true') and references sibling tool check_payment_status for verification. Clarifies 'No payment required' removing potential billing confusion.

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

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

With no annotations provided, the description carries full disclosure burden and succeeds in documenting cost ('5 sats per image'), payment mechanism ('Bitcoin Lightning'), model behavior ('upgrades automatically as SOTA evolves'), and the fidelity trade-off concept. It misses only output format details and rate limiting information.

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

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

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

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

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

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

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

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

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

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

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

The description opens with a specific verb-resource combo ('Restore... faces') and clearly scopes the input types ('blurry, damaged, or AI-generated'). It distinguishes itself from sibling tools like upscale_image or deblur_image by specifying face-specific restoration using CodeFormer technology.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema coverage is 100% (baseline 3). Description adds critical workflow context for paymentId ('Requires create_payment', cost amount) and intent for 'to' ('Reach anyone'). Repeats char limits already in schema but compensates with payment semantics.

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

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

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

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

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

Explicitly states when to use ('formal communication', 'contacting someone outside chat') and prerequisites ('Requires create_payment with toolName='send_email''). Lacks explicit 'when not to use' vs SMS/voice alternatives.

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

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

No annotations provided, so description carries full burden. It successfully discloses Bitcoin Lightning payment requirement, lack of SIM/plan needs, and the strict parameter matching constraint with create_payment. Minor gap on delivery confirmation mechanism or async status checking.

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

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

Six tightly-packed sentences with zero redundancy. Front-loaded with use case, followed by capabilities, constraints, and prerequisites. Every sentence conveys unique information about payment model, prerequisites, or scope.

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 complex two-step workflow (create_payment → send_sms) and 100% schema coverage, description adequately explains the handoff mechanism and constraints. No output schema exists; description could marginally improve by mentioning job status checking via sibling 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 coverage is 100%, establishing baseline 3. Description adds crucial workflow semantics regarding parameter consistency between this tool and create_payment (matching phoneNumber/message), which schema cannot express. Elevates above baseline.

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

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

Description opens with specific action ('Reach a human via SMS') and resource scope ('any phone number worldwide'), clearly distinguishing from sibling communication tools like send_email, place_call, or ai_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 prerequisite workflow ('Requires create_payment with toolName='send_sms''), cross-parameter constraints ('phoneNumber and message must match those used in create_payment'), and unique payment model constraints.

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

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

With no annotations provided, the description carries full burden and discloses key behavioral traits: cost (300 sats), output format (MP3 URL), authentication model (Bitcoin Lightning, no signup), and speed constraints (0.5-2.0x). Missing rate limits, error conditions, or URL expiration 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?

Every sentence earns its place: purpose statement, capability summary, specific features, return value, pricing, auth model, and prerequisites. Dense but readable with no redundancy or 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?

Adequately covers the complexity of the payment integration and extensive voice catalog. Compensates for missing output schema by specifying 'Returns MP3 URL'. Could benefit from mentioning error scenarios (e.g., insufficient balance) or URL expiration.

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% with extensive voice enum documentation, establishing a baseline of 3. The description adds confirmation of the speed range and mentions '3 quality tiers' (likely mapping to modelId), but largely defers to the comprehensive schema for parameter semantics.

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

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

The description opens with the specific action 'Convert text to natural speech audio' and immediately distinguishes capabilities (467 voices, 45+ languages, emotion control) that set it apart from sibling tools like generate_music or clone_voice. The payment requirement further differentiates it from free alternatives.

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

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

Explicitly states the prerequisite workflow 'Requires create_payment with toolName='text_to_speech'', which is critical for agent success. Describes the pay-per-request model and lack of API key requirements. Could improve by clarifying relationship to sibling clone_voice 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, but description comprehensively discloses: technology (Mistral Transcription), capabilities (accents/noise/overlapping speakers), constraints (13 languages, 512MB/3hr limit), cost (10 sats/min), payment method (Bitcoin Lightning), and async pattern (returns requestId).

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

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

Information-dense but well-structured. Every sentence delivers critical context for this complex multi-step tool (payment → submission → polling). Slightly long but necessary given async + payment complexity; no redundant 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?

No output schema exists, yet description adequately explains return value (requestId) and complete retrieval workflow. Covers all critical aspects: pricing, file limits, language support, prerequisites, and result fetching for this 3-parameter async tool.

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

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

Schema has 100% coverage (baseline 3). Description adds significant value: lists valid 13 language codes for the language parameter, clarifies paymentId must be 'paid', and implies audioBase64 constraints via file size limits (512MB).

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

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

States specific verb 'Transcribe' with resource 'audio' and feature 'timestamps'. Clearly distinguishes from siblings like text_to_speech (reverse operation), clone_voice, or generate_music by specifying speech-to-text conversion.

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

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

Exceptional guidance: explicitly states prerequisite 'Requires create_payment with toolName='transcribe_audio'', outlines async workflow 'poll with check_job_status(jobType='transcription'), then get_job_result', and specifies required jobType parameter value for the sibling tool.

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

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

With no annotations provided, the description carries the full burden and excels: it discloses the specific transformer model (Qwen3-32B), auto-detection behavior, privacy policy ('no data stored'), pricing structure ('1,000 characters per sat'), payment method (Bitcoin Lightning), and the required two-step workflow involving create_payment. This is comprehensive 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 front-loaded with essential information (function, model, key features) before detailing pricing and prerequisites. While the enumerated language list is lengthy, it serves as reference documentation. Each sentence conveys distinct value regarding capabilities, privacy, pricing, or workflow requirements with minimal 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 the 100% schema coverage and lack of output schema, the description successfully covers the operational model (payment prerequisite), cost structure, privacy guarantees, and technical specifications (model architecture). The only minor gap is the lack of description for the return value format, though this is somewhat mitigated by the straightforward nature of a translation 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%, establishing a baseline of 3. The description adds critical semantic context for the paymentId parameter by explaining it requires a prior call to create_payment with specific arguments. It also reinforces the optional nature of sourceLanguage by noting the auto-detection feature, adding meaning 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?

The description opens with a specific verb and resource ('Translate text across 119 languages') and immediately specifies the model used (Qwen3-32B) and key capabilities (low-resource support, auto-detection). It clearly distinguishes this from sibling tools like generate_text or transcribe_audio by focusing on multilingual translation specifically.

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

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

The description provides explicit prerequisite guidance stating 'Requires create_payment with toolName='translate_text',' which is critical workflow information. It also clarifies the authentication model ('no API key or signup needed'). However, it does not explicitly contrast when to use this versus other text-processing siblings like analyze_image or generate_text.

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

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

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

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

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

Efficiently structured: core function (sentence 1), technical credibility (sentence 2), quality differentiation (sentence 3), features (sentence 4), reliability (sentence 5), pricing/auth (sentence 6), prerequisites (sentence 7). Zero redundancy; every sentence adds distinct operational context.

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

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

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

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

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

With 100% schema coverage, baseline is 3. Description adds value by contextualizing paymentId within the create_payment workflow requirement, reinforcing scale enum values (2x/4x), and clarifying face_enhance as 'Optional face enhancement' rather than just a boolean flag.

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

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

Opens with specific verb-resource combination ('Upscale images 2x or 4x') and technical method ('neural super-resolution'). The 'not interpolation' phrase distinguishes from basic resizing tools, while 'Real-ESRGAN' and scale factors clearly differentiate from sibling enhancement tools like deblur_image or restore_face.

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

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

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

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

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

With no annotations provided, the description carries the full burden and discloses cost ('1 sat per vote'), business logic ('Highest-voted services get built first'), and the multi-step workflow. It lacks details on idempotency or error states, but covers the essential transactional 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?

Four sentences with zero waste: purpose, cost, prerequisite, and payment requirement. Information is front-loaded and every clause earns its place by conveying necessary orchestration logic.

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

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

For a transactional tool with no output schema, the description adequately explains the voting mechanism, cost structure, and prioritization logic. It omits specific return value details but provides sufficient context for successful invocation.

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

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

While the schema has 100% coverage (baseline 3), the description adds crucial semantic context: the slug must come from list_planned_services, and the paymentId must be created specifically with toolName='vote_on_service', clarifying parameter relationships beyond the schema.

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

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

The description opens with a specific verb ('Vote') and resource ('planned service') and clarifies the outcome ('to be built next'), clearly distinguishing this from sibling tools like create_payment or list_planned_services.

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

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

Explicitly states prerequisites ('Call list_planned_services first') and external dependencies ('Requires create_payment with toolName='vote_on_service''), providing a clear orchestration workflow that prevents incorrect invocation sequences.

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