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

With no annotations, the description must disclose behavioral traits. It does not mention that this modifies the image, whether it's additive (overlay) or destructive, if undo is possible, or what the response contains. It only states the action, leaving the agent to infer side effects. Sibling tools like undo suggest reversibility, but that's not stated.

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?

A single, clear sentence with no filler. It is appropriately concise for a simple operation, though it lacks the nuance that could be packed into a few more words.

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

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

Given the 8 parameters, the existence of an output schema, and numerous sibling tools, the description is too minimal. It doesn't explain when to use an arrow versus other annotations, what the effect on the image is, or any required preconditions. The schema covers parameters well, but the high-level context for correct invocation is missing.

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. The description adds no information about parameters. Baseline is 3, and the description neither improves nor worsens the situation.

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 'Draw an arrow on the image' clearly states the verb (draw) and resource (arrow on image). It is specific enough to distinguish from e.g., add_box or add_text, though it doesn't explicitly call out the arrowhead feature that distinguishes it from add_line.

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 add_line or add_box. It doesn't mention use cases, prerequisites, or why an arrow would be preferred. The description simply states the action without context for 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?

With no annotations present, the description carries the full burden of behavioral disclosure. It only states the action 'add a border' but does not say whether the image is modified in-place, whether a new image is returned, whether the operation is reversible, or if any permissions are required. For a mutating tool, this leaves key behavioral traits undisclosed.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's core 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?

The description is too sparse for a mutation tool without annotations. It doesn't explain what happens to the original image or what the tool returns, and while an output schema exists, the description itself lacks the behavioral context needed for an agent to invoke it confidently.

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 color, width, and image_id. The description adds no extra parameter meaning, but the schema already provides sufficient detail, 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 states a clear verb and resource: 'Add a border around the entire image.' The phrase 'entire image' distinguishes it from sibling annotation tools like add_box or add_circle, which typically target local regions. However, it does not explicitly name alternatives or contrast with them, so a small inference is required.

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 no explicit guidance on when to use this tool versus its siblings, nor does it mention prerequisites such as loading an image first. The only implied context is the tool's name and purpose, which is insufficient for selecting among the many similar image 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?

No annotations are provided, so the description must carry the behavioral burden. It only restates that a box is drawn and does not disclose side effects on the image, whether the change is reversible, or what the tool returns beyond the available output schema.

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?

A single, front-loaded sentence that states exactly what the tool does with no filler or redundancy.

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

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

The tool is a simple drawing operation, and the input schema fully documents all parameters while an output schema exists. The description could add behavioral notes, but the overall context is reasonably complete for an agent to invoke 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 all 8 parameters are already documented. The description itself adds no parameter-level semantics, which is acceptable because the schema carries that weight.

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 ('draw') and the target object ('rectangle/box on the image'). It is easy to tell apart from sibling tools like add_circle, but it does not explicitly name those 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 wording implies when to use the tool: whenever a rectangular box is needed. There are no explicit when-to-use or when-not-to-use conditions, and no alternatives are mentioned, but the simple domain makes the intended use fairly evident.

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 bears the full burden of behavioral disclosure. It only says 'draw a circle on the image,' which implies a mutation (changing the image) but does not disclose whether the operation is reversible, whether it overwrites existing annotations, what state changes occur, or any side effects. There is no mention of permissions, limits, or error behaviors. This is minimal disclosure that leaves the agent guessing about consequences.

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 consists of a single, clear sentence with no redundant words. It is front-loaded with the action and resource. However, it is so sparse that it borders on under-specification rather than effective conciseness. It earns its place by stating the purpose, but it omits any context that would make it more useful. The structure is efficient, but the brevity limits its value.

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 has 7 parameters and an output schema, the description should at least mention when to use it, prerequisites, and what happens, but it only states the basic action. It does not explain return values (though output schema exists, it may cover that), nor does it provide usage context or side effects. For a drawing tool, an agent needs to know if it mutates the image, if it is reversible, and what coordinate system is used—none of which are disclosed. The description is inadequate for safe and correct invocation without external knowledge.

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%, meaning all 7 parameters (image_id, x, y, radius, fill, color, line_width) are fully described in the input schema with titles and descriptions. The tool description adds no additional semantic clarity beyond what the schema already provides. Since the schema handles parameter meaning comprehensively, a baseline score of 3 is appropriate, as the description does not compensate for any gaps but also does not need to.

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 'Draw a circle on the image' states a specific verb and resource (draw on image), and clearly differentiates from sibling tools like add_box, add_line, etc. by naming the shape. However, it lacks any additional specificity (e.g., coordinates, styling) that the schema provides, and it does not mention why an agent should choose this over other annotation tools. Still, the core purpose is unambiguous and distinct from its siblings.

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 zero guidance on when to use this tool versus alternatives. It does not state any prerequisites (e.g., image must exist), exclusions (e.g., not for other shapes), or contexts where this tool is preferred. An agent is left to infer usage from the name alone, which is insufficient for a tool with many sibling annotation 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the highlight is 'semi-transparent' and does not clarify what happens to the image, whether the operation is reversible, how opacity/color interact, or what the output represents. For a mutating image tool, this is a notable 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 a single, efficient sentence with no filler and front-loads the core action. It is concise, though it may be too terse to fully convey behavioral or selection context.

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 large number of sibling annotation tools and the absence of annotations, the description is incomplete for helping an agent decide when to select this tool. It lacks usage conditions, visual/behavioral details beyond 'semi-transparent', and any mention of how this relates to add_box or precise_annotate. The schema and output schema help, but the description still leaves important context unstated.

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, so the parameters are already well documented in the schema. The description adds no additional parameter meaning, which is acceptable under the baseline for full schema coverage, but it does not go beyond it either.

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

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

The description states a clear verb ('Add') and resource ('highlight region to the image'), which conveys the tool's primary function. It is distinguishable from siblings like add_box and add_line by the notion of a 'semi-transparent highlight region', though it does not explicitly contrast with those 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?

