vap-e

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

No annotations are provided, so the description carries full responsibility for behavior. It mentions cost and tier requirements, but does not disclose whether the tool is synchronous, returns a task ID, modifies originals, or has other side effects. The safety profile and operational behavior are largely absent, making this a significant gap.

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 purpose, followed by capabilities and constraints. Every sentence earns its place without redundancy. The critical information (purpose, multi-image support, costing, tier) is packed efficiently.

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 the core purpose and parameters are fully documented in the schema. However, it lacks operational context like whether the operation is async, what the response format is, or how to retrieve results—especially relevant given sibling tools like get_task and list_tasks exist. This incomplete picture limits the agent's ability to invoke and integrate the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema—it reinforces the 'natural language' aspect of the prompt and implies multi-image works with additional_images, but does not elaborate on seed, aspect_ratio, or their interplay. No need to compensate further as schema is already descriptive.

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 edits images using AI with natural language prompts, and specifies single and multi-image editing. This distinguishes it from sibling tools like background_remove, inpaint, and generate_image by focusing on general prompt-based editing rather than a specialized 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?

It provides clear context that this tool is for natural language-driven image editing and supports multiple images, implying use cases. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5 but is still clear enough for an agent to decide.

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 adds useful behavioral context: 'Cost: $0.10' and 'Requires Tier 1+.' However, it does not explain return format, whether the operation is asynchronous, or any limitations, so it only partially carries 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 concise sentences, front-loaded with the core function and followed by cost and requirement. 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?

The tool has one param and no output schema, so the description should convey more. It includes cost, tier, and result state (transparency) but omits response format or asynchronous behavior, leaving the agent without full invocation context.

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

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

Schema coverage is 100% with media_url described as 'URL of the image to process.' The description adds no extra parameter meaning beyond the schema, so the baseline of 3 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 the tool's function with a specific verb and resource: 'Remove the background from an image, leaving only the subject with transparency.' This distinguishes it from sibling tools like inpaint or upscale.

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 usage via the action verb but provides no explicit when-to-use guidance, alternatives, or exclusions. It does not differentiate from potentially overlapping tools like inpaint or ai_edit.

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 transparency burden. It discloses the return values and implies a read-only check operation. While it doesn't mention side effects or auth, for a simple balance query this is adequate and adds useful context.

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

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

The description is a single, front-loaded sentence that conveys the action and output without wasted words. It is highly efficient and 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?

For a no-parameter tool with no output schema or annotations, the description is fully complete. It states what the tool does and what it returns, leaving no critical gaps 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 zero parameters, so the description doesn't need to explain any input schema fields. The baseline for zero parameters is 4, and the description doesn't need to compensate for parameter 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 checks a VAP account balance and specifies the return values (available, reserved, usable balances). This distinguishes it from sibling tools like generate_image or video_trim, which are unrelated operations.

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 doesn't explicitly state when to use this tool, but its unique function among siblings makes the usage context clear. However, it lacks explicit alternatives or exclusions, so usage is implied rather than stated.

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 responsibility for behavioral disclosure. It states 'Cost: $0.18' but does not clarify whether this is a flat fee or per image, nor how quality or num_outputs affect the total cost. It also does not explicitly state that the operation is non-destructive or read-only, leaving important behavioral gaps.

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 purpose, and contains no unnecessary words. Every word earns its place.

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

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

The tool is simple, but the description omits critical context such as whether the $0.18 is per image, how the parameters affect pricing, and what the estimate represents. Without annotations or an output schema, the description should explain the cost model more thoroughly to be 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 description coverage is 100%, so the parameters are well-documented in the schema. The description adds no additional meaning about how quality or num_outputs influence the cost estimate, 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 uses the specific verb 'Estimate' with the resource 'cost of an image generation', clearly distinguishing it from sibling tools like estimate_music_cost and estimate_video_cost by explicitly targeting image generation.

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

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

The phrase 'before executing' provides clear context for when to use the tool (prior to image generation). However, it does not explicitly mention alternatives or exclusions, so it falls short of full guidance.

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

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

