Botverse

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

Description goes beyond annotations by explaining that queued/dispatched steps are cancelled, completed steps are not reversed, and billing only applies to completed steps. This adds critical behavioral context not covered by annotations.

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

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

Three concise sentences, front-loaded with the primary action. Every sentence adds specific value without redundancy or 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?

Given the tool's simplicity (one parameter, output schema present), the description fully covers cancellation behavior, impact on steps, and billing. No gaps for effective 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?

Single parameter 'workflow_id' has 100% schema coverage with a description. The tool description adds no additional meaning beyond the schema, so baseline score applies.

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

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

The description clearly states 'Cancel an in-progress workflow' with a specific verb and resource. It distinguishes from sibling tools like submit_workflow and get_workflow_status by focusing on cancellation.

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

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

The description implies use cases for cancellation and includes billing implications. While it doesn't explicitly list when not to use or alternative tools, the context is clear and sufficient for an agent.

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

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

Discloses limits (4 MB), server-side execution, async flow, pricing, and polling instructions. Annotations provide little behavioral info, so description compensates well, though could note absence of destructive side effects more 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?

Well-structured: purpose, guidelines, limits, alternatives, async flow, pricing, CLI tip. Every sentence is informative and 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?

Covers all necessary aspects: input/output formats, async polling, sandbox considerations, pricing, and CLI alternative. No gaps for agent decision-making.

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

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

Adds meaning beyond the schema by explaining content encoding, use of base64, supported formats, and return value (job_id). Schema coverage is 100%, but description provides valuable context.

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

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

The description clearly states 'Convert a document inline' and distinguishes this tool from siblings like convert_from_url and the CLI alternative. It specifies the content-passing method and sandbox suitability.

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

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

Explicitly says it's the preferred route for documents and sandboxed environments, with an alternative for larger files. Also provides a CLI tip for non-sandboxed agents.

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?

Beyond annotations (readOnlyHint=false, etc.), the description discloses that the tool returns a job_id immediately, conversion happens server-side, there is a $0.05 fee, and polling is required. No contradictions with annotations.

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

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

The description is detailed but well-structured with clear workflow steps, supported formats, fee, and alternatives. It could be slightly more concise but effectively communicates all necessary 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, fee, polling, alternatives), the description covers all contexts: upload process, supported formats, return value (job_id), polling instructions, and alternative tools for blocked environments.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds meaning by linking object_key to the prior get_upload_url step, though it does not add syntax details beyond the schema.

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

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

The description clearly states the tool's purpose: offloading document conversion to Botverse using an already-uploaded file. It lists supported input/output formats and explicitly distinguishes from sibling tools like convert_content and convert_from_url.

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

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

The description provides explicit when-to-use guidance, including a multi-step workflow, instructions to poll get_job_status, and a flat fee. It also specifies when NOT to use (sandboxed environment blocked PUT) and names alternatives (convert_content, convert_from_url).

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

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

Describes server-side execution, sandbox compatibility, 4MB inline limit for convert_content, cost of $0.05 per file, return of job_id, and polling instructions. Annotations provide safety profile, no contradiction.

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

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

Front-loaded with main purpose, but slightly long. Every sentence adds value; could be trimmed slightly for conciseness.

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

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

Covers all aspects: asynchronous nature, polling, output retrieval methods, supported formats, cost, and limitations. Output schema exists, so return values are 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?

Adds significant context beyond schema: source_url value context (public HTTPS, provider-specific behavior), output_format enum list matches schema, and additional guidance on file types.

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 offloads a document conversion to Botverse, runs server-side, and returns a download link. Distinguishes from sibling convert_content (for strings) and transcode_from_url (for video).

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

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

Explicitly says when to use (public URL, direct download links, Dropbox/Google Drive/Box auto-resolve), when not to use (OneDrive/SharePoint unreliable), and provides alternative (convert_content for strings).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds value by disclosing the URL is presigned, expires in 24 hours, and that direct S3 download is blocked in sandboxes—environment-specific behavior beyond annotations.

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

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

Concise, front-loaded with main action. All sentences add value: prerequisites, expiration, sandbox warning, alternative. 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?

Given tool simplicity (1 param, output schema exists), description covers purpose, usage conditions, environment constraints, and alternative. No gaps.

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

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

Single parameter job_id has 100% schema coverage. Description adds context that job_id comes from transcode_video, transcode_from_url, or any convert tool, aiding understanding beyond schema.

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

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

Clearly states it gets a presigned HTTPS URL for downloading the completed output file. Mentions prerequisite (after get_job_status returns 'complete') and expiration (24 hours). Distinguishes from sibling tool get_output_content by noting environment restrictions.

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 specifies when to call (after get_job_status returns 'complete') and when not to (sandboxed environments), providing an alternative (get_output_content). No ambiguity.

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

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

Annotations already declare safe, idempotent behavior. The description adds critical behavioral context: polling strategy, expected statuses, time estimates, and indefinite retry logic. This goes well beyond annotations.

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

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