No guidance is provided about when to use this tool versus the many sibling annotation tools (add_box, add_circle, precise_annotate, etc.). The agent must infer usage from the tool name and short description alone, and there is no mention of exclusions or alternatives.

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 only states the action without revealing whether the image is permanently modified, whether the operation is undoable, or whether any permissions or side effects are involved. This is a significant gap for a mutation 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 a single sentence with no redundancy, but it is so brief that it borders on under-specification. It is front-loaded with the core action but lacks the contextual details that would make it genuinely useful. It is not verbose, but it is not sufficiently informative either.

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 7 parameters and many similar siblings, the description is incomplete. It does not mention how the line integrates with the image, whether it is an overlay or a destructive edit, or what the output schema represents. With no annotations and an output schema present, more context is needed to ensure correct invocation.

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

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

Schema description coverage is 100%, so the parameters (coordinates, color, width, image ID) are already well-documented in the schema. The description adds no additional meaning beyond what the schema provides, 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 'Draw a line on the image' clearly states the verb and resource, making the core purpose unambiguous. However, it does not differentiate from sibling tools like add_box, add_arrow, or add_circle, which are similarly named and share the same annotation pattern.

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 given on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer when a line is the appropriate annotation element.

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 reveals the auto-increment feature, which is useful, but it omits other important behaviors: it does not state that the tool mutates the image, whether changes are persistent or undoable, or what the output schema contains. The description is too sparse to give an agent confidence about side effects.

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 at two sentences and front-loads the primary purpose. It avoids redundancy with the schema and wastes no words. The auto-increment note is a useful addition that earns its place. Minor deduction for not being structured with clear separation, but overall it is efficient.

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 has 7 parameters and an output schema, the description is too brief to be contextually complete. It does not mention coordinate system, prerequisites (e.g., image must be loaded), the relationship to reset_callout_counter, or any details about the output. An agent lacks key information to correctly invoke the tool in a workflow.

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 provides 100% coverage with descriptions for all 7 parameters. The description adds no new parameter-specific meaning beyond what the schema already states (e.g., the 'number' parameter's auto-increment behavior is already in the schema). Since coverage is high, the baseline of 3 applies, and the description does not elevate it.

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 ('Add a numbered callout') and the resource (image). It also notes the auto-increment behavior, which differentiates it from other annotation tools like add_text or add_circle. However, it doesn't explicitly distinguish it from siblings like add_text with a number, but the term 'callout' implies a circled number, so it's mostly clear.

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 no explicit guidance on when to use this tool versus alternatives. It implies usage for sequential callouts via auto-increment, but does not mention when not to use it, nor does it reference the related sibling tool reset_callout_counter, which directly affects the auto-increment behavior. An agent is left to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'add text annotation to the image,' revealing nothing about how the annotation is applied (e.g., overlay coordinates, persistence, impact on the image) or anything about the operation's side effects. This is insufficient for a tool with zero annotation coverage.

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, concise sentence with no wasted words. It front-loads the core action. However, it is perhaps overly terse—while concise, it omits context that could be included without becoming bloated. Still, it is clearly structured and readable.

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 7 parameters and an output schema, the description is not complete for an agent to make a confident choice. It gives zero context on coordinate systems, how it relates to image state, or how it differs from other annotation tools. Since output schema exists, return values are covered, but the operational context is missing.

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 documents all parameters with descriptions, so schema coverage is 100%. The description itself adds no additional parameter meaning beyond what the schema provides, which meets the baseline for high coverage. A 3 is appropriate since the description doesn't hint at coordinate semantics, font sizes, or color usage 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 a specific action (add text annotation) on a resource (image). However, it does not differentiate from many similar sibling tools like add_box, add_circle, or add_highlight; an agent would still need to infer which tool is for text annotation versus other annotation 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?

There is no guidance on when to choose this tool over alternatives. The description does not mention that it is for text-only annotations, nor does it reference the many sibling annotation tools such as precise_annotate, annotate, or add_numbered_callout. An agent receives no context about selection 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not mention that it modifies the image in place, whether it is reversible, or any side effects such as overwriting existing watermarks. For a mutation tool with zero annotation coverage, this is 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?

The description is a single, concise sentence with no wasted words. It is appropriately sized, though it could include more useful information without losing conciseness. The structure is clear and front-loaded with the core action.

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 (6 parameters, 2 required, with defaults) and no annotations, the description is inadequate. It does not explain how parameters like opacity, position, or font_size affect the result, nor does it mention any behavioral context. Although an output schema exists, the description still lacks essential information about side effects or prerequisites for an agent to call 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%, with all six parameters having descriptions in the input schema. The description adds no extra meaning beyond what the schema already provides, so a baseline of 3 is appropriate. It does not compensate for any missing parameter context, but the schema itself is sufficient.

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

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

The description states the verb 'add' and the resource 'text watermark' on an image, making the core purpose clear. However, it does not differentiate from the sibling tool add_text, which also adds text to an image. The term 'watermark' provides some distinction but not explicit enough for an agent to reliably choose between the two.

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 add_text or other annotation tools. The description provides no context for selection, leaving the agent to infer usage from the name 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?

No annotations are provided, so the description carries the full behavioral burden, but it only says 'Adjust image brightness.' It does not disclose whether the image is modified in place, whether changes are reversible, whether the original file is preserved, or whether the factor has clamping 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 a single, front-loaded sentence with verve and no waste: 'Adjust image brightness.' It states the whole subject without redundant preview of parameters or generated plumbing.

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 only two well-documented parameters and an output schema available, the description covers the essential purpose. However, because this is a mutating image tool with no annotations, the absence of any usage or behavioral context leaves it only minimally 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% because both parameters have informative descriptions and a default for factor. The tool description adds no parameter-specific meaning, but the schema already covers semantics like 0.5=darker and 1.5=brighter, 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 names a specific verb ('Adjust') and resource ('image brightness'), clearly distinguishing it from siblings such as adjust_contrast. It is unambiguous, and even without opening the schema the agent knows exactly what operation this tool performs.

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 prefer this tool over sibling tools like adjust_contrast, or when not to use it. It does not mention prerequisites, ordering, or exclusions, so the agent must rely on the tool name alone to decide relevance in a larger editing workflow.

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 must carry the full burden of behavioral disclosure. 'Adjust image contrast' adds no information beyond the tool name: it does not say whether the operation mutates the image, returns a new image, requires specific permissions, or what side effects occur. This is a tautological description with no behavioral transparency.

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 only one sentence, but it is under-specified rather than usefully concise. It front-loads nothing of substance and fails to earn its place by conveying any information beyond the tool name.

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?

While the schema covers parameters and an output schema exists, the description still omits essential context such as whether the adjustment is relative to the current image, whether the original is overwritten, and when this tool should be chosen over adjust_brightness. For a tool with no annotations, this is not enough context for reliable invocation.

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

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

Schema description coverage is 100%, and the input schema already documents both parameters: factor has a clear explanation with example values, and image_id is described as the image ID. The description itself adds no parameter-level meaning, 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 states a clear verb and resource ('Adjust image contrast'), so an agent knows the basic operation. However, it does not distinguish this tool from siblings like adjust_brightness or other image-modification tools, so it misses the sibling-differentiation that would earn 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?

There is no guidance about when to use this tool versus alternatives such as adjust_brightness, rotate_image, or crop_image. The description gives no context, prerequisites, or exclusions, leaving the agent to infer usage entirely from the 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 must disclose behavior. It thoroughly explains position formats, anchor alignment, and offset direction, and provides examples. However, it does not mention side effects (e.g., whether the image is modified in place), return values, or behavior of auto_adjust. The description covers the core positioning mechanics but leaves some behavioral aspects implicit.

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 with clear sections for position, anchor, offset, and examples. It is somewhat long but every sentence contributes useful information. The front-loaded purpose is clear, and the examples are valuable. A minor point: the examples could be trimmed, but overall it is efficient.

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 thoroughly covers positioning, anchor, and offset, which are the most complex aspects. However, it does not explain the meaning of each annotation_type (box, circle, etc.) nor the end_position parameter for arrows/lines, and it omits details about auto_adjust behavior. Given the tool's complexity and the output schema's existence, these gaps mean the description is not fully 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 coverage is 100% and the schema already describes each parameter. The description adds significant value by detailing the position formats (named, percentage, pixels), anchor semantics, and offset directions, and by showing combined usage in examples. This goes beyond the schema's brief descriptions.

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

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

The description clearly states it is a unified annotation tool with flexible positioning and anchor support. It lists the annotation types implicitly via examples and the schema enum, and the word 'unified' differentiates it from sibling tools like add_box, add_line, etc. This is specific and unambiguous.

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

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

The description gives examples but no explicit guidance on when to use this tool versus the specific add_* tools or precise_annotate. It does not mention alternatives or exclusion criteria. The 'unified' label implies it can replace them, but there is no explicit when-to-use or when-not-to-use guidance.

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

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

No annotations exist, so the description carries the burden. It discloses the composite behavior and auto-placement of callout_position, which is useful. However, it does not mention any side effects (e.g., whether it modifies the image in place), return behavior, or interaction with step_number auto-increment (which is only in the schema). The absence of these details leaves some behavioral 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?

Three sentences, no filler. The main purpose is in the first sentence, the composite nature clarifies scope, and the auto-placement note is a valuable detail. Every sentence earns its place.

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

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

For an 8-parameter tool with full schema coverage and an output schema present, the description covers the core purpose, use case, and a key behavior. It does not mention alternatives explicitly, which might be helpful given the large sibling set, but it is not strictly necessary. Overall, it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so every parameter already has a clear description. The tool description adds minimal extra semantic value beyond the schema—only reinforcing that text is optional and that callout auto-places. This aligns with the baseline 3: 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 opens with a specific verb-resource pair: 'Add a numbered step annotation with callout circle, arrow, and optional text.' It then clarifies this is a composite tool combining a numbered callout and arrow, which distinguishes it from siblings like add_arrow or add_numbered_callout. The purpose is unmistakable.

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 a clear use case: 'Useful for creating step-by-step tutorials or highlighting UI elements.' This tells an agent when to apply the tool. It does not explicitly name alternative tools or state when not to use it, but the composite nature and mention of auto-placement imply it's the high-level option. Slight gap in explicit 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 behavioral burden. It explains that annotations follow the annotate() format and includes an example, but it does not disclose failure behavior, ordering, atomicity, or what happens if some annotations are invalid.

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 and then gives the required array structure and a concrete example. The example is moderately long but earns its place by showing realistic annotation objects; no sentences are wasted.

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 only two parameters, both fully documented in the schema, and an output schema is present. The description adds a practical example and references the annotate() format. Additional guidance about batching semantics would be nice but is not essential for basic invocation.

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

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

The schema already covers 100% of the parameters, so the baseline is 3. The description adds value with a multi-annotation example and a cross-reference to the annotate() format, which helps an agent understand how to construct valid entries beyond the schema text.

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 identifies the operation: applying multiple annotations in one call. This distinguishes it from the many single-annotation sibling tools like add_box, add_text, and the basic annotate tool.

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 'in a single call' and the instruction to pass an array of annotation specs implicitly tell the agent to use this when batching multiple annotations. It does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It says the tool blurs or pixelates a region, but does not mention whether the original image is modified in place, whether the operation is reversible, or what the output/return behavior is. For a mutating image tool, this leaves meaningful 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 sentences with no redundant wording. The action and purpose are front-loaded, and the example use case is useful without being verbose.

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 a complete input schema with parameter descriptions and an output schema, so the description does not need to repeat return-value details. The main missing context is behavioral (in-place mutation, reversibility/undo), but given the schema richness, the description is close enough for basic selection and invocation.

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

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

Schema description coverage is 100% and the params already explain x, y, width, height, image_id, pixelate, and blur_strength. The description adds the intent (hiding sensitive info) and mentions blur/pixelate, but does not add new parameter-level meaning. Baseline 3 is appropriate since 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 uses a specific verb ('Blur or pixelate'), names the resource ('a region of the image'), and states a clear purpose ('hide sensitive information'). This distinguishes it from sibling tools like crop_image, resize_image, and annotate, which serve different 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 gives explicit when-to-use guidance: 'Use this for hiding passwords, email addresses, personal info, etc.' It does not mention alternatives or when-not-to-use conditions, but the intended use case is clear enough for an agent to select it over other image-editing siblings.

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 the underlying implementations and platform differences, and notes the need for a numeric window ID. It does not detail side effects like file output or permissions, but the presence of an output schema likely covers return format, so this is adequate.

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 compact and efficient: the main purpose is front-loaded, and every sentence provides necessary detail (platform differences, window ID lookup) without fluff. It is well-structured across short paragraphs.

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 multiple modes and platform-specific behavior, the description covers the essential operational context: what modes exist, how to invoke them, and the platform fallback. Since an output schema exists, no return detail is needed, and the description fully equips an agent to call 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?

The input schema has 100% description coverage, with each parameter described clearly. The description adds extra value by explaining the window_id parameter more concretely (numeric ID, how to find it) and clarifies the region mode as interactive selection, which slightly extends the schema's basic definitions.

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 captures a screenshot of the screen, region, or a specific window, with distinct verbs and resources. It is obviously distinct from the sibling tools, which are all for image annotation, editing, or management, not capture.

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 platform-specific guidance (macOS native screencapture vs PIL fallback) and explains the requirement for numeric window IDs on macOS, with a command to find them. It does not explicitly state when to use this tool over alternatives, but there are no competing capture tools among siblings, so the guidance is sufficient.

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 must carry the full behavioral burden. It discloses that it returns a percentage and optionally creates a diff image, which covers the core behavior. It does not mention side effects like file persistence or permission needs, but for a comparison tool this is reasonably transparent.

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 well-structured: first sentence states the main purpose, second details the output and conditional behavior, third provides context. No redundant or extraneous 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 has an output schema, 5 parameters (2 required), and no annotations, the description covers purpose, behavior, and typical usage. It doesn't mention prerequisites like image loading, but those are implied by sibling tools and the parameter schema. Overall, it is sufficiently complete for an agent to call 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 schema already documents all parameters. The description adds no additional parameter-level detail beyond what the schema provides, making the baseline score of 3 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 compares two images and optionally creates a diff image. It specifies the verb 'compare', the resource 'images', and the key side effect. It distinguishes from siblings like create_side_by_side by focusing on difference highlighting rather than side-by-side presentation.

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 use cases ('comparing before/after screenshots, detecting UI changes, validating visual regression tests') which imply when it is appropriate. However, it does not explicitly exclude alternatives or state when to choose another tool, so it lacks the 'when-not' guidance required for a 5.

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

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

No annotations are present, so the description carries the full burden. It does disclose a key non-obvious side effect: lowering limits triggers eviction. However, it stops short of explaining what eviction entails (e.g., which images are removed, reversibility), leaving some behavioral 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?

Two sentences with zero filler: the first states the core function, the second provides the important side-effect warning. 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?

For a three-optional-parameter configuration tool with an output schema, the description is mostly sufficient: purpose, side effect, and the schema's defaults cover the essential call information. Missing explicit interaction with get_memory_stats or eviction behavior detail are 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%, with all three parameters (max_images, undo_levels, max_memory_mb) already documented with defaults and constraints. The description adds no parameter-specific detail beyond what the schema provides, so baseline 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 uses a specific verb ('Configure') with a specific resource ('memory limits for the image store') and adds a concrete behavioral consequence (eviction). It clearly differs from the read-oriented sibling get_memory_stats, so an agent can distinguish the writing operation without opening the schema.

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 intended use is implied: configure limits when you want to change the image store's memory behavior, while get_memory_stats is the read counterpart. However, the description gives no explicit when-to-use guidance, exclusions, or mention of prerequisites.

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 the action but does not mention potential side effects (e.g., overwriting clipboard contents), prerequisites (e.g., image must be loaded), or error behavior. The description is adequate but minimal for a simple 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 a single, direct sentence with zero excess words. It is front-loaded with the action and resource, making it immediately scannable. Perfect conciseness for a tool of this simplicity.

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

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

Given the tool's simplicity, one parameter, and the presence of an output schema (which likely describes return values), the description is mostly sufficient. However, it omits any contextual cues about when to use it (e.g., for pasting into external apps) and lacks explicit behavioral details. It is adequate but not thorough.

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 the single parameter is 100% (the schema already describes image_id as 'ID of the image to copy'). The description adds no additional meaning beyond what the schema provides, so it meets the baseline expectation but does not exceed it.

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

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

The description uses a specific verb ('Copy') and specific resource ('an image to the system clipboard'), making the tool's purpose unmistakable. It clearly distinguishes itself from sibling tools like save_image or open_in_preview by naming the destination (clipboard) rather than file or preview.

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 no guidance on when to use this tool versus alternatives such as save_image or open_in_preview. There is no mention of scenarios where copying to clipboard is preferred, nor any exclusions. An agent must infer when this is appropriate.

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 one meaningful behavior ('Labels are added above each image if label_height > 0') and implies creating a new composite rather than mutating the inputs. Still, it does not state whether the source images are left untouched, where the composite gets stored, or any side effects on session state.

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

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

Three sentences, each earning its place: the primary operation, the use cases, and the one non-obvious behavioral nuance. The core action is front-loaded and no filler or repetition of schema fields exists.

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 moderate-complexity tool (7 params, 2 required, output schema present), the description covers the purpose, realistic scenarios, and the key labeling behavior. Return value handling is presumably covered by the output schema. The only meaningful gap is the missing contrast with `compare_images`, which affects routing rather than invocation correctness.

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. Every parameter already has a meaningful description ('ID of the first (left) image,' 'Background color for gap and labels'). The description adds marginal value by explaining that label_1/label_2 render above each image and that label_height toggles them, but this mostly restates schema hints like '0 to disable labels.'

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?

States a specific action and resource: 'Create a side-by-side comparison image from two images.' It clearly describes the output artifact and inputs. However, it does not distinguish itself from the sibling tool `compare_images`, which plausibly overlaps in intent, so an agent must infer the difference between a composite side-by-side image and an actual comparison 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?

Provides clear usage context: 'Useful for visual comparisons, before/after documentation, or A/B testing screenshots.' This tells an agent when to reach for it. However, it offers no explicit exclusions, such as 'for pixel-diff or similarity analysis use compare_images instead,' leaving the boundary with that sibling unstated.

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 doesn't disclose whether the crop is destructive (does it modify the original image or create a new one?), whether coordinates are relative to a loaded image or file path, or how out-of-bounds coordinates are handled. These are critical behavioral details 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 very concise: a single sentence that clearly states the action. It is front-loaded and to the point. The only minor issue is that it lacks any additional context, but for simplicity it is 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 there is an output schema (though not provided here), the need for describing return values is reduced. However, the tool is one of many image manipulation tools, and the description doesn't clarify how it integrates with the workflow (e.g., whether it operates on an image already loaded, or if the image_id refers to a file path or in-memory object). It lacks critical operational context 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%, so the baseline is 3. The description adds no extra meaning beyond the schema, but it also doesn't need to since each parameter is described in the schema. However, it doesn't provide any relationships or constraints (e.g., width/height must be positive, coordinates must be within bounds) that would be valuable.

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

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

The description states a clear verb ('Crop'), resource ('the image'), and specific action ('to a specific region'). It is specific enough to distinguish it from other image manipulation tools like resize_image, rotate_image, and flip_image.

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 say anything about prerequisites (e.g., image must be loaded), coordinate system assumptions, or when another tool might be more appropriate (e.g., resize for scaling vs crop for trimming).

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

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

Annotations provide no safety hints, so the description carries the full burden of disclosing that this is a destructive operation. It does not mention irreversibility, whether deletion affects only the in-memory session, or any side effects. For a delete tool, this is a significant transparency 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 a single, front-loaded sentence with no filler. It efficiently communicates the action and scope, which is appropriately concise for a single-parameter 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?

Even though the tool is simple and has an output schema, the description omits important behavioral context for a destructive operation: undoability, persistence, and error behavior. The sibling tools include undo and get_undo_count, so the interaction between deletion and undo is a relevant detail that is not addressed.

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%, and the only parameter, image_id, is already documented as 'ID of the image to delete'. The description adds no extra semantic detail, such as where to obtain the ID or session-specific scoping nuances, 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 states a clear action ('Delete') on a specific resource ('an image') and scopes it to the session, which distinguishes it from sibling image tools like list_images, get_image, or duplicate_image. There is no ambiguity about what the tool does.

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 delete_image versus alternatives such as undo or save_image. The description is purely declarative and does not mention prerequisites, exclusions, or decision criteria for choosing this tool.

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 must carry the full behavioral disclosure burden. It only states that a copy is created and does not explain whether the original is modified, whether permissions are required, how the new image is identified, or what side effects occur.

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 concise sentence that states the core operation immediately with no filler or redundant content. It is optimally sized for the simple one-parameter 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?

The tool is simple, has only one parameter, and an output schema exists, so the missing return-value documentation is not a gap. However, with no annotations and no usage or behavioral context, the description is only minimally viable for an agent deciding whether and how to invoke it.

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 image_id already documented as 'ID of the image to duplicate.' The description adds no additional parameter-level 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 names a specific verb ('Create a copy') and a specific resource ('an existing image'), making the operation unambiguous. It also distinguishes duplicate_image from siblings like delete_image or resize_image, and the name plus description avoid confusion with copy_to_clipboard.

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 such as save_image, copy_to_clipboard, or export_session. It does not mention exclusions, prerequisites, or a preferred context, leaving the agent to infer when duplication is appropriate.

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?

There are no annotations, so the description must carry the burden of behavioral disclosure. It does well by stating that it exports to a zip archive, includes images, manifest, and optionally undo history. It also mentions later restoration. However, it does not disclose what happens to the resulting file if a file already exists at the path (overwrite vs. error), or any permissions needed. This is a minor gap for a non-destructive export 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 well-structured, starting with the core purpose and then listing contents in a bullet-like format. Every sentence adds value, and the reference to import_session is helpful. It could be slightly more compact, but the structure is effective.

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?

This is a moderately complex tool (two parameters, no nested objects) and it has an output schema, which may cover return format. The description provides enough context about what is being exported and points to the counterpart import_session. It lacks a note on path handling (overwrite behavior) and does not mention error conditions, but these are not critical for an export tool. Overall, it's sufficiently 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 fully documents both parameters. The description's mention of 'manifest.json with image IDs' and 'optionally undo history' adds context about what the archive contains, which helps understand the include_history parameter's purpose. However, it does not add specific syntax or format details beyond what the schema provides. 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 action (export), the resource (all images and metadata), and the output format (zip archive). It explicitly lists contents, distinguishing it from simpler save operations like quick_save or save_image, which likely save a single image. This is a specific and unambiguous definition.

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 says 'Use import_session to restore the session later,' which implies this tool is for backup/restore workflows and distinguishes it from single-image save tools. However, it does not explicitly mention alternative tools like quick_save or save_image or provide exclusionary guidance (e.g., 'use save_image for single image export'), but the context is clear enough for an agent to infer when to use this tool.

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 present, so the description carries the full burden of behavioral disclosure. It states only the transformation and does not say whether the original image is modified, whether a new image is returned, or whether the operation is reversible. For a mutation-like image tool, this is a meaningful 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 a single front-loaded sentence with no filler: it gives the action, the target, and both direction options while adding the clarifying synonym 'mirror.' This is appropriately sized for the tool's complexity.

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 two-parameter tool with full schema documentation and an output schema, the description covers the core invocation semantics completely. It is only slightly thin on behavioral context such as in-place mutation versus returning a new image, but no required invocation detail is missing.

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 image_id and direction already documented, including the enum and default. The description adds no new constraints, syntax details, or edge-case guidance beyond what the schema provides, so it earns the high-coverage baseline.

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

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

The description uses a specific verb ('Flip'), names the target resource ('the image'), and explicitly enumerates both supported directions. It clearly separates this operation from siblings like rotate_image or crop_image without needing to name them.

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 about when to choose flip_image over sibling tools such as rotate_image, crop_image, or resize_image. There are also no prerequisites, exclusions, or contextual hints beyond the implied meaning of 'flip.'

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 present, the description carries the burden. It implies a read-only operation and states that image data is returned, but it does not disclose potential side effects, error conditions, or output format. It is adequate for a simple retrieval tool but not rich.

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 only two short sentences, focused, and free of unnecessary detail. It front-loads the core behavior and does not waste words.

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

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

For a one-parameter retrieval tool, the description covers the essential action and return claim. It lacks an explicit output format or error behavior, but with no output schema and no annotations it is still reasonably complete for the low 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%, and the only parameter image_id is already described. The phrase 'by its ID' merely restates the parameter purpose without adding format, constraints, or additional context 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 states a specific verb and resource: 'Get a specific image by its ID' and notes it returns image dataasia. This distinguishes it from list_images and capture_screenshot, though it does not explicitly contrast with sibling load_image or get_image_base64.

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 similar siblings like load_image or get_image_base64. The agent must infer the appropriate selection from the name and description 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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only restates the action ('Get an image as a base64-encoded string') without mentioning read-only nature, side effects, permission requirements, or any constraints. The implied read operation is not explicitly stated, and there is no mention of error behavior or size limits.

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?

A single, front-loaded sentence that precisely conveys the action and output format. There is zero redundancy; every word earns its place. It is appropriately concise for a simple getter 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 simple tool with one parameter and an output schema (present), the description covers the core purpose. However, it omits any mention of when to use this over get_image or any prerequisites (e.g., how to obtain an image_id). The absence of usage guidance and explicit behavioral notes makes it slightly incomplete, but the simplicity of the tool and the presence of an output schema mitigate the 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?

The schema already documents image_id as 'ID of the image' with 100% coverage. The description adds no additional parameter context, such as format, source, or how to obtain a valid ID. Baseline 3 applies because the schema fully covers the parameter, and the description does not need to compensate for gaps.

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

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

The description states a specific verb ('Get'), a resource ('an image'), and a specific output format ('base64-encoded string'). This clearly distinguishes it from sibling tools like get_image (likely returning a file or object) and list_images (which lists). It leaves no ambiguity about what the tool does.

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_image, load_image, or capture_screenshot. The description only states the action, leaving the agent to infer appropriate usage from the format difference. There are no explicit exclusions or conditions.

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 behavioral disclosure. It implies a read-only operation via the verb 'Get' but does not explicitly state non-destructiveness, nor does it describe the output shape or any potential side effects. The output schema covers return values, but the description itself adds little beyond the action.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose, making it highly efficient and easy to parse.

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 zero-parameter, read-only utility with an output schema, the description is complete. The output schema defines the return structure, and the simple purpose requires no additional context. Nothing an agent needs to invoke it correctly is missing.

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?

There are zero parameters, so the description has nothing to explain. Per the rubric, a tool with 0 parameters receives a baseline of 4. The description does not need to add parameter information since none exist.

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 ('Get') and the resource ('memory usage statistics for the image store'), making it distinct from all sibling tools, none of which appear to return memory statistics. The verb and resource are specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives, though no obvious alternative exists among the siblings. It does not mention context such as 'when monitoring performance' or 'before heavy operations,' but the lack of alternatives makes this a minor gap. The purpose is self-evident enough that an agent could infer when it is relevant.

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 burden of behavioral disclosure. The description states it's a read-only operation (getting a count), which is useful. However, it doesn't disclose what happens if the image_id is invalid, whether the count resets after certain operations, or any side effects. For a simple read operation, this is adequate but not rich.

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's front-loaded with the action and resource. Perfectly concise.

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 an output schema. The description is adequate for an agent to understand what it does. However, it doesn't mention what the return value looks like (though the output schema exists, so that's covered) or any edge cases. For a simple read tool, this is sufficient but not exceptional.

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 (image_id). The description doesn't add much beyond what the schema provides, but it does clarify that the count is for 'an image', which maps to the image_id parameter. Baseline 3 is appropriate since 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 function: retrieving the number of available undo operations for an image. It uses a specific verb ('Get') and resource ('number of available undo operations for an image'). It doesn't explicitly distinguish from sibling tools, but the function is specific enough that it's unlikely to be confused with others like 'undo' or 'reset_callout_counter'.

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: it's for checking undo availability before performing an undo operation. However, it doesn't explicitly state when to use this tool versus alternatives like 'undo' or 'reset_callout_counter'. The context is clear enough for an agent to infer, but explicit guidance is missing.

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 key behavioral traits: default merging versus replacing all current images with imported ones. This is a mutation operation, and the description clearly states the two modes. It does not elaborate on nuances of merging (e.g., conflict resolution) or side effects on undo history, but the main behavioral choice is transparent.

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 with no filler. The primary purpose is front-loaded, and the critical merge behavior follows immediately. Every phrase contributes to understanding how to use the 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 tool with only three scalar parameters and no enums or nesting, the description covers the essential behavior. The output schema exists (though not detailed here), and parameter semantics are well-handled. Minor gaps (e.g., what happens to existing data on merge, exact behavior of restore_history) are acceptable given the schema's descriptions.

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

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

