Server Quality Checklist

Tool Scores

• placeholderA
  3.8/5.0
  Behavior3/5

  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 states that it writes to 'out' and returns the output path and generated dimensions. However, it does not address potential side effects such as overwriting existing files, required write permissions, or error handling. This is adequate for a simple tool but leaves some behavioral gaps undisclosed.

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

  Conciseness5/5

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

  The description is four concise sentences with no redundancy. It front-loads the core action, then provides use-case context, parameter summary, and return information. Every sentence contributes value, and the structure is efficient.

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

  Completeness4/5

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

  The description covers purpose, parameters (via summary and schema), and return values. It is complete enough for a straightforward generation tool. It omits edge-case behaviors like overwrite semantics, but given the tool's simplicity and full schema coverage, it does not leave critical information missing for typical usage.

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

  Parameters3/5

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

  Schema coverage is 100% and each parameter already has a description. The tool description merely summarizes the parameters (width, height, background color, optional text, color, font size) without adding new semantic meaning or clarifying relationships beyond what the schema provides. This matches the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the tool generates a brand-new solid-color image, optionally with a centered label, and writes it to a specified path. It explicitly mentions use cases (mockups, spacers, test fixtures), which distinguishes it from sibling tools that manipulate existing images (resize, crop, etc.). The verb 'generate' and resource 'solid-color image' 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.

  Usage Guidelines3/5

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

  The description provides context by stating it is useful for mockups, spacer images, or test fixtures, which implies the appropriate scenarios. However, it does not explicitly contrast with sibling tools or provide exclusions (e.g., 'do not use for existing images' or 'use resize instead'). The guidance is implied but not explicit, so it meets a moderate bar.

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

• effectsA
  4/5.0
  Behavior4/5

  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 discloses that the source remains unchanged and output is written to a new file, states the return values (output path and effect applied), and warns that unknown effect names raise an error. It does not reveal edge cases like overwriting behavior for an existing output file, but the disclosed side effects and error handling are solid.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence followed by a bullet-style list of effects and their parameter usage. Every sentence earns its place: the core purpose, the side effect, the list of effects with parameter ties, the return values, and error behavior are all covered without fluff. It is front-loaded and easy to scan.

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

  Completeness4/5

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

  Given the tool's complexity (5 parameters, no output schema, no annotations), the description covers the essential operation: effects list, parameter associations, return behavior, and error handling. It does not address details like what happens when the output file already exists or supported image formats, but these are minor gaps given the schema covers parameter semantics and the description handles the core usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters including the purpose of 'factor' and 'radius'. The description adds a mapping between effects and parameters ('blur uses radius', 'contrast/brightness use factor'), but this is redundant with the schema's own descriptions. The description does not add meaningful new semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description states a specific verb 'Apply' with an explicit resource ('visual effect') and enumerates the exact effects (greyscale, sepia, invert, blur, sharpen, contrast, brightness). It clearly distinguishes from sibling tools (resize, crop, convert, etc.) by focusing on effects, and the phrasing 'apply a single visual effect' leaves no ambiguity about the tool's role.

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

  Usage Guidelines3/5

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

  The description implies usage when a visual effect is needed, but it does not explicitly state when NOT to use this tool or mention alternatives. It provides no guidance on selecting between sibling tools (e.g., convert for format changes vs. effects for filters), so the usage context is only implied rather than explicitly defined.

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

• flipA
  4/5.0
  Behavior4/5

  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 behavior. It explicitly states the source is unchanged and that a new file is created, which is crucial non-destructive behavior. It also mentions the return value (output path and axis used). It does not cover error handling or format constraints, but for a simple flip operation, these disclosures are sufficient.

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

  Conciseness5/5

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

  The description is exactly two sentences, front-loaded with the primary purpose and key guarantee (new file, source unchanged). It covers the axis parameter and the return value in a compact, scannable format. Every word adds value—there is no fluff or redundancy.

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

  Completeness4/5

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

  For a straightforward flip tool, the description is complete: it explains the operation, the source preservation, and what is returned. It does not mention supported image formats, file size limits, or error behavior, but these are minor for a tool of this complexity. The schema covers all parameters fully, and the description fills in the behavioral return value, making it sufficient for correct usage.

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

  Parameters3/5

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

  The schema has 100% coverage with clear descriptions for each parameter (path, out, axis), including the default for axis. The description adds no new parameter-specific information—it even repeats the axis semantics from the schema. Since coverage is high, the baseline of 3 applies; the description provides no additional semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('Mirror an image') and the key outcome ('write it to a NEW file (source unchanged)'). It distinguishes itself from sibling tools like rotate or resize by explicitly naming the operation and the axis options. This 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.

  Usage Guidelines3/5

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

  The description implies when to use the tool (whenever an image needs to be mirrored) but does not explicitly contrast it with alternatives like rotate or crop. It provides no exclusionary guidance (e.g., 'use this for flips, not rotations'), relying on the tool name and operation to convey intent. This is acceptable but not proactive in steering the agent.

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

