Future Video Studio

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

Annotations already disclose the destructive nature (destructiveHint=true). The description adds context beyond this by specifying the two valid identifiers and that cancel_url comes from fvs_submit_render, which is useful for the agent. It does not detail side effects or error conditions, but the annotation coverage lowers the bar.

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 short sentences, front-loaded with the primary action. The second sentence provides essential parameter guidance without any 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 2-parameter cancel tool with an output schema, the description is largely complete. It covers how to identify the job and references the submission tool for obtaining cancel_url. It does not address edge cases (e.g., both parameters provided, already-cancelled jobs), but these are not critical for basic 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?

With 0% schema description coverage, the description carries the burden for parameter meaning. It explains that cancel_url and project_id are alternatives and that cancel_url is the full URL returned by fvs_submit_render. This adds meaningful semantics beyond the raw schema, though it omits details like project_id format or behavior when both are provided.

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 states the exact action ('Cancel a Future Video Studio render job') using a specific verb and resource. This clearly distinguishes it from sibling tools like fvs_get_render_status or fvs_download_final_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?

The description explains how to invoke the tool by providing either project_id or the full cancel_url from fvs_submit_render, giving clear context and a prerequisite. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.

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

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

The description discloses key behaviors beyond annotations: the backend returns HTTP 402 payment details (payment_url, status_url, claim_token, etc.), requires an external payment step via Link's MPP flow, and disallows local file uploads. This adds meaningful context to the non-idempotent, non-read-only 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 three sentences in a logical order: purpose, payment flow, and asset constraint. Every sentence adds value with no repetition or fluff, and the key purpose is 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 the presence of an output schema and annotations, the description adequately covers the workflow: creation, payment, polling, and asset handling. It references the necessary sibling tool for follow-up and does not need to explain return values. Slightly more detail on when to use this vs. fvs_submit_render would make it 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?

While the schema already provides 100% parameter coverage, the description adds important semantics for upload_urls: local uploads are not supported and public HTTPS URLs must be used for assets. This clarifies the parameter's purpose beyond the schema description.

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

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

The description clearly states the tool creates a 'no-account Link payment quote for an FVS render,' using a specific verb and resource. It also differentiates from sibling tools like fvs_submit_render by focusing on the payment quote aspect and mentions polling with fvs_get_paid_render_status.

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

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

It provides explicit guidance: pay the returned payment_url and poll with fvs_get_paid_render_status, and use public HTTPS upload_urls since local file uploads are not available. It lacks an explicit contrast with fvs_submit_render but gives clear usage 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?

Discloses unauthenticated HTTPS GET, local file write, parent directories created, no overwrite unless flag, 600s timeout, URL expiry, and security caution about arbitrary URLs. Complements the destructiveHint annotation by explaining exactly what may be overwritten. 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?

Structured in three concise sections: operation, usage, and side effects. Every sentence adds context without redundancy, and the length is appropriate for a file-download tool with filesystem side effects.

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

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

Covers prerequisites, side effects, timeout, absence of authentication requirements, remote-state non-modification, URL expiration, and local overwrite semantics. With an output schema present, no need to describe return values; the description is sufficient for safe invocation.

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

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

Schema has 100% coverage with detailed descriptions for all three parameters. The description adds HTTP GET behavior, security warning about untrusted URLs, and file-size/time expectations, going beyond what the schema already provides.

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

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

The description specifies verb 'download', resource 'completed Future Video Studio final render URL', and target 'local file'. It clearly separates this from sibling tools that submit, cancel, or retrieve status.

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

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

Explicitly instructs to use only after fvs_get_render_status or fvs_get_paid_render_status returns a final_video_url. Also lists exclusions: does not call FVS Agent API, spend credits, cancel jobs, or modify remote state.

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, indicating a safe operation. The description adds that it returns a minimal request, but this is mainly a restatement of purpose rather than disclosing additional behavioral traits like side-effects or response format. With annotations carrying the safety profile, a score of 3 is appropriate.

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, front-loaded sentence with no wasted words. It clearly conveys the tool's purpose and intended use.

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 tool is extremely simple, has no parameters, and an output schema exists. The description, combined with annotations and output schema, provides a complete picture. No additional context is needed for an agent to invoke it 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?

The tool has 0 parameters, and schema description coverage is 100% (vacuously). The description mentions 'adapt' but adds no parameter-specific details since none exist. Per the rubric, 0 params earns a baseline of 4.

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 "Return" and names the resource "minimal scene render request", making it clear this tool provides a template. It distinguishes from siblings like fvs_submit_render or fvs_cancel_render by emphasizing it is an example that agents can adapt, not an actual operation.

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

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

