Weftly

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it triggers processing after upload confirmation, returns errors for missing files or incomplete payment, and requires polling 'check_job_status' for progress tracking. This covers operational flow, error conditions, and async behavior, though it doesn't detail auth needs or rate limits explicitly.

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 well-structured: three sentences that efficiently cover purpose, prerequisites, error conditions, and next steps. Each sentence adds critical information without redundancy, making it easy to parse and front-loaded with the core action.

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

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

Given the tool's complexity (post-upload processing with async behavior), no annotations, and no output schema, the description does a good job of completeness. It explains the workflow, prerequisites, error cases, and follow-up actions. However, it lacks details on return values or output format, which would be helpful since there's no output schema.

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

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

Schema description coverage is 100%, with both parameters ('session_token' and 'job_id') documented in the schema. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain format or constraints for 'session_token' or 'job_id'). Baseline 3 is appropriate since the schema handles parameter documentation 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 clearly states the tool's purpose: 'Confirm the upload is done and start processing.' It specifies the verb ('confirm' and 'start processing') and resource ('upload'), but doesn't explicitly distinguish it from sibling tools like 'upload_file' or 'get_upload_url' beyond mentioning they are prerequisites. The purpose is clear but sibling differentiation is only implied through usage context.

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

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

The description provides explicit usage guidelines: 'Call this after uploading via either upload_file or the presigned URL from get_upload_url.' It names specific alternatives ('upload_file' and 'get_upload_url') as prerequisites and directs to 'poll check_job_status to track progress' for post-invocation. This clearly indicates when to use this tool versus others in the 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?

Discloses two-call workflow, payment requirement, source TTL (72h/24h), duration cap (30 min), flat fee ($0.50), output roles (clip-video, clip-srt, clip-words), transcript option, and auto-refund on failure. No annotations provided, so description fully addresses 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?

Description is detailed and well-structured, front-loading the main purpose and then logically expanding on workflow, payment, and constraints. Slightly verbose but all sentences add necessary context for a complex 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?

No output schema exists, but description fully explains return values (job_id, payment_challenge, output roles) and error handling (auto-refund). Covers source TTL, segment limits, and transcript behavior, making it complete for agent usage.

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

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

Schema coverage is 100%, but description adds essential workflow context (e.g., two-call flow, payment credential usage, segment ordering, label purpose) beyond the schema's basic field descriptions. Each parameter's role in the flow is explained.

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

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

Description clearly states the tool cuts and assembles clips from prior video jobs ('Cut and assemble a clip from any prior video job'). It specifies the resource (parent job) and action, and distinguishes from sibling 'extract_vertical_clip' by implying orientation difference.

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

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

Explicitly details when to use (for extraction from prior jobs), the two-call flow, payment process, and polling for completion. Provides guidance on alternatives (multiple calls independent, TTL limits) and contrasts with upload steps absent.

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

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

With no annotations, the description fully covers behavioral traits: default output (1080×1920 H.264/AAC), loudness normalization, source requirements (horizontal, TTL), the two-call flow, payment details, and auto-refund on failure. No contradictions.

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

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

The description is thorough and well-structured, starting with purpose, then specifics, flow, pricing, and optional parameters. It is slightly dense but all sentences are justified. Could be trimmed slightly, but overall efficient.

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

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

Despite no output schema, the description provides complete contextual coverage: purpose, constraints, two-call flow, pricing, payment methods, source prerequisites, and error handling. An agent can fully understand and invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds significant value by explaining the two-call flow for parameters (source_job_id+start+end vs. job_id+payment_credential), detailing each profile option, clarifying title usage, and noting that source_job_id is session-independent.

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 cuts a 9:16 vertical clip from prior video jobs (find_clips, summarize, or video transcribe) for short-form social media platforms. It distinguishes itself from siblings like extract_clip and find_clips by specifying the output format and use case.

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

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

The description explicitly explains when to use the tool (for social media vertical clips), when not to use it (source must be horizontal, single-segment only, duration 1-90 seconds), and provides alternatives (pair with find_clips). It also outlines the two-call flow and payment requirements.

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

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

With no annotations, the description fully discloses the payment flow, upload process, file expiration (72h), output format references to schemas, and auto-refund on failure. It also explains the source-reuse contract for extract calls.

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

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

The description is very long and thorough, but not concise. It includes extensive details that could be structured more compactly. While the content is valuable, it sacrifices brevity.

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

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

Given no output schema, the description thoroughly explains the output roles and schemas (clip-candidates, transcript, transcript-words). It covers the entire workflow including payment, upload, polling, and source-reuse, making it complete for an agent.

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

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

Schema coverage is 100%, baseline 3. The description adds significant context beyond schema: explains the three-call flow, how job_id is used, what filename does, and gives examples for query. It adds value beyond the schema descriptions.

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

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

The description explicitly states that find_clips is the canonical entry point for clip workflows, includes transcription as a free byproduct, and distinguishes it from siblings like transcribe and extract_clip. It provides a specific verb and resource with clear scope.

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

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

The description provides explicit usage guidelines: start here for clip workflows, do not call transcribe first, and details the three-call flow. It also warns against doubling uploads and spend, and gives retry behavior.

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

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

With no annotations provided, the description carries full burden and delivers substantial behavioral context. It discloses: polling behavior with timing constraints (60 seconds between checks), typical completion times (1-2 minutes for short files, 10-30 minutes for long files), presigned URL characteristics (time-limited to 1 hour), and recovery functionality for lost state. It doesn't mention error handling or rate limits, keeping it from a perfect score.

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

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

