Server Quality Checklist

Tool Scores

• delete_projectC
  2/5.0
  Behavior1/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 but fails completely. 'Delete a project' implies a destructive, irreversible mutation, but the description doesn't confirm this, mention any confirmation prompts, warn about cascading effects (e.g., deleting associated frames/layers), specify permission requirements, or describe what happens on success/failure. For a destructive tool with zero annotation coverage, this is dangerously inadequate.

  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 maximally concise at three words with zero wasted text. It's front-loaded with the core action and resource, though this brevity comes at the cost of completeness. Every word earns its place by conveying the essential operation, making it structurally efficient despite its informational deficiencies.

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

  Completeness1/5

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

  For a destructive mutation tool with no annotations and no output schema, the description is severely incomplete. It doesn't address critical context: the irreversible nature of deletion, potential side effects, required permissions, error conditions, or what the tool returns (e.g., success confirmation or error message). Given the high-stakes nature of deletion operations, this minimal description fails to provide adequate guidance.

  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 input schema has 100% description coverage with a single parameter 'projectId' documented as 'Project identifier'. The description adds no parameter semantics beyond what the schema already provides—it doesn't explain format requirements, where to obtain the ID, or validation rules. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose2/5

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

  The description 'Delete a project' is a tautology that essentially restates the tool name without adding meaningful context. While it correctly identifies the verb ('Delete') and resource ('project'), it doesn't distinguish this from sibling tools like 'remove_frame' or 'remove_layer' that also perform deletion operations on different resources. The description lacks specificity about what constitutes a 'project' in this context.

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

  Usage Guidelines1/5

  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. There's no mention of prerequisites (e.g., whether the project must exist, be empty, or have specific permissions), no indication of when NOT to use it (e.g., irreversible consequences), and no reference to related tools like 'list_projects' for identification or 'create_project' for creation. The agent receives zero contextual guidance.

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

• get_project_infoC
  2.6/5.0
  Behavior2/5

  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 this is a read operation ('Get information'), which implies it's non-destructive, but doesn't cover other aspects like authentication needs, rate limits, error conditions, or what the return format looks like (e.g., JSON structure). This leaves significant gaps for a tool with no 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.

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words, making it appropriately sized and front-loaded. However, it's overly concise to the point of under-specification, lacking necessary details for a tool with no annotations or output schema, which slightly reduces its effectiveness.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what information is returned (e.g., project metadata, settings), potential errors, or how it fits into the broader context of sibling tools. For a read operation with no structured output, more detail is needed to guide the agent effectively.

  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 input schema has 100% description coverage, with 'projectId' clearly documented as 'Project identifier'. The description adds no additional meaning beyond this, such as format examples (e.g., numeric ID, string) or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'Get information about a project' states a clear verb ('Get') and resource ('project'), but it's vague about what specific information is retrieved. It distinguishes from siblings like 'create_project' or 'delete_project' by being a read operation, but doesn't specify what makes it different from other read tools like 'list_projects' or 'get_frame_data'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project ID), exclusions, or compare it to siblings like 'list_projects' for listing all projects versus getting details for a specific one. Usage is implied only by the tool name and parameter.

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

• draw_pixelsC
  2.7/5.0
  Behavior1/5

  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. 'Draw' implies a write/mutation operation, but the description doesn't specify whether this requires authentication, what happens if pixels overlap existing content, whether the operation is reversible, or any rate limits. It lacks essential context for safe and effective use.

  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, efficient sentence with zero wasted words. It's front-loaded with the core action and immediately clarifies the batch nature of the operation. Every part of the sentence earns its place by distinguishing from 'draw_pixel'.

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

  Completeness2/5

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

  Given the complexity of a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'drawing' entails (e.g., setting pixel colors), the expected return value, error conditions, or how it interacts with sibling tools. For a tool that modifies data, this leaves critical gaps in understanding.

  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%, with all parameters documented in the schema itself. The description adds no additional meaning beyond implying 'multiple pixels' relates to the 'pixels' array parameter. Since the schema already fully describes parameters, the baseline score of 3 is appropriate—the description doesn't enhance parameter understanding but doesn't detract either.

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

  Purpose4/5

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

  The description clearly states the action ('draw') and resource ('pixels') with the qualifier 'multiple...at once', which distinguishes it from the sibling tool 'draw_pixel'. However, it doesn't specify what system or context these pixels belong to (e.g., a graphics project, canvas, or animation), leaving some ambiguity about the exact resource being modified.

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

  Usage Guidelines2/5

  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. With siblings like 'draw_pixel', 'draw_circle', 'draw_line', 'draw_rectangle', and 'fill_area', there's no indication of when batch pixel drawing is preferred over single-pixel operations or other drawing primitives, nor any mention of prerequisites or constraints.

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