With no annotations, the description carries the full burden. It only states 'Cost: $0.68', which is ambiguous and potentially misleading because the schema includes duration and audio_format parameters that likely affect the final cost. The description does not disclose how the estimate is computed, what is returned, or whether it is a read-only operation.

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 and front-loaded with the purpose. However, the second sentence 'Cost: $0.68' is incomplete and could mislead the agent into thinking the cost is flat, detracting from the structure.

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 has no output schema and no annotations. The description does not explain what the tool returns (e.g., a numeric estimate or a breakdown) or any potential limitations. While the tool is simple, the missing return value and cost-calculation caveats leave a notable gap.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (duration and audio_format). The main description adds only a base cost figure, which does not clarify how parameters influence the estimate. 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 estimates the cost of music generation, using a specific verb ('Estimate') and resource ('cost of music generation'). This distinguishes it from sibling tools like estimate_cost and estimate_video_cost.

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 context of music generation is implied, but there is no explicit guidance on when to use this tool versus alternatives such as estimate_cost or estimate_video_cost. The description does not mention exclusions or 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 states a fixed cost ($1.96) but does not explain how the cost is computed or how parameters (duration, resolution, audio) affect it, despite the schema noting a +33% cost for 1080p. This lack of disclosure could mislead users into thinking the cost is constant.

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

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

The description is very concise at two sentences. However, the cost figure is presented without context, which slightly reduces clarity, but overall it is efficiently worded.

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 fails to explain the tool's output (e.g., a numeric cost estimate) or how the base cost interacts with parameter choices. It also omits any mention of audio generation's impact on cost, leaving significant gaps for a simple estimate 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?

The schema provides thorough descriptions for all three parameters, including default values and the 1080p cost adjustment. The description adds no additional parameter detail, so with 100% schema coverage, the 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 'Estimate the cost of a video generation' with a specific verb and resource. It distinguishes from sibling tools like estimate_cost and estimate_music_cost by explicitly targeting video generation.

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

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

No usage guidelines are provided. The description does not mention when to prefer this over estimate_cost or estimate_music_cost, nor any exclusions or prerequisites. Users must infer usage from the tool name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states that the tool returns a task ID for async tracking and provides the exact cost ($0.18). This is valuable operational information beyond the input schema. However, it does not describe error conditions, rate limits, or how to retrieve the final image, which would make it even more transparent. Given no annotations, this is a solid 4.

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 extremely concise: two sentences that deliver the core purpose, model, return type, and cost. It is front-loaded with the main action first, and every word earns its place. No fluff or repetition.

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 low-to-medium complexity (3 params, one required, no output schema), the description adequately explains what the tool does and what it returns. It is missing a pointer to sibling tools like get_task or list_tasks for tracking, which would be a natural completion. However, it does cover the essential aspects for a user to successfully invoke and understand the flow.

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 covers 100% of parameters with detailed descriptions, including the aspect_ratio guidance. The description text itself does not add parameter semantics beyond what the schema already provides. Per the rubric, with high schema coverage, the baseline is 3, and the description neither detracts nor significantly enhances parameter meaning.

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 core function: "Generate an AI image from text prompt" using a specific model (VAP/Flux2 Pro). It explicitly mentions the return type (task ID for async tracking) and distinguishes itself from sibling tools like ai_edit or inpaint by focusing on text-to-image generation. The verb (Generate), resource (AI image), and scope (from text prompt) are all present.

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 the tool's primary use case (text-to-image generation) but does not mention when to use it versus alternatives like ai_edit or inpaint. There are no explicit exclusions or alternative tool references. The guidance is implied rather than spelled out, so it falls short of a 4 or 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?

With no annotations, the description carries the full burden. It discloses that the tool returns a task ID for async tracking and notes the cost ($0.68). It also warns about a common pitfall (including meta-text), which is valuable behavioral guidance.

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

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

The description is well-structured and front-loaded: purpose, cost, usage warning, and example. It is slightly longer than necessary but every part adds practical value, especially the example prompt.

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?

It covers async behavior, cost, and prompt formatting, which are key for a generation tool with 5 parameters and no output schema. It doesn't explicitly mention how to retrieve results, but the async task ID concept implies the use of get_task/list_tasks siblings.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds an example prompt and reminds users to describe genre, mood, instruments, etc., but it doesn't provide extra detail for parameters like duration or audio_format beyond what the schema already covers.

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 generates AI music from text using VAP, which is a specific verb+resource combination. It also distinguishes itself from sibling tools like generate_image and generate_video by focusing on music.

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 gives explicit instructions to send only the music description and not meta-text, and provides a recommended content structure with an example prompt. It doesn't explicitly contrast with alternatives, but the use case is clear enough.

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 key behaviors: returns a task ID for async tracking, costs $1.96, and strongly warns about prompt purity. It could mention that this is a creation (non-destructive) operation and how to retrieve results, but the disclosed traits are meaningful and useful.

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: a single sentence about purpose, a cost note, and an important usage note. It is front-loaded with the main purpose and contains no fluff. 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?

