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 that the tool 'Returns a batch ID for polling,' which indicates an asynchronous operation, but doesn't specify polling frequency, timeout, error handling, or what happens to submitted images. For a batch processing tool with no annotation coverage, this leaves significant gaps in understanding its 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 extremely concise with just two sentences that directly state the action and outcome. Every word earns its place, and it's front-loaded with the core purpose. There's no unnecessary elaboration 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 complexity of batch processing (asynchronous operation, multiple images) and the absence of both annotations and output schema, the description is insufficient. It doesn't explain what vectorization entails, what format the results will be in, how to retrieve them using the batch ID, or any limitations beyond the schema's 50-image maximum. For a tool with no structured behavioral hints, this leaves too many unknowns.

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 'images' parameter fully documented in the schema. The description doesn't add any parameter details beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. No additional semantic context is provided about image formats, size limits, or processing order.

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: 'Submit multiple images for batch vectorization.' It specifies the verb ('Submit'), resource ('multiple images'), and operation ('batch vectorization'). However, it doesn't explicitly differentiate from the sibling 'vectorize' tool, which appears to be a single-image version.

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 the sibling 'vectorize' tool for single images or explain why batch processing is preferable for multiple images. There's no context about prerequisites, limitations, or typical use cases.

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. While it indicates this is a read operation ('Check'), it doesn't describe what the status check entails—such as whether it returns progress percentages, error messages, completion timestamps, or if it has rate limits or authentication requirements. This leaves significant gaps for a tool that likely interacts with asynchronous jobs.

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 zero wasted words. It is front-loaded with the core purpose and appropriately sized for a simple tool, 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 (checking job status) and the absence of both annotations and an output schema, the description is minimally adequate but incomplete. It covers the basic purpose but fails to address behavioral aspects like return values or error handling, which are crucial for status-checking tools. The high schema coverage helps, but gaps remain.

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%, with the single parameter 'batch_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify the format of the batch ID or where to obtain it). Since the schema does the heavy lifting, 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 action ('Check the status') and the resource ('batch vectorization job'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'list_vectorizations' or 'batch_vectorize' that might also provide status information, 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., that a batch job must already exist), nor does it compare it to sibling tools like 'list_vectorizations' that might offer similar functionality. The agent must infer usage from context alone.

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 states this lists vectorizations, implying a read-only operation, but doesn't clarify aspects like pagination, rate limits, error handling, or what 'recent' means (e.g., time frame, limit). This leaves gaps in understanding how the tool behaves beyond basic functionality.

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 wasted words. It front-loads the core action ('List recent vectorizations') and efficiently adds scope ('for the authenticated user'). Every part of the sentence contributes directly to understanding the tool's purpose.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior (e.g., output format, what 'recent' entails) that would help an agent use it effectively. Without annotations or output schema, more context on results 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, avoiding redundancy. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce unnecessary complexity.

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 action ('List') and resource ('recent vectorizations'), with the scope 'for the authenticated user' providing additional context. It distinguishes itself from siblings like 'vectorize' or 'batch_vectorize' by focusing on listing rather than creating vectorizations. However, it doesn't explicitly differentiate from 'get_batch_status', which might also list vectorizations but with a different focus.

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 needing to view recent vectorizations, but provides no explicit guidance on when to use this versus alternatives like 'get_batch_status' (which might list batch-specific vectorizations) or other siblings. It mentions 'authenticated user' as a prerequisite, but lacks details on timing, frequency, or exclusion criteria.

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. While it states what the tool does ('Change colors'), it lacks critical behavioral details: whether the operation is destructive to the original SVG, what format the output takes, whether there are limitations on color mapping (e.g., partial replacements), or error handling for invalid colors. This leaves significant gaps in understanding how the tool behaves in practice.

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 two sentences that directly state the tool's function and required inputs. Every word earns its place with zero redundancy or unnecessary elaboration, making it easy for an agent to parse quickly while covering the essentials.

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 (color manipulation in structured data) and the absence of both annotations and an output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., modified SVG string, success status), behavioral constraints, or how it interacts with sibling tools. For a mutation tool with no structured safety or output information, more descriptive context is needed to guide effective use.

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

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

Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'a mapping of old colors to new colors,' which echoes the schema's description of 'color_map.' It doesn't provide additional context about color formats, handling of CSS color names, or edge cases, so it meets the baseline for high schema coverage without enhancing parameter understanding.

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

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