• duplicate_frameC
  2.7/5.0
  Behavior2/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 states the action ('duplicate') but does not explain what duplication involves (e.g., whether it copies pixel data, layers, or metadata), potential side effects (e.g., reindexing of frames), or any constraints (e.g., permissions, rate limits). This is a significant gap for a mutation 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.

  Conciseness5/5

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

  The description is a single, efficient sentence ('Duplicate a frame') with no wasted words. It is front-loaded and appropriately sized for the tool's apparent simplicity, making it highly concise and well-structured.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It does not address what the tool returns (e.g., the new frame's index or data), behavioral details, or usage context. For a mutation tool with two parameters, this minimal description fails to provide sufficient context for effective agent use.

  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 input schema has 100% description coverage, with parameters 'projectId' and 'frameIndex' clearly documented. The description does not add any meaning beyond the schema (e.g., it does not clarify what 'frameIndex' refers to or how duplication affects indices). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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

  Purpose3/5

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

  The description 'Duplicate a frame' states the action (duplicate) and resource (frame), which provides basic purpose clarity. However, it lacks specificity about what duplication entails (e.g., copying content, metadata, or both) and does not distinguish it from sibling tools like 'add_frame' or 'remove_frame', making it vague rather than precise.

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

  Usage Guidelines2/5

  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. It does not mention prerequisites (e.g., existing frames), exclusions, or comparisons to siblings like 'add_frame' (which might create a new frame from scratch) or 'remove_frame', leaving the agent 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.

• add_frameC
  2.9/5.0
  Behavior2/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 states 'Add a new frame' but doesn't clarify if this is a mutation (likely yes), what permissions are needed, how it affects existing frames/layers, or what the response looks like. This leaves critical behavioral traits unspecified for a tool that appears to modify project state.

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

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

  Completeness2/5

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

  Given the complexity of a tool that likely modifies project state (adding frames to layers), the lack of annotations and output schema means the description should provide more context. It doesn't explain what a 'frame' entails in this system, how the addition affects the project, or what happens upon success/failure, making it incomplete for safe and effective use.

  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 input schema has 100% description coverage, with clear documentation for both parameters ('projectId' and 'layerIndex'). The description adds no additional meaning beyond what the schema provides, such as explaining what a 'frame' is or how 'layerIndex' interacts with the layer structure. This meets the baseline score of 3 given the high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and the resource ('a new frame to a layer'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'duplicate_frame' or 'remove_frame', which would require more specific context about what makes 'add_frame' unique.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project or layer), exclusions, or comparisons to siblings like 'duplicate_frame' or 'clear_frame', leaving the agent with minimal context for selection.

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

• add_layerC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states 'Add a new layer' which implies a write/mutation operation, but doesn't disclose behavioral traits like permission requirements, whether the operation is idempotent, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is inadequate.

  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, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'adding a layer' entails (e.g., default properties, position in layer stack), success/failure behavior, or return values. For a tool that modifies state, more context is needed.

  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 both parameters (projectId and layerName). The description doesn't add any meaning beyond what the schema provides—it doesn't explain layer naming conventions, projectId format, or parameter interactions. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and resource ('a new layer to the project'), making the purpose understandable. It doesn't explicitly differentiate from siblings like 'create_project' or 'remove_layer', but the verb+resource combination is specific enough for basic understanding.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to sibling tools like 'create_project' or 'duplicate_frame', leaving the agent 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.