The description is concise (3 sentences), front-loads the purpose, and every sentence provides essential guidance without redundancy.

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

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

Given the presence of an output schema (return values documented), the description covers all necessary aspects: polling behavior, terminal conditions, timing, and error handling instructions. It is complete for a polling 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 for job_id is 100% and includes a description listing source tools. The tool description does not add further parameter meaning, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: polling the status of transcode or convert jobs. It uses specific verbs and resources, and the context distinguishes it from sibling tools like get_workflow_status by specifying the job 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?

The description provides explicit usage guidance: polling every 5 seconds until terminal status, handling normal statuses, and warning against fixed attempt limits. It does not explicitly mention alternatives or when not to use, but the guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it delivers base64 inline, is limited to 4 MB, and explains the sandboxed environment context. 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 a single paragraph with multiple sentences. It is clear and informative, but slightly longer than necessary. Could be broken into bullet points for better structure, but still concise enough.

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 one parameter, output schema exists, and good annotations, the description covers what, when, limitations, and alternatives comprehensively. No gaps.

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

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

Schema coverage is 100% for the single parameter job_id. The description says 'Job ID from any convert or transcode job' which aligns with the schema. No additional 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?

The description clearly states 'Return the finished output of a completed job INLINE as base64 — no S3 download.' It specifies the verb (return), resource (output), and scope (inline, base64). It also distinguishes from get_download_url by mentioning the alternative.

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

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

Explicitly says to use this in sandboxed environments where get_download_url is blocked, and for larger outputs use get_download_url. Also states to call after get_job_status returns 'complete'. Provides clear when-to-use and when-not-to-use.

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

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

Beyond annotations (readOnlyHint: false, openWorldHint: true), the description discloses expiration (15 min), that it's a presigned POST not PUT, the required upload flow (multipart/form-data with fields then file), and a critical network access restriction for sandboxed agents. This adds significant context beyond the structured annotations.

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

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

The description is long but every sentence is informative. It is well-structured: starts with basic purpose, then technical details (expiration, HTTP method), then critical constraints and alternatives. No fluff 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?

Given the tool's complexity (upload flow, subsequent operations, network restrictions), the description covers all necessary aspects. It tells the agent how to use the response, what to do after upload, and provides fallback paths for restricted environments. An output schema exists for return values, so not mentioning them is acceptable.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing examples of filename (e.g., report.md) and listing common MIME types for content_type (video/mp4, text/markdown, etc.). This helps an agent select appropriate values, though it does not deeply explain each parameter's semantics beyond what the schema offers.

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

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

The description clearly states that the tool gets a presigned upload form for any file type (video, audio, document). It specifies the verb 'Get', resource 'presigned upload form', and distinguishes from siblings by mentioning subsequent tools (transcribe_media, transcode_video, convert_file) and alternatives for sandboxed environments.

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

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

The description explicitly says when to use this tool (for files needing upload to Botverse storage) and when NOT to use it (in sandboxed environments without direct network access). It lists specific alternatives: convert_content, transcode_content, convert_from_url, transcode_from_url, transcribe_from_url. This provides excellent 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds limited behavioral context. It mentions the check operation and prepaid nature, which is consistent but not adding critical new info.

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

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

Two concise sentences, the first stating purpose and the second providing usage guidance. No wasted words.

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

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

Given the tool's simplicity (no parameters, no required inputs, and an output schema exists), the description is complete and provides sufficient context 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 has zero parameters and schema description coverage is 100%. With no parameters, the baseline is 4; the description adds no parameter details, but none are needed.

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 identifies the resource 'prepaid wallet balance for this Botverse account.' It clearly distinguishes from sibling tools which deal with conversions, uploads, and transcoding.

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: 'Use before large batch jobs to confirm sufficient funds.' It provides clear context but does not mention alternatives or when not to use.

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

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

The description states 'Each call may advance the workflow,' implying side effects, but annotations set readOnlyHint=true. This is a direct contradiction per instructions, warranting a score of 1.

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 that get straight to the point: purpose, behavior, then polling advice. No extraneous words, well-structured.

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

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

Given the output schema exists and annotations provide safety info, the description fully covers purpose, behavioral nuance (state advancement), and usage pattern. Nothing missing for a status-checking 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 covers the single parameter with a clear description. The tool description adds no additional parameter info beyond what schema provides, 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?

The description clearly states the tool gets workflow status and all steps, with specific verbs and resource. It distinguishes from sibling tools like submit_workflow and cancel_workflow by noting the polling behavior and state advancement.

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 instructions: poll every 5-10 seconds until terminal status. However, it does not mention when to avoid using this tool or contrast with alternatives like get_job_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?

Discloses asynchronous behavior (returns workflow_id immediately, poll for status), idempotency (implied by unique workflow_id), and billing conditions. Mentions that no other template syntax is supported. Goes well beyond annotations which only show idempotentHint true.

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?