• thumbnailA
  4/5.0
  Behavior4/5

  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 key side effect (source unchanged, new file created) and states the return value (output path and max-side constraint). This covers the main behavioral traits; it does not mention edge cases like whether it upscales if the source is smaller, but that is not critical for a preview tool.

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

  Conciseness5/5

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

  Two sentences with no redundancy. The first sentence front-loads the operation and core constraints; the second adds use case and return info. Every clause earns its place.

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

  Completeness4/5

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

  For a simple tool with full schema coverage, no output schema, and no annotations, the description covers operation, side effect, return value, and intended use. Minor gaps like behavior when the source is already smaller are acceptable and would not prevent correct invocation.

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

  Parameters3/5

  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 restates the size parameter's meaning (longest side) and adds aspect-ratio preservation, which is not in the schema. However, it doesn't significantly enhance parameter understanding beyond what the schema already provides.

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

  Purpose5/5

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

  States a specific operation (create downscaled preview) with the key constraint (max side, aspect ratio preserved) and explicitly mentions writing to a new file. The phrase 'downscaled preview' and 'NEW file' distinguishes it from potential siblings like resize or convert, even without naming them.

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

  Usage Guidelines3/5

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

  Mentions an intended use case ('Ideal for generating small previews or contact sheets') but provides no explicit exclusions or contrast with sibling tools such as resize. Usage is implied rather than explicitly routed, leaving the agent to infer when thumbnail is preferable.

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

• watermarkA
  4/5.0
  Behavior4/5

  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 does so well by explicitly stating that the source file is unchanged, that the label is drawn with an alpha channel for blending, and that it returns the output path and effective position. While it doesn't cover edge cases like invalid file formats or error handling, it covers the essential transmission-pertinent behaviors.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The first sentence front-loads the core action and the non-destructive write behavior; the second sentence lists configuration options, adds the alpha blending detail, and states the return value. It is concise yet complete.

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

  Completeness4/5

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

  For a tool with 8 parameters, no annotations, and no output schema, the description provides the essential context: what it does, how it treats the source, what it returns, and a summary of configurable options. It doesn't specify defaults for all parameters, but those are covered in the schema. The description is sufficiently complete for an agent to understand the tool's function and output without ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter already has a description in the schema. The tool description enumerates the parameters (position, color, opacity, font size, padding) and gives an example hex value, but it does not add substantial meaning beyond the schema. It repeats the opacity default but omits other defaults like position and padding, which are available in the schema. This is adequate but not enhancing.

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

  Purpose5/5

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

  The description states a specific verb ('burn a text label onto an image'), resource (image), and a distinct behavior (writes to a NEW file, source unchanged). This clearly distinguishes it from the sibling 'overlay' tool, which would typically overlay another image. The mention of configurable placement, color, opacity, font size, and padding further narrows the purpose.

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

  Usage Guidelines3/5

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

  Usage is implied — the description makes it obvious this is for adding text watermarks — but it does not explicitly state when to prefer this over the sibling 'overlay' tool or when not to use it. There is no mention of alternatives or exclusion criteria, so the agent must infer from the nature of the tool.

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