With no output schema, the description explains the return type (task ID). It covers cost and prompt guidance. However, it does not mention that the task ID can be used with get_task/list_tasks, nor does it mention cost variations for options like 1080p or audio, though these are present in the schema. Overall, it is fairly complete for a generation 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?

The schema description coverage is 100%, so the baseline is 3. The tool description's instruction about sending only the visual description is already present in the schema's prompt parameter description, so it adds no new parameter meaning. Cost information is not parameter-specific. Thus, description adds minimal 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?

The description clearly states the tool's function: 'Generate an AI video from text prompt using VAP (P-Video).' It uses a specific verb ('Generate') and resource ('AI video'), and distinguishes it from sibling tools like generate_image and generate_music. It also notes the async nature with task ID.

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

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

The description provides clear context for when to use the tool: for generating a video from a text prompt. It includes an important usage caution about sending only the visual description. However, it does not explicitly mention alternatives or when not to use it, such as for editing existing videos (video_trim/merge).

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 of disclosing behavior. It adds the useful detail that an output URL is returned when completed, but it does not mention other possible statuses (e.g., pending, failed) or error handling, leaving room for ambiguity.

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 that states the purpose and a key behavioral detail. No unnecessary words or repetition.

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 simple with one parameter and no output schema, so the description is mostly adequate. However, it omits what statuses can be returned when not completed and how this relates to the sibling 'get_task', which leaves a gap for an agent deciding how to poll or interpret 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?

Schema description coverage is 100% and already explains that operation_id is a UUID returned from an operation tool. The tool description adds no extra parameter semantics, so the baseline score of 3 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 the tool retrieves the status and result of an operation, and adds a specific detail about returning an output URL. However, it does not explicitly differentiate from the sibling 'get_task', so it misses a point for sibling distinction.

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?

No guidance is provided on when to use this tool versus alternatives like 'get_task' or 'list_tasks'. It does not mention prerequisites, polling behavior, or any exclusions.

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 of behavioral disclosure. It only states the success outcome (returns image URL when completed) but does not explain behavior when the task is still running, whether it blocks, returns error codes, or has any other side effects. This is a significant gap for a status-polling 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 remarkably concise, consisting of two short sentences that immediately state the purpose and a key result condition. No wasted words or padding.

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 simple with one well-documented parameter and no output schema, but the description lacks information about polling behavior, status values, and error handling. Given the existence of sibling tools like get_operation and generate_image, more context on usage flow would improve completeness.

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

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

The schema already fully describes the task_id parameter (100% coverage), including its source. The description adds no additional parameter context 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 verb 'Get' and the resource 'status and result of a generation task', plus what it returns when completed. It is specific to generation tasks, distinguishing it from sibling tools like get_operation, though not explicitly naming 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?

The description implies usage by mentioning 'generation task' and the schema clarifies task_id comes from generate_image, but it does not explicitly say when to use this instead of get_operation or list_tasks. No exclusions or alternative guidance is provided.

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 adds useful context by disclosing cost ($0.15) and tier requirement (Tier 1+), but fails to mention whether the operation is asynchronous, what the output/return value is, or any side effects on the original image. Cost and tier are valuable, but transparency is incomplete.

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 purpose, then cost and tier. No fluff. Every word earns its place, making it highly concise and 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?

The tool has no output schema and no annotations. The description does not explain what the tool returns (e.g., a new image URL) or whether it is asynchronous, even though sibling tools include get_operation and get_task, suggesting task-based flow. Cost and tier are noted, but critical operational context is missing for an agent to use 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?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond the schema's own descriptions; it only mentions cost and tier, which are not parameter-related. Thus, no extra 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?

