vap-e

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 cost ($0.15) and access requirements (Tier 1+), which are useful behavioral traits. However, it lacks details on rate limits, error handling, output format, or whether edits are destructive/reversible. For a mutation tool with no annotations, this is a moderate 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?

The description is extremely concise and front-loaded: three sentences that efficiently cover purpose, capabilities, cost, and requirements. Every sentence adds value with zero waste, making it easy for an AI agent to parse quickly.

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

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

Given no annotations and no output schema, the description provides basic purpose, cost, and requirements but lacks details on behavioral aspects like output format, error cases, or side effects. For a mutation tool with 5 parameters, this is minimally adequate but has clear gaps in 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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't clarify 'prompt' usage or 'additional_images' limits). Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Edit images using AI with natural language prompts.' It specifies the action (edit), resource (images), and method (AI with natural language prompts). However, it doesn't explicitly differentiate from sibling tools like 'inpaint' or 'background_remove', which might also edit images, so it doesn't reach the highest score.

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 some usage context: 'Supports single and multi-image editing. Cost: $0.15. Requires Tier 1+.' This implies when to use it (for AI-based image editing with cost and tier requirements) but doesn't explicitly state when not to use it or name alternatives among siblings like 'inpaint' or 'background_remove'. The guidance is implied rather than explicit.

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 adds valuable context beyond the input schema by specifying a cost ('Cost: $0.10') and access requirements ('Requires Tier 1+'), which are critical for usage decisions. However, it does not detail aspects like rate limits, error handling, or output format, leaving some 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 appropriately sized and front-loaded, consisting of two concise sentences that efficiently convey the tool's purpose, cost, and requirements without any wasted words. Every sentence earns its place by providing essential 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 moderate complexity (image processing with cost and tier requirements), no annotations, and no output schema, the description is fairly complete. It covers purpose, cost, and prerequisites, but lacks details on output (e.g., format of the processed image) and error cases, which could be important for an AI agent to handle 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 input schema has 100% description coverage, with the single parameter 'media_url' documented as 'URL of the image to process'. The description does not add any meaning beyond this, as it focuses on the tool's purpose and behavioral traits rather than parameter details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with a specific verb ('Remove') and resource ('background from an image'), and distinguishes it from siblings by specifying it leaves 'only the subject with transparency'. This is precise and differentiates it from tools like 'inpaint' or 'ai_edit' that might modify images differently.

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 this tool (for background removal from images) and includes prerequisites ('Requires Tier 1+'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for image processing but lacks comparison to tools like 'inpaint' or 'generate_image'.

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

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

With no annotations, the description carries full burden but only states it 'Returns available, reserved, and usable balances.' It doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether it's read-only (implied but not explicit). This is inadequate for a tool with zero annotation coverage, as critical operational details are missing.

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 with zero waste. The first sentence states the purpose, and the second specifies the return values. Every word earns its place, making it easy for an agent to parse quickly.

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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and what it returns, but lacks context on usage, behavior, or integration with siblings. For a balance-checking tool, more guidance on authentication or error handling would improve completeness, but it's not entirely incomplete.

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%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the return values instead. This meets expectations for a parameterless tool, though it doesn't add extra semantic value 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: 'Check VAP account balance' specifies the verb ('Check') and resource ('VAP account balance'). It distinguishes from siblings by focusing on balance retrieval rather than editing, generating, or managing tasks. However, it doesn't explicitly differentiate from potential balance-related siblings, which prevents a perfect score.

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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), timing (e.g., before cost estimation), or comparisons to other tools (e.g., 'estimate_cost' for projections). This leaves the agent without context for selection, though the purpose is straightforward.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the cost ($0.18) which is useful, but doesn't specify if this is per image, per request, or how it varies with parameters. It also doesn't mention authentication needs, rate limits, or what the actual output format will be.

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 with two short sentences that communicate the core purpose and cost information. However, the cost information could be better integrated with parameter context rather than presented as a standalone fact.

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 cost estimation tool with no annotations and no output schema, the description provides basic purpose and cost information but lacks details about what the actual return value will contain, how the cost calculation works with different parameter combinations, or any error conditions.

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 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional value.

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: estimating cost before image generation execution. It specifies the resource (image generation) and verb (estimate cost), but doesn't explicitly differentiate from sibling tools like 'estimate_music_cost' or 'estimate_video_cost' beyond the implied context of images.

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 context ('before executing') which suggests this should be used prior to actual generation tools like 'generate_image'. However, it doesn't provide explicit guidance on when to use this versus alternatives or any prerequisites for usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context by stating a fixed cost ('$0.68 (Suno V5)') and noting that 'WAV adds +$0.10', which hints at pricing behavior. However, it lacks details on rate limits, authentication needs, or error handling, leaving gaps for a mutation-related tool (cost estimation often implies financial implications).

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, consisting of just one sentence that directly states the tool's purpose and key cost information. There is zero waste, and every word earns its place by providing essential context 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 tool's moderate complexity (cost estimation with financial implications), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and cost structure but lacks details on return values, error cases, or integration with sibling tools like 'generate_music'. This leaves the agent with incomplete contextual 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?