• clear_frameC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this is destructive (likely yes, but not stated), whether it requires specific permissions, what happens to transparency/alpha channels, or what the visual outcome looks like. For a pixel modification tool with zero annotation coverage, this is insufficient behavioral disclosure.

  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, efficient sentence with zero wasted words. It's front-loaded with the core action and immediately communicates the essential purpose without unnecessary elaboration. This is model conciseness for a straightforward operation.

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

  Completeness2/5

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

  For a tool that modifies visual data with 3 parameters and no annotations or output schema, the description is too minimal. It doesn't explain what 'clear' means technically (set to transparent? set to black?), doesn't mention coordinate systems or bounds, and provides no information about return values or side effects. The context demands more completeness than provided.

  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 three parameters adequately. The description doesn't add any parameter-specific context beyond what's in the schema (like explaining coordinate systems, layer/frame hierarchy, or default behavior implications). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Clear all pixels') and target resource ('in a frame'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'erase_pixel' or 'fill_area' which also modify pixel data, but the verb+resource combination is specific enough for basic understanding.

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

  Usage Guidelines2/5

  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 like 'erase_pixel' (for selective clearing) or 'fill_area' (for clearing with color). There's no mention of prerequisites, typical workflows, or contextual constraints that would help an agent choose appropriately among sibling drawing/modification tools.

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

• create_projectC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a project but doesn't mention any behavioral traits: whether it's idempotent, what happens on duplicate projectId, if it requires specific permissions, what the response contains, or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

  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, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse. Every word earns its place by conveying the essential action and resource.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation with 4 parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a project object, error handling), behavioral traits, or usage context. For a create tool with no structured support, more detail is needed to be fully helpful to an agent.

  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 description adds no parameter semantics beyond what the input schema provides. With 100% schema description coverage, the schema already documents all four parameters clearly (projectId, width, height, name). The baseline is 3 since the schema does the heavy lifting, and the description doesn't compensate with additional context like default values or constraints.

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

  Purpose4/5

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

  The description clearly states the action ('create') and resource ('new pixel art project'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'delete_project' or 'list_projects' by specifying creation. However, it doesn't explicitly differentiate from other creation-like tools (none exist in the sibling list), so it doesn't reach the highest level of sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether projects must be unique), when not to use it (e.g., for updating existing projects), or refer to related tools like 'list_projects' for context. The agent must infer usage from the tool name alone.

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

• draw_circleC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'outline or filled' which hints at the filled parameter's effect, but doesn't describe what happens when drawing occurs (e.g., whether it overwrites existing pixels, requires specific permissions, has performance implications, or returns any confirmation). For a mutation tool with 10 parameters, this is inadequate.

  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 extremely concise - a single parenthetical phrase that efficiently communicates the core functionality. Every word earns its place by specifying both the shape type and the fill/outline options. No wasted words or redundant information.

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

  Completeness2/5

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

  For a drawing/mutation tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (success/failure, the drawn object, nothing?), doesn't mention error conditions, and provides minimal behavioral context. The agent would struggle to use this effectively without trial and error.

  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 thoroughly. The description adds minimal value beyond the schema - it implies the shape type and fill behavior, but doesn't explain coordinate systems, color formats, or layer/frame context beyond what's in the parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

  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 object ('circle/ellipse'), including whether it's outline or filled. It distinguishes from siblings like draw_line and draw_rectangle by specifying the shape type. However, it doesn't explicitly mention the bounding box approach, which is a key differentiator from other drawing tools.

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

  Usage Guidelines2/5

  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. The description doesn't mention when to choose draw_circle over draw_pixel, draw_line, or draw_rectangle, nor does it specify prerequisites like needing an existing project or layer. The agent must infer usage from parameter names alone.

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

• draw_lineC
  2.9/5.0
  Behavior2/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 states the action ('Draw') but doesn't cover critical aspects like whether this is a mutation (likely yes), permissions needed, side effects (e.g., modifying a project), or error conditions. The description lacks behavioral context beyond the basic action.

  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, efficient sentence with zero waste—'Draw a line between two points' is front-loaded and directly conveys the core purpose without unnecessary elaboration.

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

  Completeness2/5

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

  Given the complexity (a mutation tool with 9 parameters, no annotations, and no output schema), the description is inadequate. It doesn't explain the context (e.g., that it modifies a project in a drawing/animation system), behavioral traits, or what happens on success/failure, leaving significant gaps for an AI agent.

  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 9 parameters. The description adds no parameter-specific information beyond implying coordinates (x0, y0, x1, y1) for 'two points'. This meets the baseline of 3 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.

  Purpose4/5

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

  The description 'Draw a line between two points' clearly states the action (draw) and resource (line), with 'between two points' specifying the geometric operation. It distinguishes from siblings like draw_circle or draw_rectangle by focusing on lines, though it doesn't explicitly contrast with them.

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

  Usage Guidelines2/5

  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 draw_pixel or draw_rectangle, nor any context about prerequisites (e.g., needing an existing project). The description implies usage for line drawing but offers no explicit when/when-not instructions.

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