The description clearly states the tool removes or replaces objects via AI inpainting, using a specific verb and resource. It distinguishes itself from siblings like background_remove and upscale by naming the technique (inpainting).

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 usage when the user wants to remove/replace objects but provides no explicit alternatives or when-not cases relative to sibling tools. It does not mention using background_remove for backgrounds or generate_image for new images, so guidance is only inferred.

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 must carry the burden. It clarifies the scope ('recent') and mentions the optional status filter, but does not disclose ordering, default limit behavior, or what constitutes 'recent.' While it implies read-only behavior, it is not explicit. The description adds some value beyond the name but lacks depth.

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, clear sentence with no redundant words. It front-loads the core action and scope, making it easy to scan and understand.

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 a simple list operation with two optional parameters. The description adequately conveys the core purpose but does not explain what a 'generation task' is or what the return value looks like. Given the absence of an output schema and presence of many sibling generation tools, a bit more context about task types or return structure would improve completeness.

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

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

Schema coverage is 100%, with both 'limit' and 'status' having descriptive text. The description's mention of 'optional status filter' reinforces the status parameter but does not add any new meaning beyond the schema. 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's function: 'List recent generation tasks with optional status filter.' The verb 'list' and resource 'generation tasks' are specific. It distinguishes from sibling get_task via the 'list' vs 'get' contrast, though not explicitly, so it falls 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention get_task for retrieving a single task or other list-like tools, and gives no exclusions or context about when not to use it.

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 for behavioral disclosure. It adds useful context about cost and authorization tier, but lacks details on output format, file limits, or asynchronous behavior. This is a minimal but non-zero disclosure.

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, well-structured sentence with three concise clauses: action, cost, and requirement. Every piece of information is essential and there is no wasted text.

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

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

For a simple tool with two thoroughly documented parameters, the description covers purpose, cost, and tier. However, it omits potential operational details like file size limits, supported image formats, or synchronous/asynchronous behavior, leaving some gaps for a complete understanding.

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 parameters is 100%, so the schema fully documents scale and media_url. The description does not add any additional parameter-specific meaning beyond the schema, warranting the baseline score of 3.

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

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

The description clearly states the tool's function: 'Upscale/enhance an image to higher resolution using AI.' It uses specific verbs and a resource, and is distinct from sibling tools like background_remove and inpaint.

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 prerequisites ('Cost: $0.15', 'Requires Tier 1+') but does not explicitly mention when to use this tool versus alternatives. Usage is implied by the purpose, but no exclusions or alternative recommendations are given.

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 must disclose behavioral traits. It does include useful operational details: cost ($0.05) and access level (Tier 1+). However, it does not mention whether the operation is asynchronous, how results are returned, or any format/limit constraints, leaving notable gaps.

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 extremely concise: two sentences, front-loaded with the purpose, followed by key cost and access details. Every sentence earns its place with no redundancy or filler.

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

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

For a simple one-parameter tool, the description covers the essential action and requirements. However, since there is no output schema and no mention of how to retrieve the merged video or whether the operation is asynchronous, it is not fully complete for an agent expecting to track the task.

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 fully describes the single parameter (media_urls) with 100% coverage, including playback order and minimum items. The description adds minimal extra meaning beyond the schema, so the 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 function: merging multiple video clips into one continuous video. It uses a specific verb ('Merge') and resource ('video clips'), and distinguishes itself from siblings like video_trim (which trims rather than merges).

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 usage when merging video clips is desired, but it does not explicitly explain when to use this tool over alternatives or provide exclusions. It does add practical context with cost and tier requirements, but lacks explicit guidance on prerequisites 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions cost and tier access, but omits critical details such as whether the operation is asynchronous, what the output format is, how the trimmed video is returned, or whether the original file is preserved.

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 extremely concise and front-loaded: two sentences that state the operation, cost, and access requirement without any filler. Every clause provides useful 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?

There is no output schema, so the description should explain what the tool returns or how results are retrieved. It does neither, nor does it mention asynchronous patterns or results handling, leaving a significant completeness gap for a tool with no annotations.

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 100% coverage with clear descriptions for all three parameters (media_url, start_time, end_time). The description adds no additional parameter semantics beyond echoing the 'time range' concept, so the baseline of 3 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 the operation with a specific verb and resource: 'Trim a video to a specific time range.' This distinguishes it from sibling tools like video_merge (merging) or generate_video, and the scope is well-defined.

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

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

There is no guidance on when to use this tool versus alternatives like video_merge or ai_edit. The description only states the operation and associated cost/tier, leaving usage context entirely implicit.

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