The input schema has 100% description coverage, with clear documentation for both parameters ('duration' and 'audio_format'). The description adds marginal value by reinforcing the cost implication of the 'audio_format' parameter ('WAV adds +$0.10'), but doesn't provide additional syntax or meaning beyond what the schema already covers. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Estimate the cost of music generation.' It specifies the verb ('estimate') and resource ('cost of music generation'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'estimate_cost' or 'estimate_video_cost', which prevents a perfect score.

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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'estimate_cost' (which might be more general) or 'generate_music' (which might be the actual generation tool), nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the cost ($1.96) without explaining what 'P-Video' means, whether this is a read-only estimation or has side effects, if it requires authentication, or how pricing might vary. For a cost estimation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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 - just one sentence with a price example. While efficient, it might be overly terse given the lack of behavioral context and usage guidance. Every word earns its place, but more information would be helpful for this type of 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?

For a cost estimation tool with 3 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what the tool returns (just a cost amount? breakdown?), how the $1.96 relates to parameter combinations, what 'P-Video' means, or any error conditions. The schema covers parameters well, but the overall context for using this tool is incomplete.

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 description provides no parameter information beyond the cost example. However, the input schema has 100% description coverage with clear documentation for all three parameters (duration, resolution, generate_audio), including default values and cost implications for resolution. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description adds no value beyond what's already in 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: estimating video generation costs. It specifies the resource (video generation) and verb (estimate cost), and includes a concrete price example. However, it doesn't explicitly differentiate from sibling tools like 'estimate_cost' or 'estimate_music_cost' which serve similar estimation purposes.

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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'estimate_cost' (general cost estimation), 'estimate_music_cost' (specific to music), or 'generate_video' (actual generation tool). There's no context about prerequisites, timing, or comparison with other estimation tools.

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

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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses the async nature ('Returns a task ID for async tracking'), cost implications ('Cost: $0.18'), and hints at quality cost scaling ('high costs 1.5x' via schema). It doesn't cover rate limits or auth needs, but provides key operational 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?

The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral details (async tracking and cost) in a second sentence. Every sentence earns its place with no wasted words, making it 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?

Given the complexity of an AI image generation tool with no annotations and no output schema, the description is mostly complete: it covers purpose, async behavior, and cost. However, it lacks details on error handling, output format (e.g., image URL or data), or integration with sibling tools like get_task for tracking, leaving minor 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 description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining prompt best practices or aspect ratio interactions. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Generate an AI image'), the resource ('from text prompt'), and the technology used ('using VAP (Flux2 Pro)'), which distinguishes it from sibling tools like generate_music or generate_video that handle different media types.

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 through the mention of 'Cost: $0.18' and the async nature, suggesting it's for image generation when budget and async processing are acceptable. However, it doesn't explicitly state when to use this vs. alternatives like ai_edit or inpaint for image modifications, or provide clear 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively reveals key traits: it's a paid service ($0.68 cost), returns a task ID for async tracking, has specific input constraints (send ONLY music description), and provides formatting guidance. It doesn't mention rate limits or authentication needs, but covers the essential transactional behavior.

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

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

The description is well-structured and front-loaded with the core functionality, followed by important constraints, cost, and a helpful example. Every sentence serves a clear purpose with zero waste, making it easy to scan and understand quickly.

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 tool with no annotations and no output schema, the description does an excellent job covering the essential context: purpose, cost, async behavior, input constraints, and example. It could slightly improve by mentioning the relationship with get_task for tracking results, but it's largely complete given the complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by emphasizing the prompt parameter's importance and providing an example, but doesn't add significant semantic meaning beyond what the schema provides for other parameters like duration or audio_format.

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 descriptions using VAP (Suno V5), specifying the exact action and resource. It distinguishes itself from sibling tools like generate_image and generate_video by focusing specifically on music 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 description provides clear context for when to use this tool (to generate music from text descriptions) and includes an example prompt. However, it doesn't explicitly mention when NOT to use it or compare it to alternatives like estimate_music_cost or get_task for tracking, though the async nature is noted.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's an async operation ('Returns a task ID for async tracking'), has a monetary cost ('Cost: $1.96'), and provides important input constraints. However, it doesn't mention rate limits, authentication needs, or error conditions.

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 perfectly front-loaded and concise: first sentence states purpose, second provides behavioral context (async + cost), third gives critical usage instruction. Every sentence earns its place with zero waste 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?

For a complex video generation tool with 6 parameters and no output schema, the description provides good context about async nature, cost, and input constraints. However, it doesn't explain what the task ID can be used for (presumably with get_task) or mention the sibling tools that might be relevant for follow-up operations.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds some value by emphasizing the 'prompt' parameter's constraints, but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verb ('Generate') and resource ('AI video from text prompt using VAP'), and distinguishes it from siblings like generate_image or generate_music by specifying video generation. It provides the exact service being offered.

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

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

The description provides explicit usage guidelines: 'Send ONLY the video description. Do NOT include any instructions, guidelines, or meta-text. Just the pure visual description.' This tells the agent exactly when and how to use this tool versus alternatives, with clear constraints on input format.

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 that it returns 'output URL when completed,' adding useful behavioral context about the result. However, it misses details like error handling, polling behavior, or rate limits, leaving gaps in transparency for a status-checking 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 two concise sentences with zero waste: it states the purpose and a key behavioral detail. It is front-loaded and efficiently structured, making it easy to parse without unnecessary elaboration.

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

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

Given no annotations and no output schema, the description is moderately complete. It covers the basic purpose and a result detail, but for a tool that retrieves operation status, it lacks information on response format, error cases, or dependencies, leaving room for improvement in 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 description coverage is 100%, so the schema fully documents the 'operation_id' parameter. The description adds no additional meaning beyond implying the ID comes from 'an operation tool,' which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.

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: 'Get the status and result of an operation.' It specifies the verb ('Get') and resource ('operation'), but does not distinguish it from sibling tools like 'get_task' or 'list_tasks', which also retrieve information. This makes it clear but not fully differentiated.

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 minimal guidance: it implies usage when checking on an operation's completion, but offers no explicit when-to-use rules, alternatives (e.g., vs. 'get_task'), or exclusions. Without context on when to choose this over similar tools, it lacks actionable 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 provided, the description carries the full burden. It discloses that the tool returns status/result and an image URL upon completion, which is useful behavioral context. However, it lacks details on error handling, polling behavior, or what happens for non-completed tasks, leaving gaps for a mutation-checking 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 two concise sentences with zero waste. The first sentence states the core purpose, and the second adds key behavioral detail (image URL return). It's front-loaded and efficiently 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 no annotations and no output schema, the description is moderately complete for a simple lookup tool. It covers the purpose and key return behavior but lacks details on response format for non-image tasks, error cases, or status types, which could be important 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 description coverage is 100%, with the parameter 'task_id' well-documented in the schema. The description adds minimal value by referencing 'task_id returned from generate_image', which slightly clarifies the parameter's origin but doesn't provide additional semantics beyond what the schema already states.

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 specific action ('Get the status and result') and resource ('a generation task'), distinguishing it from siblings like 'generate_image' (which creates tasks) and 'list_tasks' (which lists multiple tasks). It precisely defines the tool's scope.

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

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

The description implies usage context by mentioning 'Returns image URL when completed' and referencing 'task_id returned from generate_image', suggesting it's used to check on tasks created by generation tools. However, it doesn't explicitly state when NOT to use it or name alternatives like 'list_tasks' for broader task queries.

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 and adds valuable behavioral context: it discloses the cost ('$0.15') and access requirements ('Requires Tier 1+'), which are not inferable from the schema. However, it does not mention other potential traits like rate limits, response format, or error conditions.

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: the first sentence states the core purpose, and the second adds critical behavioral details (cost and tier). Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly.

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 moderate complexity (AI-based image editing), no annotations, and no output schema, the description is reasonably complete: it covers purpose, cost, and access. However, it lacks details on output (e.g., what is returned, such as a new image URL) and error handling, which would be helpful for an agent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description does not add any meaning beyond the schema (e.g., it doesn't explain parameter interactions or provide examples). Baseline 3 is appropriate as the schema handles the heavy lifting.

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 specific action ('Remove or replace objects'), the resource ('image'), and the method ('using AI inpainting'), which distinguishes it from sibling tools like 'background_remove' (more specific removal) or 'ai_edit' (broader editing). It goes beyond just restating the name 'inpaint' by explaining the AI-based object manipulation.

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 this tool ('Remove or replace objects in an image'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'background_remove' for simpler removals or 'ai_edit' for other edits). The cost and tier requirement offer practical usage constraints.

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 full burden. It mentions 'recent' tasks but doesn't define recency, disclose pagination behavior, rate limits, or authentication requirements. For a list operation with no annotations, this leaves significant 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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes the key optional feature. 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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'recent' means, how tasks are ordered, what fields are returned, or error conditions. For a list tool with multiple sibling tools, more context is needed to guide proper usage.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal value by mentioning the optional status filter, but doesn't provide additional context beyond what the schema already specifies. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('List') and resource ('recent generation tasks') with an optional filter. It's specific about what the tool does, though it doesn't explicitly distinguish from sibling tools like 'get_task' which likely retrieves a single task.

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 on when to use this tool versus alternatives like 'get_task' or 'get_operation'. The description mentions an optional status filter but doesn't provide context on when filtering is appropriate or what 'recent' means relative to other tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about cost and tier requirements, which are not in the schema, but does not cover other behavioral traits such as rate limits, response format, or error handling. The description does not contradict any 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 front-loaded with the core purpose in the first clause, followed by cost and prerequisites. It uses only two sentences with zero waste, making it highly efficient and easy to parse for an AI agent.

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 moderate complexity (AI-based upscaling with cost and tier requirements), no annotations, and no output schema, the description is adequate but has gaps. It covers purpose, cost, and prerequisites but lacks details on output (e.g., format, quality), error cases, or integration with sibling tools like 'estimate_cost'. It meets minimum viability but could be more 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 schema already documents both parameters ('scale' and 'media_url') with descriptions. The description does not add meaning beyond what the schema provides, such as details on URL formats or scale implications. Baseline 3 is appropriate when the schema handles 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's purpose with a specific verb ('upscale/enhance') and resource ('an image'), specifying the outcome ('to higher resolution using AI'). It distinguishes from siblings like 'generate_image' (creation) or 'background_remove' (editing) by focusing on resolution enhancement.

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 usage with cost ('$0.15') and prerequisites ('Requires Tier 1+'), but does not explicitly state when to use this tool versus alternatives like 'ai_edit' or 'inpaint' for other image modifications. It implies usage for resolution enhancement but lacks explicit exclusions or comparisons.

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 adds useful context beyond the schema by stating the cost ('$0.05') and access requirement ('Requires Tier 1+'), but it does not cover other important behavioral aspects such as processing time, output format, file size limits, or error handling.

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, consisting of only two sentences that efficiently convey the core purpose, cost, and requirement. Every word serves a clear purpose with no redundancy or unnecessary elaboration.

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 complexity of a video merging tool with no annotations and no output schema, the description is moderately complete. It covers cost and access requirements but lacks details on output behavior (e.g., format, quality), error cases, or limitations, which are important for such an 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?

Schema description coverage is 100%, so the schema already documents the single parameter 'media_urls' with details like type, minItems, and order. The description does not add any parameter-specific information beyond what the schema provides, meeting the baseline for high coverage.

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

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

The description clearly states the specific action ('merge multiple video clips') and the resource ('into one continuous video'), distinguishing it from sibling tools like video_trim (which trims rather than merges) and generate_video (which creates new content). The purpose is unambiguous and 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?

The description provides explicit context for usage with 'Requires Tier 1+', indicating a prerequisite. However, it does not specify when to use this tool versus alternatives like video_trim or generate_video, nor does it mention exclusions or direct comparisons to sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully adds important context beyond the basic function: it discloses the monetary cost ($0.05) and access requirements (Tier 1+), which are crucial for an agent to understand usage constraints. However, it doesn't mention potential side effects like whether the original video is modified or a new file is created.

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 perfectly concise with just two sentences that each earn their place: the first states the core function, and the second provides essential usage constraints. There's zero wasted language, and the most critical information (the action) 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?

For a mutation tool with no annotations and no output schema, the description does well by covering the core function, cost, and access requirements. However, it doesn't describe what the tool returns (e.g., a new video URL, operation ID) or potential error conditions, leaving some gaps in completeness for a tool that modifies media.

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 schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where the schema does the heavy lifting 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 specific action ('Trim a video') and the resource ('video'), distinguishing it from siblings like video_merge or generate_video. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

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 by mentioning the required 'Tier 1+' access level and the cost implication, which helps the agent understand prerequisites. However, it doesn't differentiate when to choose this tool over alternatives like video_merge or ai_edit for similar video editing tasks.

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