• draw_pixelC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. 'Draw a single pixel' implies a write/mutation operation but doesn't disclose behavioral traits like whether it overwrites existing pixels, requires specific permissions, or has side effects. It lacks context on what 'draw' entails operationally.

  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, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.

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

  Completeness2/5

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

  For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'draw' does behaviorally, what happens on success/failure, or how it interacts with other tools. More context is needed given the complexity and lack of structured data.

  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 6 parameters. The description adds no additional meaning beyond implying that parameters define where and how to draw the pixel, which is already covered by the schema. Baseline 3 is appropriate as the schema handles parameter semantics.

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

  Purpose4/5

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

  The description 'Draw a single pixel' clearly states the action (draw) and resource (pixel), making the purpose immediately understandable. It distinguishes from siblings like draw_circle, draw_line, and draw_pixels by specifying a single pixel, though it doesn't explicitly contrast with these alternatives.

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

  Usage Guidelines2/5

  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 like draw_pixels (for multiple pixels) or erase_pixel (for removal). It also doesn't mention prerequisites such as needing an existing project or layer, leaving usage context unclear.

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

• draw_rectangleC
  2.9/5.0
  Behavior2/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 mentions the rectangle can be outline or filled, which hints at visual output, but fails to describe what the tool actually does (e.g., modifies a project's visual layer, may require specific permissions, or has side effects like overwriting existing content). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

  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, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized for a straightforward drawing tool 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.

  Completeness2/5

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

  Given the tool's complexity (10 parameters, mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or the visual context (e.g., coordinate system units). For a drawing tool that likely modifies project state, more behavioral and output details are needed to guide an agent effectively.

  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 10 parameters thoroughly. The description adds minimal value beyond the schema by implying the rectangle's visual style (outline or filled), but doesn't provide additional context like coordinate systems, color formats beyond hex, or interaction with other parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('draw') and resource ('rectangle') with additional detail about outline or filled options. It distinguishes from siblings like draw_circle, draw_line, and draw_pixel by specifying the shape type, but doesn't explain how it differs from other drawing tools in terms of functionality or use cases.

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

  Usage Guidelines2/5

  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 like draw_circle or draw_line, nor does it mention prerequisites (e.g., needing an existing project or layer). It lacks context about typical scenarios or constraints, leaving the agent to infer usage from parameter names alone.

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

• erase_pixelC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic effect ('set to transparent'). It doesn't mention permissions needed, whether the operation is destructive (implied by 'erase'), rate limits, or what happens on success/failure. For a mutation tool, this is inadequate.

  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?

  Extremely concise with a single, clear sentence that front-loads the core action. Every word earns its place with no wasted text.

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

  Completeness2/5

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

  For a mutation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value, error conditions, or behavioral nuances like whether erasing is undoable or affects multiple frames/layers.

  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 parameters are well-documented in the schema. The description adds no additional parameter context beyond implying 'penSize' relates to eraser size, which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Erase pixels') and the effect ('set to transparent'), which is specific and distinguishes it from drawing tools. However, it doesn't explicitly differentiate from 'clear_frame' or 'fill_area' which might also affect transparency.

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

  Usage Guidelines2/5

  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 'clear_frame' (which clears an entire frame) or 'fill_area' (which might fill with transparency). The description only states what it does, not when it's appropriate.

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

• export_gifC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool exports an animated GIF but does not mention critical behaviors like whether it overwrites existing files, requires specific project states, has performance implications, or handles errors. This leaves significant gaps for a tool that likely involves file I/O and processing.

  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 extremely concise with a single, front-loaded phrase ('Export as animated GIF') that directly conveys the core purpose without any wasted words. It is appropriately sized for a straightforward tool.

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

  Completeness2/5

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

  Given the tool has no annotations and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., success status, file path), error conditions, or behavioral details like file overwriting. For a tool with 3 parameters and potential side effects, this lacks necessary context for safe and effective use.

  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 (projectId, outputPath, frameDelay) with descriptions. The description adds no additional meaning beyond implying animation via 'animated GIF', which relates to frameDelay but does not elaborate on parameter interactions or constraints beyond the schema.

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

  Purpose4/5

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

  The description clearly states the action ('Export') and the output format ('animated GIF'), which is specific and unambiguous. However, it does not explicitly distinguish this tool from its sibling 'export_png' or 'export_sprite_sheet', which would require mentioning format differences or use cases.

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

  Usage Guidelines2/5

  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 like 'export_png' or 'export_sprite_sheet'. It lacks context about prerequisites, such as needing an existing project with frames, or exclusions, like not being suitable for static images.

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

