Weftly

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

With no annotations provided, the description carries the full burden. It discloses that the tool verifies file presence in storage and job payment, and that it returns status 'processing'. This covers key behavioral aspects, though it omits error scenarios or authentication requirements.

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

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

The description is two concise sentences, front-loaded with the primary action and immediately providing necessary context on preconditions and next steps. Every sentence adds value with no unnecessary wording.

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

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

For a simple tool with one parameter and no output schema, the description provides sufficient context: it explains the upload prerequisite, the verification behavior, the returned status, and how to track progress. It lacks explicit failure handling but is otherwise complete.

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

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

The schema fully describes job_id as 'The job_id returned from a previous transcribe or summarize call.' The description does not add extra semantic detail beyond that, but since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Confirm that the file has been uploaded (via HTTP PUT to the upload_url from transcribe or summarize) and start processing.' This specifies a concrete verb and resource, and distinguishes it from siblings like transcribe/summarize (which initiate jobs) and get_job_status (which polls progress).

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

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

The description provides clear context: it should be used after uploading the file via HTTP PUT to the upload_url, and it explicitly recommends polling get_job_status afterward. It doesn't explicitly state when not to use the tool, but the precondition and follow-up are clear enough to guide proper usage.

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

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

With no annotations, the description carries full burden and does so thoroughly: discloses two-call payment flow, output roles (clip-video, clip-srt, clip-words), audio normalization, 72h/24h TTL, auto-refund on failed jobs, and segment limitations.

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

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

Long but dense; every sentence adds essential context (pricing, TTL, output roles, payment flow). The structure is a single coherent paragraph with no wasted words 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?

Covers the full lifecycle: first call with source_job_id and segments, payment via MPP/Stripe, second call with job_id and payment_credential, polling, output roles, and source storage expiry. Fully compensates for the lack of an output schema.

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

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

Despite 100% schema coverage, the description adds substantial meaning: explains that segments compose a single mp4, flat $0.50 fee regardless of segment count, 30-minute cap, payment_credential format, and include_transcript default behavior.

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

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

The description clearly states the tool 'Cut and assemble a clip from any prior video job' with a specific verb and resource. It distinguishes from siblings by specifying it operates on a parent job (find_clips, summarize, or video transcribe) rather than uploading new media.

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 two-call flow and describes when to use (from prior video jobs) while noting 'no upload step'. However, it doesn't explicitly contrast with the sibling extract_vertical_clip, so it misses a clear alternative exclusion.

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

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

With no annotations, the description carries the full transparency burden and excels: it discloses output specs, audio normalization, single-segment limitation, fallback behavior for subject strategies, auto-refund on failure, and storage TTL. It even explains parent-job capability semantics, making behavioral expectations crystal clear.

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

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

The description is long but every sentence delivers critical information. It is front-loaded with purpose and output, then systematically covers constraints, flow, pricing, options, and fallbacks. There is no fluff or tautology; the structure mirrors the operational sequence an agent needs.

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

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

Covers purpose, prerequisites, payment flow, output role, polling mechanism, failure behavior, and complementary tools. With 12 parameters and no output schema, the description compensates fully, leaving no significant gap for an agent to guess.

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 enormous value by explaining the two-call flow, distinguishing first-call vs second-call required parameters, and detailing profile performance differences (e.g., 720p ~40% faster) and subject strategy behaviors. This transforms bare schema entries into actionable operational knowledge.

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 'Cut' and clear resource 'a 9:16 vertical clip from any prior video job', explicitly naming the parent job types and output platforms. It distinctly differentiates from siblings like extract_clip by emphasizing vertical format and social-media readiness, eliminating ambiguity.

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

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

Provides explicit when-to-use guidance: 'Pair with find_clips... to pick a moment first', and defines prerequisites such as horizontal-only sources, TTL constraints, and the two-call payment flow. It clearly states the tool is single-segment and duration-limited, helping the agent decide if another tool is needed.

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

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

With no annotations provided, the description carries the full burden. It discloses the free transcription byproduct, payment challenge flow, presigned URL expiry, 72-hour source retention, retry behavior, and auto-refund policy. It also explains the three output roles and their schemas—excellent transparency.

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

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

The description is long but every sentence conveys essential information (flow, pricing, source reuse, retry). It is front-loaded with 'START HERE' and uses bold for key terms, though the single dense paragraph could benefit from clearer sectioning for readability.

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

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

Given the multi-step payment flow, three distinct output roles, and cross-tool source-reuse contract, the description covers all necessary context: pricing, schemas, timing, retry semantics, and failure handling. It fully prepares an agent to invoke the tool correctly without additional external knowledge.

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

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