Schema descriptions cover all three parameters (100% coverage), so the baseline is 3. The description adds meaningful context by explaining the merge parameter's default and its effect, which goes beyond the raw schema. It does not add anything about path or restore_history, but those are well-described 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 that the tool imports a previously exported session from a zip archive. It distinguishes itself from siblings like export_session (reverse operation) and load_image (single image vs entire session) with a specific verb and resource.

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 tool's name and mentions the merge parameter's default behavior, but it does not explicitly instruct when to choose this tool over alternatives (e.g., load_image or export_session). No exclusions or alternative routing is given, though the context that it is for restoring sessions is reasonably clear.

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 must carry the full burden. It states 'Quickly label' but does not disclose whether the operation modifies the image, requires prior image loading, or what the return value is. For a tool that likely alters an image, this lack of side-effect disclosure is 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?

The description is concise, with a clear opening sentence and a helpful example. It avoids unnecessary fluff and front-loads the purpose. The example is well-formatted and directly illustrates the 'regions' parameter, making it efficient for an agent to parse.

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 that an output schema exists and the input schema covers all parameters, the description is adequate but not fully complete. It doesn't mention any prerequisites like requiring an image to be loaded (sibling tools include load_image), nor does it explain the output format beyond what the schema likely covers. For a tool that modifies an image, this is a notable omission.

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 provides 100% coverage with descriptions for all four parameters, including an example for 'regions'. The description adds a slightly different example, but this doesn't go beyond the schema's explanation. With high schema coverage, a baseline of 3 is appropriate; the description adds marginal value but doesn't compensate for any missing details.

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: 'Quickly label multiple regions of an image.' It specifies the verb (label), resource (regions of an image), and the 'multiple' aspect distinguishes it from single-region annotation tools like add_box or add_text. However, it doesn't explicitly differentiate from sibling tools like annotate or batch_annotate, so it's not a perfect 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 phrase 'Quickly label multiple regions' implies batch usage, which is a clear context for when to use it over single-label tools. It also provides an example that clarifies the expected input format. However, it doesn't explicitly state when not to use it or name alternative tools, so it misses some 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?