Somewhat lengthy but every sentence adds value. Front-loaded with core purpose then details. Could be slightly more concise, but the structure is logical and easy to follow.

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

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

Comprehensive coverage of submission semantics, step dependency ordering, parallel execution, inter-step references, billing rules, and schema availability. With an output schema present, the description fully prepares an agent to use the tool correctly.

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

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

Adds rich meaning to the sole 'definition' parameter: explains it must be BWDL, includes required fields (workflow_id, steps), and provides detailed inter-step reference syntax with examples. Schema coverage is 100% but description significantly enhances understanding.

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

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

Clearly states it submits a multi-step workflow to the Botverse workflow engine, distinguishing it from simpler conversion tools and sibling tools like cancel_workflow and get_workflow_status. The verb 'submit' plus 'multi-step workflow' is specific and unambiguous.

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

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

Explicitly describes when to use (for multi-step workflows) and indirectly when not (use convert tools for single conversions). Provides billing guidance, polling recommendations, and a schema reference. Alternative tools are implied by sibling list and 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?

Annotations are limited (readOnlyHint=false, etc.). Description adds significant context: returns job_id immediately, wallet debited on completion, 2 GB limit, reliability/fallback handling, polling instructions, and explanations of Botverse vs MCP errors. 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?

Description is long but front-loaded with purpose. Every sentence adds value, but could be slightly trimmed without losing information. Still very good 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?

Given output schema exists (return values not needed), description covers input, behavior, limitations, error handling, polling, fallback. Very complete for a complex tool with multiple use cases.

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 meaning: explains start_time/duration with examples, details source_url types, clarifies output_format options, and provides usage tips. Adds value beyond schema.

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

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

Clearly states 'Offload a video or audio transcode to Botverse using a public URL — no upload step needed.' Specific verb and resource, distinguishes from siblings like transcode_video and transcribe_from_url.

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

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

Explicitly says when to use (public URLs, Dropbox/Google Drive/Box, not OneDrive/SharePoint), provides alternatives (upload via get_upload_url), and fallback guidance (use CLI if MCP fails). Also advises against writing own code.

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 key behaviors: returns job_id immediately, constraints (≤10 min, ≤5 GB), polling instructions, wallet debit on completion, and error handling (structured errors vs. bare HTTP 500). No annotations contradict these 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?

Well-structured with clear sections, front-loaded with purpose. However, the reliability section is somewhat verbose and includes CLI instructions that could be trimmed. Still, every sentence serves a 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?

Comprehensive coverage: workflow steps, constraints, error handling, fallback alternatives, and output schema existence. No gaps given the complexity and rich annotations/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 coverage is 100%, with descriptions for all parameters. The description adds context for object_key (requires get_upload_url) and elaborates on output_format options, providing integration guidance beyond the schema.

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

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

The description clearly states the tool offloads video transcoding to Botverse, with specific verb 'Offload a video transcode' and resource 'video'. It distinguishes from siblings like transcode_from_url and transcode_content by noting the upload requirement and 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 when to use this tool (requires get_upload_url first) and when not to (use transcode_from_url or transcode_content in sandboxed environments). Also provides fallback guidance and warns against writing own code, making it highly actionable.

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

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

Discloses internal steps (conversion, diarization, AI naming), cost, job_id return, consent requirement, and error handling beyond annotations.

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

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

Long but well-structured; front-loaded with main purpose, but could be more concise by trimming redundant fallback 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?

Covers all essential aspects: source types, process, options, consent, output, polling, cost, and fallback, making it complete for agent use.

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

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

Schema coverage is 100%; description adds context for options (e.g., attendees for speaker naming) and output formats, enhancing understanding.

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

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

The description clearly states the tool transcribes video/audio from a public URL into a speaker-labelled transcript, distinguishing it from siblings like transcribe_media and transcode_from_url.

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 (direct URLs, Dropbox/Google Drive/Box) and when-not-to-use (OneDrive/SharePoint) with alternatives, plus polling process and fallback 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?

Discloses behavioral traits: one-call pipeline, consent required, cost per hour, error handling (structured errors vs HTTP 500), and warns against writing own code as workaround. No contradiction with annotations.

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

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

The description is relatively long but each sentence serves a purpose: purpose, use case, consent, polling, cost, fallback. Could be slightly more concise, but well-structured and front-loaded.

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

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

Given 3 params, nested object, and output schema exists, the description covers usage, fallback, cost, consent, and next steps comprehensively. No need to explain return values as output schema is present.

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 is 3. Description adds value by explaining object_key source (get_upload_url), listing output_format options, and cross-referencing options from transcribe_from_url, providing context beyond schema.

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

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

The description clearly states it transcribes already-uploaded media files into speaker-labelled transcripts, distinguishes from transcribe_from_url, and specifies it handles local/large files (up to 2 GB).

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

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

Explicitly says when to use this tool vs transcribe_from_url ('Use for local files or files larger than a URL fetch allows'), provides consent requirement, polling instructions, cost, and fallback behaviors.

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