The schema already provides 100% parameter coverage, and the description adds minimal parameter-level meaning beyond the flow context. It reinforces `query` mode behavior and `job_id` recovery but does not significantly exceed the schema's 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 'START HERE for any clip workflow on a video' and clearly states the tool identifies 'ranked candidate clips in a video — what to cut for highlights, social, or testimonials.' It distinguishes itself from siblings by explicitly warning not to call `transcribe` first and by outlining the extract 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?

Provides explicit when-to-use guidance ('canonical entry point'), a direct alternative exclusion ('Do not call transcribe first'), a step-by-step three-call flow, and a source-reuse contract for `extract_clip`/`extract_vertical_clip`. This is exemplary usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses extensive behavioral details: outputs are either inline 'content' or a presigned time-limited (1-hour) 'download_url', format parameter behavior with derived formats (txt/vtt from SRT, json v1 vs v2), and output type variations. This goes beyond a simple status check and fully informs the agent.

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

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

Although fairly long, the description is well-structured and front-loaded with the main purpose. Every sentence provides value: return format details, format parameter behavior, polling intervals, expected durations, and recovery scenarios. No filler or 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?

Despite no output schema, the description comprehensively covers output structure, parameter usage, polling guidance, expected completion times, and recovery from lost state. It is complete for a status-checking tool with complex output semantics.

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 semantics beyond the schema. It elaborates on the 'format' enum values (e.g., txt/vtt derived from SRT, json v1 vs v2 with schema reference), and explains when 'format' applies (on completion) versus default download URLs. This exceeds the baseline for high schema coverage.

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

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

Clearly states the tool checks the status of transcribe or summarize jobs and returns the current state and outputs array. Distinguishes from sibling tools like transcribe/summarize (job creation) and complete_upload (uploading).

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

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

Explicitly instructs to poll after complete_upload with a 60-second wait, provides expected completion times, and describes a recovery use case for lost state. Clear context but does not explicitly list when not to use or name alternative 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?

With no annotations, the description carries the full burden. It discloses the possible return states (pending, publishing, completed, failed), when youtube_video_url appears, and expected latency. This gives the agent a clear behavioral model without over-specifying.

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

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

Two sentences, front-loaded with the primary action, then supplementary details. No wasted words.

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

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

For a simple polling tool with no output schema, the description adequately covers purpose, return format, timing, and usage trigger. Missing error handling details but not necessary for this complexity level.

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% for both parameters, so the baseline is 3. The description adds no new parameter-level detail beyond what the schema provides; it only references job_id relationship in passing. No addition to schema 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 'Check the status of a YouTube publish job' — a specific verb and resource that clearly distinguishes it from generic get_job_status. It also references trigger_youtube_publish, confirming its role in the publish workflow.

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

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

It states 'Poll periodically after trigger_youtube_publish' and provides a time estimate (1-10 minutes), telling the agent exactly when to call it. It doesn't explicitly mention alternatives like get_job_status, but the temporal coupling makes the usage context unambiguous.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: statelessness ('no job is created, no database row written'), the $0.01 USDC cost per attempt, the two-call protocol with expected responses, and the relationship to paid product tools. This is comprehensive and exceeds what annotations would typically provide.

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

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

The description is relatively long but each sentence contributes meaningful information: the flow, cost, statelessness, and use case. While it could be tightened, the structure logically moves from purpose to flow to benefits, making it effective despite its length.

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

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

The description is complete for the tool's complexity: it covers the two-call flow, expected response format, cost, side effects (none), and when to use it. No output schema exists, but the description describes the response structure ('{paid: true, timestamp, receipt_ref, payment_method}') so the agent knows what to expect.

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

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

The schema already has 100% coverage for the single parameter, so the baseline is 3. The description adds value by explaining the credential's role in the two-call flow, providing an example format ('Payment eyJ...'), and explicitly stating to omit it on the first call. This enriches the schema's description without redundancy.

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 this is a smoke test for MPP payment plumbing, with a specific verb ('smoke-test') and resource ('MPP payment plumbing via this MCP server'). It distinguishes itself from sibling paid tools by explicitly noting it uses the same verification path as transcribe/summarize but costs only $0.01 USDC and creates no job.

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 usage guidance is provided: 'Use this 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.' It also explains the two-call flow, making it clear when and how to use it as an alternative to paid 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?

With no annotations provided, the description carries the full burden. It discloses the $1.75 price, OAuth token storage, auto-generated captions, and the required OAuth scope, which are meaningful side effects and conditions. It does not cover failure modes or token expiry behavior, but the disclosed details go beyond a generic 'publish' statement.

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 deliver purpose, side effects, caption behavior, workflow, and OAuth requirements without redundancy. Information is front-loaded and every sentence contributes.

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

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