The description is appropriately sized and front-loaded with core functionality. Every sentence adds value: first defines purpose, second explains format parameter utility, third gives polling guidance, fourth provides timing estimates, fifth describes URL characteristics, sixth introduces recovery use case. Minor redundancy in explaining format options slightly reduces efficiency.

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

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

Given the tool's complexity (status checking with polling, recovery functionality, inline format options) and no annotations or output schema, the description provides comprehensive context. It covers purpose, usage patterns, behavioral expectations, parameter semantics, timing guidance, and edge cases (recovery from lost state), making it complete enough for effective agent use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that the 'format' parameter is 'useful when you need the text directly without fetching a URL' and clarifies that omitting it returns 'download URLs only'. This provides practical usage insight that enhances the schema's technical specifications.

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

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

The description clearly states the tool's purpose: 'Check the status of a transcribe or summarize job' with specific verbs ('check', 'retrieve') and resources ('job', 'download URLs', 'fresh challenge', 'upload URL'). It distinguishes from siblings like 'complete_upload', 'summarize', and 'transcribe' by focusing on status monitoring rather than job initiation or 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?

The description provides explicit usage guidance: 'Poll this periodically after calling complete_upload — wait at least 60 seconds between checks' and 'Also use this to recover from lost state'. It distinguishes when to use this tool versus alternatives by specifying it's for checking job status after job creation tools, and it includes timing recommendations for different file sizes.

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 statelessness, no job created, no database row written, and that it uses the exact same verification path as paid tools. Also mentions cost and two-call requirement.

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

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

Single dense paragraph but well-organized: purpose, flow, example, stateless note, usage guidance, cost. Every sentence adds value; slight lack of bulleted structure prevents a 5.

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 two-call payment flow complexity, description thoroughly explains the entire process, return values, and relationship to other tools. No output schema but description covers return of second call.

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

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

Schema coverage is 100% with one parameter. Description adds meaning beyond schema by explaining the parameter is the Authorization header value from paying the challenge, and should be omitted on first call. Very helpful.

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

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

The description specifies the tool is for smoke-testing MPP payment plumbing via a two-call flow costing $0.01 USDC. It clearly distinguishes this tool from paid siblings like transcribe and summarize by noting it's a cheaper health check.

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: 'whenever you want to confirm a wallet, the MCP transport, the worker, and the production payment middleware are all healthy without paying a transcribe price.' Provides the two-call flow steps. Does not mention when not to use or alternatives, but context is clear.

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

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

With no annotations provided, the description fully discloses behavioral traits: it explains the multi-step workflow (create job, pay, upload, poll), pricing details ($0.75 for audio, $1.25 for video), output formats (SRT, VTT, TXT, JSON), and constraints like segment-level transcripts and flat pricing per job, covering all critical operational aspects.

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

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

The description is well-structured and front-loaded with key information (purpose and workflow), but includes some redundant details (e.g., repeating the three-call flow and pricing in multiple sentences) that slightly reduce efficiency, though most content is valuable.

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

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

Given the tool's complexity (multi-step workflow, payment, sibling interactions) and lack of annotations or output schema, the description is highly complete: it covers the process, outputs, pricing, use cases, and integration with other tools, providing all necessary context for effective agent use.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra context (e.g., linking 'filename' to media type inference and 'payment_credential' to the MPP flow), but doesn't significantly enhance parameter understanding beyond what the schema provides, meeting the baseline expectation.

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 ('start a summarization job') and resources ('audio or video file'), and explicitly distinguishes it from the sibling 'transcribe' tool by noting it returns both a summary and transcript, eliminating the need for separate transcription calls.

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

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

The description provides explicit guidance on when to use this tool (e.g., 'good for meetings, long-form interviews, lectures, and podcast episodes where you want the gist without reading a full transcript') and when not to use it ('do not also call transcribe on the same file'), including clear alternatives and prerequisites like the three-call flow and payment process.

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 thoroughly describes the multi-step workflow, payment requirements (MPP, pricing details), file upload process (presigned URL with expiry), output formats (SRT, VTT, TXT, JSON), and polling mechanism. This goes well beyond basic functionality to include operational constraints and expected behaviors.

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

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

The description is appropriately sized for a complex tool, front-loading the core purpose and workflow. Every sentence adds value, though it's somewhat dense with technical details. The structure flows logically from purpose to process to pricing to use cases, with no redundant information.

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

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

Given the tool's complexity (multi-step workflow with payment integration), no annotations, and no output schema, the description provides comprehensive context. It covers the entire operational process, pricing, supported file types, output formats, and integration with sibling tools. This is complete enough for an agent to understand and correctly 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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the three-call flow and how parameters are used across different calls: 'filename' is required on first call, 'job_id' and 'payment_credential' are used together on second call, and 'job_id' alone can recover state. This contextual usage information isn't captured in the schema descriptions.

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

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

The description explicitly states the tool's purpose: 'Start a transcription job for an audio or video file.' It clearly distinguishes this from sibling tools like 'complete_upload' (for finalizing uploads) and 'get_job_status' (for polling progress), and specifies it's the first step in a three-call flow.

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

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

The description provides explicit guidance on when to use this tool: as the initial step in a multi-call workflow, with detailed instructions on subsequent steps (payment, upload, completion). It also lists use cases like 'podcasts, interviews, meetings, lectures, video content' and mentions alternatives implicitly by referencing sibling tools for later stages.

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