• convertA
  4.2/5.0
  Behavior4/5

  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 non-destructive behavior (source unchanged), alpha flattening onto white for non-transparent formats, and the return value (output path and final format). This is substantial, though it doesn't cover error cases or overwrite semantics, which are minor for this simple tool.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds specific critical details (format inference, alpha handling, return) without repetition or filler. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple conversion tool with no output schema or annotations, the description covers the key aspects: purpose, input/output, behavioral quirks, and result. It lacks details on error scenarios or handling of existing output files, but these are not essential for basic invocation. The description is complete enough 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.

  Parameters4/5

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

  Schema covers all parameters (100% coverage), so baseline is 3. The description adds value beyond the schema by explaining the inference of format from the output extension and the alpha-flattening behavior tied to format choice. This enriches understanding of 'format' and 'out' parameters, pushing slightly above baseline.

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

  Purpose5/5

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

  States a specific verb ('Change an image's file format') and resource (image), with the outcome of writing to a NEW file and source unchanged. Clearly differentiates from siblings like resize/crop by focusing on format conversion. The purpose is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage (format conversion) but does not explicitly contrast with alternatives or state when to use this over siblings. No 'when to use' or 'when not to use' guidance is provided. It's clear from the name and purpose, but not explicit.

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

• resizeA
  4.4/5.0
  Behavior5/5

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

  With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It explicitly states that the source is never overwritten, explains aspect ratio computation, details each fit mode's consequences (crop, aspect ratio change), and mentions the return value (output path and dimensions). This is comprehensive for a resize operation.

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

  Conciseness5/5

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

  Two sentences with dense, relevant information. The key side effect (new file) is front-loaded, and the fit modes are explained efficiently. No wasted words or redundant phrasing.

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

  Completeness4/5

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

  For a straightforward resize tool with no output schema, the description covers the essential information: dimension specification, fit behavior, and the return value. It does not address edge cases like omitting both width and height, but that is a minor gap given the tool's simplicity.

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

  Parameters3/5

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

  The schema covers all parameters with descriptions, so the baseline is 3. The description adds some clarity by explaining the interaction between width and height and elaborating on fit modes, but it largely repeats the schema content. It does not provide substantial new information beyond what the schema already documents.

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

  Purpose5/5

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

  The description clearly states the action (resize an image), the resource (image), and the key side effect (writing to a new file, never overwriting the source). It distinguishes from siblings like crop or convert by specifying resizing behavior and preserving aspect ratio. No ambiguity in the tool's function.

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

  Usage Guidelines4/5

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

  Provides explicit instructions on how to specify dimensions (width and/or height) with the aspect-ratio-preservation logic, and explains each fit mode's behavior. However, it does not mention when to prefer this tool over siblings like crop or thumbnail, so it lacks explicit alternative guidance.

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

• cropA
  4.5/5.0
  Behavior4/5

  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 explicitly states that the source is unchanged, that coordinates are automatically clamped, and that the return value includes the output path and actual box. This is thorough for a crop operation. It does not cover edge cases like invalid image files or zero dimensions, but those are minor given the safe clamping behavior and typical tool expectations.

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

  Conciseness5/5

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

  Two sentences with no waste. The purpose and non-destructive nature are front-loaded, followed by the coordinate semantics and a safety note. Every sentence adds essential information; there is no filler.

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

  Completeness5/5

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

  The description is complete for a 6-parameter tool with no output schema and no annotations. It covers the operation, parameters, edge-case handling (clamping), and return value. An agent has everything needed to invoke the tool correctly without additional lookup.

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

  Parameters4/5

  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 value beyond the schema by explaining that x,y define the top-left corner, width/height define size, and that clamping applies. It also specifies the return value (output path and actual box), which is not in the schema. This extra context justifies a score above baseline.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Extract a rectangular sub-region and write it to a NEW file'), immediately distinguishing it from sibling tools like resize, rotate, or compress. It also highlights the non-destructive behavior, which is the key differentiator from in-place editing tools. The phrasing is unambiguous and precisely identifies 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.

  Usage Guidelines4/5

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

  The description clearly implies when to use the tool (when you need a rectangular sub-region) and provides a safety hint via clamping behavior. However, it does not explicitly name alternatives or give exclusion criteria (e.g., 'use resize instead to scale the whole image'). The context is clear but lacks direct routing to siblings, so it earns a 4 rather than a 5.

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

• infoA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so well. It declares 'Read-only' upfront and explicitly states 'Never writes to or modifies the source file,' plus it enumerates the exact output fields. This fully discloses behavioral expectations.

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

  Conciseness5/5

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

  Two sentences with zero filler. The purpose is front-loaded ('Read-only metadata inspector'), followed by the output list and usage guidance. Every word earns its place.

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

  Completeness5/5

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

  For a simple metadata lookup with one parameter and no output schema, the description fully covers what the tool returns, when to use it, and that it is non-destructive. Nothing an agent needs to call it correctly is missing.

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

  Parameters3/5

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

  The single parameter 'path' is fully described in the schema (100% coverage). The description adds no extra semantics beyond the schema's note about absolute or relative path, so it meets the baseline but doesn't exceed it.

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

  Purpose5/5

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

  The description clearly states it is a read-only metadata inspector and lists the specific fields returned (absolute path, format, width, height, color mode, file size). It differentiates from sibling manipulation tools by being informational, not transformative.

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

  Usage Guidelines4/5

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

  It explicitly says 'Use it first to learn an image's dimensions or mode before resizing, cropping, or converting,' giving clear context for when to call it ahead of other operations. It doesn't enumerate alternatives, but the implication is strong enough for an agent to select it correctly.

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

• overlayA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently states that output is written to a new file, sources remain untouched, alpha channel is respected, opacity is configurable, and it returns the output path and offset. This is comprehensive for a compositing tool.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose and a key safety caveat (new file). Every clause adds value; no redundancy or filler.

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

  Completeness5/5

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

  Even without an output schema, the description explicitly states the return value (output path and offset) and covers the essential behavior needed to invoke the tool correctly. For a straightforward image overlay with this parameter set, nothing critical is missing.

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

  Parameters3/5

  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 (base, overlay, out, x, y, opacity). The description adds contextual flavor (offset placement, alpha mix) but does not materially exceed schema details; baseline 3 is appropriate.

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

  Purpose5/5

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

  States a specific verb ('composite'), the resources (images), and the result (new file, sources unchanged). Clearly distinguishes from siblings like watermark and resize by detailing the overlay placement and opacity behavior.

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

  Usage Guidelines4/5

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

  Provides explicit use cases ('logos, badges, or layering') that help an agent decide when to apply this tool. Does not explicitly exclude alternative tools (e.g., watermark), but the context is strong enough to guide selection.

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

• rotateA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does it thoroughly. It discloses that the source is untouched, the output is a new file, the effect of expand on canvas clipping, and what the tool returns (output path and angle applied). This goes beyond typical descriptions and covers the main behavioral expectations.

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

  Conciseness5/5

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

  Three sentences, each carrying distinct information: core action, expand behavior, and return value. The most critical detail (new file, source unchanged) is front-loaded. No filler or redundancy.

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

  Completeness5/5

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

  For a 4-parameter tool with no output schema, the description covers what the tool does, how parameters behave, and what it returns. It explains the default expand behavior and its trade-off. There's nothing an agent needs to know to use it correctly that's omitted, except perhaps error handling, which is not typically required.

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

  Parameters4/5

  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 value beyond the schema by explaining the consequence of expand=true vs false (no clipping vs cropping overflow) which the schema states but less concretely. It also clarifies the return includes the angle applied, which isn't in the schema. However, it doesn't elaborate on 'degrees' beyond the schema's clockwiseness, so it's not a full 5.

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

  Purpose5/5

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

  The description opens with a clear verb and resource ('Rotate an image clockwise by a number of degrees') and immediately states the key behavior of writing to a NEW file while leaving the source unchanged. It also names the expand behavior, distinguishing it from sibling image operations by its non-destructive nature. 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.

  Usage Guidelines3/5

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

  The description provides clear context for the expand parameter (default true means enlarged canvas, false crops) but doesn't explicitly state when to prefer this tool over siblings like resize, crop, or flip. There's no 'use this when...' or comparison to alternatives, leaving the agent to infer usage from the operation name.

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

• compressA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility. It discloses the side-effect (new file, source untouched), the quality/format behavior, and the return payload (output path plus size metrics). This goes well beyond what a bare schema would convey and fully informs the agent of operational consequences.

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

  Conciseness5/5

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

  Two sentences, no fluff. The most critical information (source unchanged, new file) is front-loaded, and the rest is packed efficiently. Every clause earns its place.

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

  Completeness5/5

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

  Given no output schema, the description appropriately details the return values (output path, bytes_before/after, saved_percent). It also covers defaults for quality and format, making the tool fully callable without extra research.

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

  Parameters4/5

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

  Though schema coverage is 100%, the description adds meaningful semantics: quality scale (1-100) and its effect on file size, default format (JPEG) and the transparency hint for PNG/WEBP. This exceeds the schema's generic parameter descriptions and helps the agent choose appropriate values.

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

  Purpose5/5

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

  Clearly states the verb 're-encode' with the resource 'image', the purpose 'reduce file size', and a key differentiator: writes to a NEW file, preserving the source. This distinguishes it from siblings like convert, resize, or rotate without needing to inspect their schemas.

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

  Usage Guidelines4/5

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

  The description explicitly ties use to reducing file size and explains the quality/format behavior. It does not explicitly contrast with alternatives (e.g., when to use compress vs convert), but the purpose is clear enough for an agent to infer appropriate usage. Minor gap: no explicit 'use when' or 'use instead' guidance.

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