The description clearly states the verb ('Change colors') and resource ('in an SVG'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'simplify_svg' or 'vectorize' by focusing specifically on color modification rather than structural changes or format conversion. However, it doesn't specify whether this applies to all color references or just certain types (e.g., fill vs stroke), 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 whether this should be used before or after other SVG manipulation tools like 'simplify_svg' or 'vectorize', nor does it specify use cases or prerequisites. The agent must infer usage context solely from the tool name and description without explicit 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 but offers minimal behavioral insight. It implies a mutation (removing background) but doesn't disclose permissions needed, whether the operation is reversible, rate limits, or what the output looks like (e.g., modified SVG string). This leaves significant gaps for a tool that modifies content.

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 wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.

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

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

Given the tool's complexity (mutating SVG content), lack of annotations, and no output schema, the description is insufficient. It doesn't explain the return value (e.g., modified SVG string or error details), behavioral traits like idempotency, or edge cases (e.g., handling transparent backgrounds). For a mutation tool with no structured support, more context is needed.

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 ('svg' and 'image') adequately. The description adds marginal value by implying the raster image is used as a reference for background removal, but doesn't provide additional syntax, format details, or constraints beyond what the schema 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 action ('Remove the background') and the resource ('from an SVG'), specifying the method ('using the original raster image for reference'). It distinguishes from siblings like 'recolor_svg' or 'simplify_svg' by focusing on background removal, but doesn't explicitly differentiate from all siblings (e.g., 'vectorize' might also involve background handling).

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. The description mentions using the raster image as reference, but doesn't specify prerequisites, when-not-to-use scenarios, or compare to sibling tools like 'simplify_svg' or 'vectorize' that might offer overlapping functionality.

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 states the tool reduces colors via quantization, implying a transformation, but doesn't cover critical aspects like whether the operation is destructive, if it requires specific permissions, rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this is insufficient.

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 that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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?

Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral traits, output format, error handling, and differentiation from siblings. For a tool that modifies SVG content, more context is needed to ensure 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%, with clear descriptions for both parameters ('svg' as SVG content string and 'max_colors' with range 1-256). The description adds no additional parameter semantics beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate when the schema handles documentation adequately.

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: 'Reduce the number of colors in an SVG by quantizing the palette.' This specifies the action (reduce colors via quantization) and the resource (SVG). However, it doesn't explicitly differentiate from sibling tools like 'recolor_svg' or 'vectorize', which may have overlapping functionality, 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'recolor_svg' or 'vectorize', nor does it specify scenarios or prerequisites for use. This leaves the agent without context for tool selection.

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 states the conversion action but lacks details on performance traits (e.g., processing time, rate limits), error handling, or output characteristics (e.g., SVG quality, size changes). The mention of 'clean SVG vector' is vague and doesn't clarify what 'clean' entails.

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 that front-loads the core purpose ('Convert a raster image...') and includes essential details (formats, encoding). There is no wasted text, and it's appropriately sized for a tool with one parameter and no annotations.

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

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

Given the tool's complexity (conversion operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., SVG structure, potential metadata), error cases, or behavioral constraints. For a mutation tool with zero annotation coverage, more context is needed to guide effective use.

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

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

Schema description coverage is 100%, so the schema fully documents the single parameter 'image'. The description adds minimal value by reiterating 'base64-encoded image' but doesn't provide additional semantics beyond what's in the schema (e.g., image size limits, supported color modes). Baseline 3 is appropriate as 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: 'Convert a raster image (PNG, JPG, WebP) to a clean SVG vector.' It specifies the verb (convert), input resource (raster image with formats), and output (SVG vector). However, it doesn't explicitly differentiate from sibling tools like 'recolor_svg' or 'simplify_svg', which also work with SVGs but perform different 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 provides no guidance on when to use this tool versus alternatives. It mentions the input format and encoding but doesn't indicate scenarios where vectorization is preferred over other SVG-related tools like 'recolor_svg' or 'simplify_svg', nor does it specify prerequisites or exclusions.

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