• export_pngC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool exports a frame, implying a read operation that generates a file, but lacks details on permissions, file overwriting behavior, error conditions, or output specifics. This is inadequate for a tool with file system impact.

  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, efficient sentence with zero wasted words. It is appropriately sized and front-loaded, directly stating the tool's core function without unnecessary elaboration.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, and file system interaction, the description is insufficient. It doesn't explain what 'export' entails (e.g., file creation, format details), error handling, or dependencies on other tools. Given the complexity, more context is needed for safe and effective use.

  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 three parameters (projectId, frameIndex, outputPath). The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high coverage.

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

  Purpose4/5

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

  The description 'Export a frame as PNG' clearly states the action (export) and resource (frame), specifying the output format (PNG). It distinguishes from sibling tools like export_gif and export_sprite_sheet by naming the PNG format, but doesn't explicitly differentiate from other export tools beyond format.

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

  Usage Guidelines2/5

  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 like export_gif or export_sprite_sheet. It doesn't mention prerequisites (e.g., needing an existing project/frame) or contextual constraints, leaving usage entirely implicit.

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

• export_sprite_sheetC
  2.9/5.0
  Behavior2/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 mentions exporting frames as a PNG, implying a write operation, but lacks details on permissions, file overwriting behavior, error handling, or output format specifics. This is insufficient for a mutation 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of a file export operation with no annotations and no output schema, the description is incomplete. It does not address critical aspects like what happens if the output path exists, error conditions, or the structure of the sprite sheet. More detail is needed for adequate contextual understanding.

  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. The description does not add any additional meaning or context beyond what the schema provides, such as explaining how 'columns' affects layout or default values. Baseline 3 is appropriate when the schema handles parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('Export') and the resource ('all frames as a sprite sheet PNG'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'export_gif' or 'export_png', which would be needed for a score of 5.

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

  Usage Guidelines2/5

  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 like 'export_gif' or 'export_png', nor does it mention any prerequisites or context for usage. It merely states what the tool does without indicating appropriate scenarios.

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

• get_pixelC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify permissions, rate limits, or what happens with invalid coordinates. The description lacks details on return format (e.g., color representation) or error handling.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'color' means (e.g., RGB values, hex code), potential errors, or how it interacts with layers/frames. For a tool with 5 parameters and no structured output, more context is needed.

  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. The description adds no additional meaning beyond implying coordinates (x, y) are used to locate the pixel, which is already clear from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description 'Get the color of a pixel' clearly states the action (get) and resource (color of a pixel), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_frame_data' or 'get_project_info', which also retrieve information but about different resources.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project), exclusions, or comparisons to similar tools like 'get_frame_data' for broader data retrieval.

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

• remove_frameC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'remove' implies a destructive mutation, the description doesn't specify whether this operation is reversible, what happens to frame data, whether it affects animation timing, or any permission requirements. It provides minimal behavioral context beyond the basic action.

  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, efficient sentence with zero wasted words. It's appropriately sized for a simple operation and gets straight to the point without unnecessary elaboration.

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

  Completeness2/5

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

  For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'remove from all layers' means operationally, what the tool returns, whether indices shift after removal, or any error conditions. Given the complexity of frame manipulation in animation/graphics contexts, more context is needed.

  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%, providing complete parameter documentation. The description doesn't add any additional meaning about parameters beyond what the schema already states. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('remove') and target resource ('a frame from all layers'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'clear_frame' or 'duplicate_frame', which also operate on frames.

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

  Usage Guidelines2/5

  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. The description doesn't mention prerequisites, consequences, or when this operation is appropriate compared to similar frame-manipulation tools in the sibling list.

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

• remove_layerC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is destructive ('Remove'), but doesn't clarify if this is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting other layers). For a mutation tool with zero annotation coverage, this leaves significant gaps.

  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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding the purpose.

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

  Completeness2/5

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

  For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It lacks critical context about behavioral traits (e.g., permanence, permissions), usage guidelines relative to siblings, and expected outcomes. The high schema coverage doesn't compensate for these gaps in a tool that modifies state.

  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%, with both parameters clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides about 'projectId' or 'layerIndex', so it meets the baseline for high schema coverage without compensating value.

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

  Purpose4/5

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

  The description clearly states the action ('Remove') and the target ('a layer from the project'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'remove_frame' or 'delete_project', but the specificity of 'layer' vs 'frame' or 'project' provides implicit distinction.

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

  Usage Guidelines2/5

  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 'remove_frame' or 'delete_project'. The description only states what it does, not when it's appropriate or what prerequisites might exist (e.g., whether the layer must exist or be unlocked).

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

• get_frame_dataB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, has rate limits, or what happens with invalid inputs. For a tool with zero annotation coverage, this is a significant gap in transparency.

  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, efficient sentence that front-loads the core purpose ('Get all pixel data from a frame as a 2D array'). It has zero waste, with every word contributing directly to understanding the tool's function.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on return format (e.g., array structure), error handling, or prerequisites. For a data retrieval tool with three parameters, it should provide more context to be fully complete.

  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 three parameters (projectId, layerIndex, frameIndex) with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the 2D array structure or default values. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('pixel data from a frame'), specifying it returns a 2D array. It distinguishes from siblings like get_pixel (single pixel) and get_project_info (metadata), but doesn't explicitly contrast them. The purpose is specific but lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives is provided. It doesn't mention when to choose get_frame_data over get_pixel for single pixels or other data retrieval tools. The description implies usage for bulk pixel data but offers no explicit context or exclusions.

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

• list_projectsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose if it's read-only, paginated, returns structured data, has rate limits, or requires specific permissions, which are critical for a list 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?

  The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

  Completeness2/5

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

  For a list tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'active' means, the return format, or any behavioral constraints, leaving significant gaps for the agent to operate effectively.

  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?

  The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline high score for not adding unnecessary information.

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

  Purpose4/5

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

  The description clearly states the action ('List') and target resource ('all active projects'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get_project_info', but it's not vague or tautological.

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

  Usage Guidelines2/5

  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 like 'get_project_info' or 'create_project'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage.

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

• fill_areaB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether the fill is destructive (overwrites existing pixels), requires specific permissions, has rate limits, or what happens on success/failure. The 'paint bucket' metaphor hints at mutation but isn't explicit 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—every word ('fill', 'connected area', 'color', 'paint bucket') contributes to understanding the tool's purpose. It's appropriately sized 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.

  Completeness3/5

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

  For a mutation tool with no annotations and no output schema, the description is minimally adequate but lacks completeness. It covers the basic purpose but misses behavioral context (e.g., side effects, error conditions) and output expectations. Given the complexity of a fill operation with 6 parameters, more guidance would be helpful.

  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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'connected area' relates to x/y coordinates and color, but doesn't clarify fill boundaries, tolerance, or interaction with existing pixels. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('fill a connected area'), resource ('area'), and tool metaphor ('paint bucket'), distinguishing it from sibling drawing tools like draw_pixel, draw_line, or draw_rectangle which perform different operations. It precisely communicates the tool's function without ambiguity.

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

  Usage Guidelines2/5

  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 like draw_pixels for manual coloring or clear_frame for erasing. It lacks context about prerequisites (e.g., needing an existing project/layer/frame) or exclusions, leaving the agent to infer usage from parameter names alone.

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