The description explains the overall process and points to get_youtube_publish_status for polling, covering the main constraints (existing job, OAuth token, cost). It does not describe the API response shape or failure handling, but given the workflow is explicit, the tool is sufficiently contextual 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?

The input schema already provides descriptions for all 7 parameters (100% coverage). The description adds workflow context and reiterates that captions are auto-generated, but does not add new parameter-specific semantics beyond what the schema already states. Thus, a baseline score of 3 is appropriate.

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

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

The description opens with a specific action—publishing an existing video from a transcribe or summarize job to YouTube—and clarifies it creates a paid publish job rather than directly uploading. It references the broader workflow, distinguishing itself from trigger_youtube_publish while naming it in the sequence.

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

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

It states the prerequisite of an existing transcribe/summarize job and an independently obtained YouTube OAuth token, and lays out the full workflow (create_job → pay → trigger_youtube_publish → poll). It does not explicitly say when not to use this tool or directly compare with alternatives, leaving some room for confusion with the sibling trigger_youtube_publish.

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 excels: it discloses the three-call payment flow, MPP credential requirements, presigned URL expiry, idempotent retries, auto-refund on failure, and the exact output roles/formats. This is exceptionally thorough for a complex paid tool.

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

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

The description is front-loaded with the core purpose and a critical warning. Every sentence contributes necessary detail for the complex flow, pricing, and outputs, but the paragraph is long and dense, making it somewhat heavy to parse.

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

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

Given no output schema and no annotations, the description covers the full lifecycle: initial call, payment, upload, polling, output formats, use cases, pricing, idempotency, and refunds. It even references relevant JSON schemas and includes authoritative pricing. This is remarkably complete.

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

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

Schema coverage is 100% and each parameter already has a rich description covering its purpose and timing. The tool description repeats the flow but adds no semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool summarizes audio/video files and returns both a text summary and full transcript with per-word timestamps. It distinguishes itself from the sibling 'transcribe' by explicitly warning 'Do not also call transcribe on the same file', making the scope and differentiation clear.

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

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

It provides explicit use cases ('meetings, long-form interviews, lectures, and podcast episodes') and a clear when-not ('Do not also call transcribe'). However, it does not compare against other relevant siblings like extract_clip or find_clips, so while guidance is strong, it is not fully exhaustive.

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 carries the burden of behavioral disclosure. It explains the multi-step payment flow, presigned PUT URL with 1-hour expiry, MPP payment challenge, idempotent retries, auto-refund on failed jobs, and the exact output shapes from get_job_status across different formats. This far exceeds the minimum transparency expected.

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

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

The description is long but every sentence earns its place, covering a complex multi-step protocol in a logically ordered flow. It front-loads the core purpose, then systematically walks through the three-call sequence, output formats, pricing, and edge cases without redundancy or fluff.

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

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

Given the tool's high complexity (multi-step payment, upload, polling, multiple output formats), the description leaves no critical gap. It covers all invocation phases, return types via get_job_status, pricing, failure handling, and even points to authoritative schemas. No output schema exists, but the description fully explains expected results.

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

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

Although the input schema already provides descriptions for all three parameters, the description adds substantial meaning beyond the schema. It explains the call sequence (filename first, then job_id + payment_credential), the purpose of each parameter in context, and additional details like the full Authorization header format and supported filename extensions. This significantly aids correct invocation.

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 'Transcribe audio or video to text, including per-word timestamps for precise editing,' which is a specific verb+resource statement that clearly conveys the tool's core function. It distinguishes itself from sibling tools like summarize or find_clips by focusing on transcription with word timestamps and downstream editing use cases.

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

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

The description provides an explicit three-call workflow with numbered steps, specifying exactly when to use each parameter and how to complete the process. It also names concrete use cases (podcasts, interviews, meetings, lectures, clip creation) and notes idempotent retry behavior, giving clear guidance on how to invoke the tool correctly.

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

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

Discloses asynchronous behavior: 'Returns immediately' and 'runs as durable Workflow in the background'. Without annotations, this essential behavioral transparency sets expectations. Could add more about idempotency or failure modes, but the core behavior 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?

Three concise sentences, front-loaded with purpose, no fluff. Each sentence adds workflow context, return behavior, or monitoring advice.

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

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

Covers workflow integration, return behavior, and monitoring in a compact description. Sufficient for a tool with simple schema and 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 already covers both parameters with descriptions. Description doesn't add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

Specific verb 'Start' and resource 'YouTube upload' clearly state the action. Distinguishes from siblings by referencing publish_to_youtube as predecessor and get_youtube_publish_status as successor.

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 call after publish_to_youtube once payment_status is 'paid', which is a clear condition. Also mentions polling get_youtube_publish_status for progress, guiding agent on alternatives.

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