The description implies when to use it: when an agent needs a starting point for creating a render request. It provides clear context but does not explicitly state exclusions or alternatives, such as 'use this when you need a template rather than submitting a real render'.

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. Description adds the 'no-account' characteristic and linkage to creation, but no additional behavioral details such as polling behavior or response format (output schema covers that). 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?

Two sentences, minimal waste, front-loaded with the core purpose and usage pattern.

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 describe safety/idempotency, the description is sufficient for selection and invocation. It would benefit from an explicit mention of how this differs from the general fvs_get_render_status, but the 'no-account' qualifier provides enough context.

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

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

Schema has 0% description coverage, but the description compensates by explaining that status_url alone or quote_id+claim_token pair can be used. This gives functional meaning to the parameters beyond their names and nullability.

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 a no-account paid render, referencing the creation tool fvs_create_paid_render_quote. This distinguishes it from the sibling fvs_get_render_status by scope (no-account paid).

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

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

Specifies the intended use case ('no-account paid render') and the two alternative input modes, but doesn't explicitly contrast with fvs_get_render_status or state when not to use it. Context is clear but not fully complete.

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, covering the safety profile. The description adds context that either project_id or the status_url returned by fvs_submit_render can be used, which clarifies input behavior. It does not describe the response format or polling behavior, but the output schema and annotations reduce the burden.

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 sentences with no filler. The first sentence states the purpose, and the second gives essential input instructions. It is front-loaded, concise, and every sentence earns its place.

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

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

For a simple status-check tool with annotations and an output schema, the description covers the core purpose and parameter selection adequately. It is missing an explicit pointer to fvs_get_paid_render_status for paid render jobs, which would make it fully complete. However, the provided context is sufficient for most 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 description coverage is 0%, so the description must compensate for the schema's minimal parameter info. It names both parameters and clarifies they are alternatives ('either ... or'), adding meaning the schema lacks. It also indicates the provenance of status_url, though it does not give format or precedence details, so not a 5.

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

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

The description uses a specific verb 'Check' and identifies the resource as 'a Future Video Studio render job', clearly stating the function. It also references fvs_submit_render for the status_url, which helps position the tool. However, it does not explicitly distinguish from the sibling fvs_get_paid_render_status, so it stops short of a 5.

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 the tool is used after submitting a render by mentioning fvs_submit_render, but it does not state when to use this tool instead of alternatives like fvs_get_paid_render_status. It provides input instructions ('Provide either project_id or the full status_url') but no explicit when-to-use or when-not-to-use guidance. This is implied usage, not explicit differentiation.

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, idempotentHint, and destructiveHint. The description adds valuable context by emphasizing 'without creating a render' and 'before spending credits,' reinforcing the non-destructive, read-only nature. 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?

Two concise sentences front-load the core action and provide clear use-case examples. Every word earns its place with no redundancy.

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

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

For a simple widget-opening tool with an output schema, the description covers the key context and use cases well. However, it omits parameter semantics, which is a minor gap given the simple nature of the operation.

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 has 5 optional parameters with zero descriptions, and the description only mentions pasting a status URL without mapping to the status_url parameter or explaining other parameters. The description fails to compensate for the complete lack of schema documentation.

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

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

The description clearly states the tool opens the Future Video Studio ChatGPT app widget without creating a render. It names the specific resource (FVS app widget) and distinguishes it from render-related operations in sibling tools.

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

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

Explicitly lists when to use: when user wants the FVS app panel, paste a status URL, or prepare a render interactively before spending credits. This provides clear context and implicitly excludes render creation/cancellation/download scenarios.

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 disclose destructiveHint=true, so the description does not need to restate that. It adds valuable context: credential lookup order (connector header, marketplace mapping, or FVS_AGENT_API_KEY) and the strict filename-matching rule between upload_urls and request.assets. These go beyond annotation flags.

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, front-loaded with the primary purpose, and every sentence covers a necessary point: what the tool does, how to pass payload and assets, and where credentials come from. 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?

The description covers submission, reference asset handling, and authentication—enough to invoke the tool correctly. Since an output schema exists, return values need no description. It does not mention checking status later, but that is covered by sibling tools and is not essential for submission.

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 descriptions for request and upload_urls are already detailed and include the filename-matching requirement. The description repeats this relationship but does not explain poll_until_complete, the third parameter. With 67% schema coverage, the prose adds minimal extra value over 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?

Description uses 'Submit a Future Video Studio render job through the FVS Agent API'—a specific verb+resource that clearly distinguishes it from siblings like fvs_cancel_render, fvs_get_render_status, and fvs_download_final_video. The scope is unambiguous.

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

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

The description gives clear context for when to use it (to submit a render job) and provides operational how-to details, but it does not explicitly mention alternatives such as checking status with fvs_get_render_status. Missing explicit when-not-to-use guidance.

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