There are no annotations, so the description carries the behavioral burden. It scopes the operation to the current session, which is useful, and 'list' implies a read-only action. However, it does not disclose ordering, whether results include metadata or just identifiers, or any session-related constraints. For a simple list tool this is acceptable but not richly transparent.

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?

A single, front-loaded sentence with no filler. Every word contributes to the meaning, and the scope is stated immediately in the core clause.

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 zero-parameter list operation with an output schema present, the description is nearly complete. It conveys the key scoping detail (current session) and relies on the output schema to define return values, which is appropriate. It is missing only minor behavioral nuance like ordering or result format, but nothing that blocks correct invocation.

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

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

There are no parameters and the schema is empty, so the description needs to add little. The phrase 'current session' gives useful context about the implicit scope of the operation, satisfying the baseline for a zero-parameter tool.

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?

Clear verb-resource pair: 'list' + 'all images'. The scope 'in the current session' distinguishes it from per-image retrieval tools like get_image and mutation tools like delete_image. The simple name plus description leaves no ambiguity about what the tool does.

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

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

The description implies when to use it—when a full enumeration of the current session's images is needed—but it does not explicitly mention alternatives or state when not to use it. For a zero-parameter tool the inference is straightforward, but the guidance remains implicit 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 the full burden of behavioral disclosure, but it only states the action and purpose. It does not say whether loading replaces the current image, whether it has side effects, what happens with invalid paths, or what the output contains. 'Load' implies reading an existing file, but that is minimal.

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?

A single sentence that is front-loaded with the verb and object. It contains no filler and communicates the core purpose 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?

For a simple one-required-parameter tool with an output schema, the description is minimally adequate: an agent knows what to do and what input to provide. However, in the context of many sibling tools, it lacks guidance on workflow placement and how this load differs from other loading/opening 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 coverage is 100%, and the path parameter is already described as 'Path to the image file to load.' The description adds little beyond the schema, so the baseline of 3 applies. It confirms the parameter refers to an existing file, but no format or sourcing details are added.

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

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

The description uses a specific verb and resource: it loads an existing image file for annotation. This makes the tool's purpose immediately clear and distinguishes it from siblings that create images (capture_screenshot), list them (list_images), or retrieve them in other forms (get_image).

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 about when to use this tool versus alternatives such as get_image, open_in_preview, or list_images. The phrase 'for annotation' implies its context, but it does not state exclusions, preconditions, or how to obtain a valid path.

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 burden of behavioral disclosure. It discloses that the tool doesn't require loading the image into the session, which is useful, but it doesn't mention side effects like whether it launches a GUI app, whether it blocks, or whether it requires a display environment. The description is accurate but minimal.

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

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

The description is two sentences with no wasted words. The key behavioral distinction (doesn't require loading into session) is front-loaded and earns its place.

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

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

For a simple one-parameter tool, the description is mostly complete. However, with no annotations and no mention of return values or potential errors (e.g., file not found), an agent might not know what to expect. The output schema exists but the description doesn't clarify the tool's behavior beyond opening the file.

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 path parameter. The description adds no extra meaning beyond what the schema provides, so the 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 opens an image file in the native Preview app or default viewer, with a specific verb and resource. It distinguishes itself from loading the image into the session, which helps differentiate it from tools like load_image, though it doesn't explicitly name a sibling.

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

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

The description implies when to use this tool: when you want to open an image externally without loading it into the session. However, it doesn't explicitly state when not to use it or name alternatives like load_image or open_in_preview, leaving some inference to the agent.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains platform-specific behavior (Preview vs default viewer) and mentions annotation capability on macOS, but does not disclose side effects, return values, or environmental requirements. This is minimal but covers the key platform distinction.

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 exceptionally concise—two sentences with no filler. It front-loads the primary purpose and adds the platform detail in the second sentence. 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 the tool's simplicity and the existence of an output schema, the description adequately covers the core behavior. It lacks details about return values or error handling, but those may be covered by the output schema. The platform-specific note adds valuable context, making it nearly complete for this tool type.

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 both parameters are documented in the schema. The tool description adds no extra meaning to the parameters, merely restating the action. Baseline 3 is appropriate since the schema handles parameter documentation and the description does not detract.

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

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

The description clearly states the tool opens an image and specifies the target app (Preview on macOS). The phrase 'macOS only' is then contradicted by 'On other platforms, it opens with the default image viewer,' creating minor ambiguity about platform availability. It distinguishes from open_file_in_preview by focusing on images, but not explicitly.

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 open_file_in_preview or other image viewers. The description only explains the action, not the context or selection criteria. An agent receives no hints about appropriate use cases or 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 behavioral disclosure burden. It does disclose core behavior: exact coordinate placement, no auto-positioning, and type-specific coordinate semantics. However, it does not describe side effects such as whether annotations persist, whether existing annotations are affected, or how invalid or out-of-bounds coordinates are handled.

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-organized, front-loaded with the key behavioral promise, and uses brief coordinate rules followed by concrete examples. Every sentence serves a purpose, and the examples are clear and actionable without unnecessary verbosity.

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

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

For a 13-parameter tool with a full schema and an output schema, the description is largely complete: it explains coordinate conventions, gives usage examples, and covers all major annotation types. The main gap is the lack of explicit guidance on when to use this tool versus the many similar sibling tools, and it assumes the agent knows how to supply image_id from the examples.

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 the baseline is 3. The description adds meaningful value by explaining coordinate semantics per annotation type: top-left for box, center for circle, start for text, and x2/y2 for arrows/lines. The examples further clarify parameter usage, exceeding what the schema alone provides.

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

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

The description clearly identifies the tool as a pixel-perfect annotation tool with a specific verb and resource: it places annotations at exact pixel coordinates. It distinguishes itself from convenience/auto-positioning alternatives by stating 'no anchor adjustments, no auto-positioning', though it does not explicitly name any sibling tool.

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

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

The description implies when to use the tool: when exact pixel placement is required, and not when auto-positioning or anchor adjustments are desired. However, it provides no explicit guidance or clear alternatives, despite many overlapping sibling tools like add_box, add_arrow, add_text, and annotate.

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 exist, so the description carries the burden of behavioral disclosure. It adds one useful non-obvious behavior—automatic OS-specific path resolution—but does not mention overwrite behavior, file conflicts, or other side effects of a write 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?

Two short sentences, front-loaded with the tool's purpose and immediately followed by the key behavioral detail. 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 100% schema coverage and an output schema, the description is mostly sufficient. It lacks explicit when-to-use guidance versus save_image and does not disclose write-operation semantics, which leaves some contextual gaps.

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

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

Schema coverage is 100%, giving a baseline of 3. The description adds value by explaining that location values are resolved to OS-specific paths automatically, so the caller does not need to provide full paths; this meaningfully supplements the enum values.

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?

States the action 'save' and the target common locations, and the schema identifies the image resource. It is distinguishable from save_image by its focus on OS-resolved common locations, though it does not explicitly name the alternative.

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

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

No guidance is given about when to use quick_save versus save_image or other saving-related siblings. 'Quick' implies convenience, but there are no explicit conditions, exclusions, or alternatives.

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 present, so the description carries the full burden of behavioral disclosure. It correctly states the effect (counter set to 0), which implies a mutation. It does not mention side effects like whether existing callout numbers change or if any prerequisites exist, but for such a simple reset operation, the disclosure is adequate but not rich.

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, concise sentence that states the action and the target value. There is no waste, and the core information is front-loaded. It is appropriately sized for the simplicity of the tool.

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

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

Given the tool's simplicity (no parameters, a clear reset action, and an output schema present), the description is sufficient for an agent to invoke it correctly. It does not explain the return value or any prerequisites, but these are not essential for a trivial reset operation. Overall, it is complete enough for the use case.

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, and the schema coverage is 100% (vacuously). The baseline for a zero-parameter tool is 4, and the description adds no parameter-specific information because none are needed. It correctly omits any parameter details.

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

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

The description states a clear action (reset) and a specific resource (auto-increment callout counter). It is unambiguous about what it does, and the sibling list includes add_numbered_callout, which makes the counter's purpose implicit. However, it doesn't explicitly name the sibling it complements, so it falls short of full differentiation.

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

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

The description implies when to use it (when you want to restart callout numbering), but provides no explicit guidance, exclusions, or alternatives. The context of sibling tools (add_numbered_callout) hints at usage, but the description itself leaves it to inference.

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, but it only states the operation and parameter types. It does not reveal whether the original image is modified in place or a new image is returned, nor how conflicting parameters (scale vs. width/height, maintain_aspect) are resolved.

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 sentence of about ten words, front-loading the main verb and resource without any filler. It is appropriately concise for a straightforward 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?

Because the input schema thoroughly documents every parameter and an output schema exists, the description does not need to explain all details. However, it omits a decision rule for choosing between scale and width/height and does not state whether resizing is destructive, which an agent would need to invoke the tool safely and 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 schema describes all parameters (100% coverage), so the baseline is 3. The description adds a high-level mapping between 'dimensions' (width/height) and 'scale factor' (scale), but does not explain parameter precedence or the interaction with maintain_aspect beyond what the schema already says.

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 ('Resize the image') and the two supported modes ('by dimensions or scale factor'), distinguishing it from siblings like rotate_image or flip_image. It does not explicitly contrast with sibling tools, but the core action is specific enough for an agent to identify the intended use.

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 given about when to use this tool versus alternatives such as crop_image or flip_image. The only usage signal is the verb 'Resize', so the agent must infer appropriateness from the tool name and context rather than from any explicit when-to-use or when-not-to-use instruction.

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 implies mutation ('rotate the image') but does not state whether the operation modifies the image in place, returns a new image, or is reversible. There is no mention of side effects, permissions, or limitations, which is a significant gap for a mutation 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 a single, concise sentence that directly states the action and the allowable degrees. It is front-loaded with the core verb and resource, with zero wasted words. This is an appropriate length for a simple operation.

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, and the schema plus output schema cover the parameters and return values. However, without annotations, the description does not clarify whether the rotation is destructive or reversible, nor does it provide any usage context or alternatives. While the description is minimally sufficient for a basic operation, it leaves behavioral questions unanswered, making it only partially 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 baseline is 3. The description adds no extra meaning beyond what the schema already provides; it merely reiterates the angle values that are already enumerated in the schema. Since the schema fully documents both parameters, the description does not need to compensate, but it also does not add 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 states a specific verb ('rotate') and resource ('the image') along with the allowed angles (90, 180, 270), making the action unambiguous. It clearly distinguishes from siblings like flip_image (which flips rather than rotates) and resize/crop, so an agent can select it correctly without opening the schema.

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. The description does not mention any conditions, prerequisites, or exclusions (e.g., when flip_image might be preferred, or whether rotation is in-place or creates a new image). This is a pure functional statement with no contextual usage information.

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 available, the description alone must disclose side effects and behavioral traits. It only says 'save to disk' and gives no information about file overwriting, required preconditions (e.g., the image must already exist), or whether this is a mutating/destructive 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 a single, front-loaded sentence with no wasted words. It is appropriately short for a tool whose parameters are fully documented in the schema.

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 4 parameters, no annotations, and no usage guidance, this description is too thin. The schema covers parameter names and types, but the description omits important context such as overwrite behavior, file naming implications, and how this tool relates to quick_save.

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 already well documented. The description adds no additional parameter-level meaning beyond the schema, which is acceptable but earns only the baseline score.

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

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

The description states a clear action ('Save') and resource ('an image to disk'), so an agent understands the tool's basic function. However, it does not differentiate from sibling tools like quick_save or export_session, which may also persist or save image data.

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 about when to use this tool versus alternatives such as quick_save or copy_to_clipboard. The description only states what it does, not the conditions that make it the right choice or when to avoid 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 must disclose behavioral traits. It only states the action 'undo' without mentioning side effects, reversibility, error conditions (e.g., no annotation to undo), or whether it applies per image. This leaves the agent without knowledge of what changes occur or what the output schema represents.

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, concise sentence that front-loads the action and object. There is no redundant wording or filler, making it efficient for an agent to parse.

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 one parameter and an output schema, the description is minimally adequate. However, it lacks behavioral context such as what happens when there is no annotation to undo, whether the operation is idempotent, or how the output schema relates to the action. Given the simplicity, a 3 is reasonable but it could be improved with a note on undo limits.

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% – the image_id parameter is fully described in the schema. The description adds no additional meaning beyond the schema, so the baseline of 3 applies. No extra context about the parameter's format or constraints is given.

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

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

The description states a specific verb (undo) and resource (last annotation on an image), clearly distinguishing it from sibling annotation tools like add_box or annotate. The scope is unambiguous and matches the tool name.

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 after a mistaken annotation, but provides no explicit when-to-use guidance or mention of alternatives such as get_undo_count. It does not explain when undo might be unavailable or how it interacts with other tools.

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