SVG Canvas MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as draw_circle vs. draw_rect or layer_create vs. layer_delete. However, some overlap exists in AI suggestion tools (e.g., ai_align_objects and ai_suggest_layout might be confused for layout-related tasks), and path creation tools (path_create, path_lineto, etc.) could be ambiguous without careful reading of descriptions.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear verb_noun or category_verb_noun structures throughout, such as draw_circle, layer_create, and export_png. All tools adhere to this convention, making them predictable and easy to parse for agents.
Tool Count2/5
With 79 tools, the count is excessive for a single server, likely overwhelming for agents and leading to confusion or inefficiency. While SVG editing is a broad domain, this many tools suggests over-fragmentation, such as separate tools for each shape type or path command, rather than consolidation.
Completeness5/5
The tool set provides comprehensive coverage for SVG canvas operations, including drawing, styling, layering, animation, export, history, and templates. It supports full CRUD/lifecycle management for objects, layers, and symbols, with no obvious gaps in core functionality for the domain.
Average 2.8/5 across 79 of 79 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 provides none. It doesn't indicate whether this creates a new graphical element, modifies an existing one, requires specific context (like an active canvas), has side effects, or what happens after drawing. For a tool with 7 parameters and no annotation coverage, this is a critical gap in behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single 3-word phrase), this represents under-specification rather than effective conciseness. The description doesn't front-load important information and fails to provide the minimal context needed for tool selection. A truly concise description would still include essential differentiating information.
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 tool with 7 parameters, no annotations, no output schema, and multiple similar sibling tools, the description is completely inadequate. It provides no behavioral context, no usage guidance, no differentiation from alternatives, and relies entirely on the schema for parameter documentation. The description fails to address the complexity of the tool's context.
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 information beyond what's already in the schema, which has 100% description coverage. All 7 parameters (points, fill, stroke, strokeWidth, opacity, id, class) are documented in the schema with clear descriptions. The baseline score of 3 reflects adequate parameter documentation entirely through the schema, with no added value from the description.
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 '다각형을 그립니다' (Draws a polygon) is a tautology that restates the tool name 'draw_polygon' without providing additional specificity. It doesn't distinguish this tool from sibling drawing tools like draw_circle, draw_rect, or draw_regular_polygon, nor does it clarify what makes a polygon different from a polyline or other shapes.
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 absolutely no guidance on when to use this tool versus alternatives. With multiple sibling drawing tools available (draw_circle, draw_rect, draw_polyline, draw_regular_polygon, etc.), there's no indication of when a polygon is appropriate versus other shape types or what distinguishes this tool from draw_polyline or draw_regular_polygon.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '텍스트를 추가합니다' only states the action without any behavioral details: it doesn't mention whether this is a read-only or destructive operation, what happens to existing elements, if there are side effects (e.g., adding to a layer), or any performance/rate limits. For a tool with 14 parameters and no annotations, this is a critical 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 extremely concise—a single phrase—with zero wasted words. It is front-loaded and efficiently states the core action, though this brevity comes at the cost of completeness. For conciseness alone, it scores perfectly as it avoids redundancy and is straightforward.
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?
Given the tool's complexity (14 parameters, no annotations, no output schema), the description is severely incomplete. It fails to explain what the tool does in context (e.g., adding text to a drawing), behavioral aspects, usage scenarios, or output expectations. The agent would struggle to use this tool effectively based solely on the description, making it inadequate for the tool's requirements.
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 all 14 parameters clearly documented in the schema itself (e.g., 'X 좌표' for x, '텍스트 내용' for text). The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 '텍스트를 추가합니다' (Adds text) is a tautology that essentially restates the tool name 'draw_text' without providing meaningful context. It doesn't specify what resource or context text is being added to (presumably a drawing/canvas), nor does it distinguish this from sibling tools like 'draw_circle' or 'draw_rect' beyond the obvious difference in shape. The purpose is vague and minimally informative.
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 are no indications of prerequisites, context (e.g., whether a canvas must be open), or comparisons to sibling tools like 'draw_path' or 'object_group'. The agent receives zero usage instructions beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only states the action ('duplicates') without explaining what happens after duplication: whether the duplicate is selected, where it appears (with offsets), if it inherits properties, or what the return value might be. This is inadequate 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 extremely concise - a single Korean sentence that directly states the tool's action. There's no wasted verbiage or unnecessary elaboration. While it's under-specified in terms of content, it's perfectly efficient in terms of word economy.
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 mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what gets duplicated, where the duplicate appears, what properties it inherits, whether it becomes selected, or what the tool returns. Given the complexity implied by the sibling tools (graphic design/editing context), this minimal description leaves critical gaps.
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 three parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema (objectId, offsetX, offsetY). According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
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 '객체를 복제합니다' (Duplicates an object) is a tautology that essentially restates the tool name 'object_duplicate'. It doesn't specify what type of object is being duplicated (graphic element, layer, etc.) or in what context. While it clearly indicates a duplication action, it lacks the specificity needed to distinguish it from sibling tools like 'layer_duplicate'.
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, when duplication is appropriate, or what distinguishes it from similar operations like 'layer_duplicate' or 'object_group'. The agent receives no contextual help for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action ('moves an object') without revealing whether this is a destructive mutation, requires specific permissions, has side effects, or what happens on success/failure. This is inadequate 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 with zero wasted words. It is appropriately sized for a simple tool, though this conciseness comes at the cost of completeness.
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?
Given the complexity of a mutation tool with no annotations and no output schema, the description is severely incomplete. It lacks essential context like behavioral traits, usage guidelines, and what to expect after invocation, making it inadequate for safe and effective tool 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 schema description coverage is 100%, with clear parameter descriptions in the schema (object ID, X/Y movement amounts). The description adds no additional meaning beyond what the schema provides, such as units for dx/dy or constraints on objectId. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '객체를 이동합니다' (moves an object) is a tautology that restates the tool name 'object_move' without adding specificity. It doesn't distinguish this tool from siblings like 'object_scale' or 'object_rotate' that also manipulate objects, nor does it specify what type of object or coordinate system is involved.
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. It doesn't mention prerequisites, context (e.g., for graphical objects in a design tool), or exclusions, leaving the agent to infer usage from the name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('adjusts object size') without any information about side effects, permissions needed, whether the operation is destructive or reversible, rate limits, or what happens on success/failure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single Korean phrase—with no wasted words. It's front-loaded but arguably too brief, bordering on under-specification rather than optimal conciseness. However, it efficiently communicates the core action without redundancy.
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 (5 parameters, mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'adjusting size' entails in this context, what objects are affected, the impact of parameters like originX/Y, or what the tool returns. For a scaling tool in what appears to be a graphics/design environment, 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%, with all parameters well-documented in the input schema (e.g., scaleX, scaleY, originX, originY). The description adds no additional parameter semantics beyond what's already in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 '객체 크기를 조절합니다' (adjusts object size) is a tautology that essentially restates the tool name 'object_scale' in Korean. It provides a generic verb+resource but lacks specificity about what type of objects or context, and doesn't distinguish from siblings like object_rotate or object_move which also modify objects. The purpose is clear at a basic level but too vague for effective differentiation.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context, or comparison with sibling tools like object_rotate for rotation or object_move for positioning. Without this, an agent might struggle to choose between similar object manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 provides none. It doesn't indicate whether this is a read or write operation, what permissions might be needed, whether it modifies existing elements or creates new ones, or what happens after pattern definition. The single sentence offers no behavioral context beyond the basic action implied by 'defines.'
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 extremely concise - a single Korean sentence. While this could be seen as efficient, it's arguably under-specified rather than appropriately concise. However, it does follow the principle of being front-loaded with the core action, and there's no wasted verbiage or redundancy.
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 pattern definition tool with 4 parameters (3 required) and no annotations or output schema, the description is severely incomplete. It doesn't explain what happens after pattern definition, how patterns are used, what the SVG content parameter should contain, or how this tool integrates with the many sibling drawing and styling tools. For a tool that likely creates reusable graphical patterns, this minimal description is inadequate.
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 description coverage is 100%, with all parameters well-documented in the input schema. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 '패턴을 정의합니다' (Defines a pattern) is a tautology that essentially restates the tool name 'style_pattern' without providing meaningful context. It doesn't specify what kind of pattern, for what purpose, or how it relates to the sibling tools. While it includes a verb ('정의합니다' - defines), it lacks specificity about the resource or domain.
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 absolutely no guidance about when to use this tool versus alternatives. There are many sibling tools related to styling (style_fill, style_gradient, style_stroke) and drawing operations, but no indication of how this pattern definition tool fits into the workflow or when it should be selected over other styling options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '이미지를 삽입합니다' implies a mutation (inserting an image), but it doesn't disclose any behavioral traits such as whether this requires specific permissions, what happens if the image URL is invalid, if there are rate limits, or the format of any output. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, but this brevity comes at the cost of being under-specified rather than efficient. It's front-loaded but lacks necessary detail, so it doesn't fully earn its place. While not verbose, it fails to provide essential context, making it less effective.
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 (9 parameters, 5 required, mutation tool) and the absence of annotations and output schema, the description is incomplete. It doesn't explain the tool's purpose in context, usage scenarios, or behavioral aspects, leaving significant gaps for an agent to understand how to invoke it correctly. The high schema coverage helps but doesn't compensate for the lack of overall context.
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 description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain how parameters like 'preserveAspectRatio' affect the image insertion). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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 '이미지를 삽입합니다' (inserts an image) is a tautology that essentially restates the tool name 'draw_image' in Korean. It provides no additional specificity about what resource is being inserted (e.g., into an SVG canvas or document) or how it differs from sibling drawing tools like draw_circle or draw_rect. While it uses a verb+resource structure, it lacks the differentiation needed for a higher score.
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 are no explicit instructions, implied contexts, or exclusions mentioned. Given the many sibling tools (e.g., other drawing tools like draw_circle, export functions), this absence of usage guidelines is a significant gap, making it misleading for an agent trying to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states 'draws a rectangle' but doesn't explain what happens after drawing (e.g., adds to a canvas/SVG, returns an object ID, requires a specific context like an active layer). There's no mention of side effects, permissions, or error conditions, making it insufficient for a tool with 12 parameters.
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 Korean sentence. It's front-loaded with the core action and wastes no words. While it's under-specified, it earns full marks for brevity and structure as every word serves the minimal 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 (12 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's context (e.g., part of an SVG editor), what it returns, or behavioral traits. The high parameter count and lack of annotations mean the description should do more to compensate, but it fails to provide necessary context for 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 schema description coverage is 100%, with each parameter clearly documented in Korean (e.g., coordinates, dimensions, colors). The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 '사각형을 그립니다' (Draws a rectangle) is a tautology that essentially restates the tool name 'draw_rect'. It doesn't specify what kind of rectangle (SVG graphic, canvas element, etc.) or distinguish it from sibling tools like 'draw_rounded_rect_path' or 'draw_polygon'. The purpose is minimally stated but lacks specificity and differentiation.
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 are many sibling drawing tools (e.g., draw_circle, draw_polygon, draw_rounded_rect_path), but no indication of when a rectangle is preferred over other shapes or which tool handles rounded rectangles specifically. This leaves the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action 'ungroup' without explaining what happens during ungrouping (e.g., whether objects retain their properties, if it's reversible, permission requirements, or side effects on sibling tools like 'object_list'). This leaves critical behavioral traits unspecified for a mutation 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 in Korean that directly states the tool's action. It's front-loaded with the core purpose and has no wasted words, making it highly concise and well-structured for quick comprehension, though it lacks depth.
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 as a mutation operation with no annotations and no output schema, the description is incomplete. It fails to explain behavioral aspects like what 'ungroup' entails, potential impacts, or return values. While the parameter is fully covered by the schema, the overall context for safe and correct usage is insufficient, especially compared to sibling tools with more descriptive names.
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 input schema has 1 parameter with 100% description coverage ('groupId' is documented as '해제할 그룹 ID' or 'Group ID to ungroup'). The description doesn't add any parameter details beyond the schema, but with 0 parameters needing extra explanation and high schema coverage, the baseline is appropriately high. No compensation is needed as the schema fully defines the single required parameter.
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 '그룹을 해제합니다' (Ungroups) is a tautology that essentially restates the tool name 'object_ungroup' in Korean. It specifies the verb 'ungroup' but doesn't clarify what resource is being ungrouped (objects, layers, etc.) or distinguish it from sibling tools like 'object_group' or 'layer_merge'. While the action is clear, it lacks specificity about the target resource and differentiation from related operations.
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. It doesn't mention prerequisites (e.g., needing an existing group), exclusions (e.g., not applicable to ungrouped objects), or related tools like 'object_group' for grouping or 'layer_merge' for similar operations. Without such context, an agent must infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 gradient is defined and used with fill, implying a creation or configuration action, but doesn't disclose critical traits: whether this is a read-only or mutating operation, if it requires specific permissions, what happens on invocation (e.g., adds to a document, modifies existing styles), or any side effects. The description is too sparse to inform the agent adequately.
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 concise with two short sentences, avoiding unnecessary verbosity. However, it's under-specified rather than efficiently informative—the brevity comes at the cost of clarity. It's front-loaded with the main action but lacks depth, making it efficient in length but not in communicative value.
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 (12 parameters, no annotations, no output schema), the description is incomplete. It fails to explain the tool's role in the context of sibling tools (e.g., vs. 'style_fill'), what it returns, or how it integrates with other operations. For a parameter-rich tool with no structured support, the description should provide more contextual guidance to be adequate.
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 12 parameters (e.g., type, stops, id, coordinates). The description adds no parameter-specific information beyond implying the 'id' is used in 'url(#id)', which is already inferred from the schema. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 '그라디언트를 정의합니다. fill에 url(#id)로 사용합니다.' (Defines a gradient. Use with fill as url(#id).) is vague and tautological. It restates the tool name 'style_gradient' without specifying what action it performs (e.g., creates, applies, modifies) or what resource it acts on. It mentions usage with 'fill' but doesn't clarify if this is for SVG elements or other contexts, making the purpose unclear.
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 minimal guidance: it suggests using the gradient with 'fill' via 'url(#id)', but doesn't explain when to use this tool versus alternatives like 'style_fill' or 'style_pattern'. There's no mention of prerequisites, context (e.g., for SVG styling), or exclusions, leaving the agent with little direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action ('rotates an object') without disclosing behavioral traits like whether this is a destructive mutation, requires specific permissions, has side effects, or how it interacts with other tools. This is inadequate 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 with zero waste. It's appropriately sized and front-loaded, though it could benefit from more detail given the lack of annotations and output schema.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what happens after rotation (e.g., visual update, return values), potential errors, or integration with the broader toolset, 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%, with clear parameter descriptions in the schema (objectId, angle, originX, originY). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 where 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 '객체를 회전합니다' (rotates an object) states a clear verb+resource action, but it's vague about what type of object is being rotated (e.g., graphical object, 3D model) and doesn't distinguish from sibling tools like object_move or object_scale. It provides basic purpose but lacks specificity.
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, context (e.g., for graphical editing), or exclusions, leaving the agent to infer usage from the tool name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It states the tool '제안합니다' (suggests), implying it's advisory rather than directly modifying objects, but doesn't clarify whether suggestions are displayed, returned as data, or require confirmation. It also doesn't mention permissions, side effects, or what happens with the 'auto' mode. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Korean sentence that gets straight to the point without unnecessary words. It's appropriately sized for a tool with two parameters and clear schema documentation. However, it could be slightly more front-loaded with key behavioral information given the lack of annotations.
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 for a tool that suggests alignment methods. It doesn't explain what form the suggestions take, how they're presented to users, or what happens after suggestions are made. With 2 parameters and behavioral uncertainty, the description should provide more context about the tool's operation and results.
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 well-documented in the schema (objectIds with minItems constraint, mode with enum values and default). The description doesn't add any parameter semantics beyond what the schema already provides - it mentions '선택한 객체들' (selected objects) and '정렬 방법' (alignment methods) which map to parameters but don't provide additional context. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool '제안합니다' (suggests) alignment methods for selected objects, which is a clear verb+resource combination. However, it doesn't distinguish this from potential sibling tools like 'object_move' or 'object_order' that might also affect object positioning. The purpose is understandable but lacks 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. With many sibling tools related to object manipulation (object_move, object_order, object_rotate, etc.), there's no indication whether this is for alignment suggestions versus actual transformations, or what context triggers its use. Only basic parameter requirements are implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'suggests layouts' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, what the output looks like (e.g., visual suggestions, data structures), or any rate limits. The description is minimal and lacks essential context for safe and effective use, especially for an AI-driven tool that might involve complex processing.
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, concise sentence in Korean ('캔버스 크기에 맞는 레이아웃을 제안합니다'), which translates to 'Suggests layouts fitting canvas size.' It's front-loaded with the core purpose and wastes no words. However, it could be more structured by including key details, but as-is, it's efficient and to the point.
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 an AI suggestion tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'suggests' means in practice, what the output entails (e.g., visual layouts, coordinates, recommendations), or any behavioral aspects. For a tool that likely involves AI processing and returns layout data, this minimal description leaves significant gaps for an agent to understand and use it correctly.
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 (contentType with enum values and elementCount with range). The description adds no additional meaning beyond what the schema provides—it doesn't explain how these parameters influence layout suggestions or their interaction. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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 states the tool 'suggests layouts fitting canvas size' which provides a general purpose, but it's vague about what 'suggests' entails (e.g., generates, recommends, returns). It distinguishes from siblings like drawing or export tools, but doesn't clarify how it differs from other AI tools like ai_suggest_colors. The verb 'suggests' is somewhat ambiguous, and the resource 'layout' is clear but lacks specificity about output 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?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for layout suggestions based on canvas size, but it doesn't mention when not to use it, prerequisites, or how it compares to other layout-related tools (none are listed in siblings). Without context on alternatives, the agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. '타원을 그립니다' indicates a creation/drawing operation but doesn't specify whether this adds to an existing canvas, creates a new document, requires specific context, or has side effects. For a drawing tool with zero annotation coverage, this leaves critical behavioral aspects unexplained.
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 Korean sentence ('타원을 그립니다') that's extremely concise and front-loaded with the core action. There's no wasted verbiage, though it could benefit from slightly more context given the lack of annotations.
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 tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after drawing (e.g., adds to current layer, returns element ID), how it integrates with other tools, or any constraints. The high parameter count and lack of structured metadata require more descriptive context.
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 10 parameters well-documented in the schema (e.g., center coordinates, radii, styling attributes). The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 where 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 '타원을 그립니다' (draws an ellipse) states a clear verb+resource action, but it doesn't differentiate from sibling drawing tools like draw_circle, draw_rect, or draw_polygon. The purpose is understandable but lacks specificity about what makes this tool unique compared to other shape-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?
The description provides no guidance on when to use this tool versus alternatives like draw_circle or draw_rect. There's no mention of prerequisites, context, or comparative advantages. The agent must infer usage purely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('draws a line'). It doesn't disclose behavioral traits like whether this creates a new SVG element, modifies an existing one, requires specific permissions, has side effects (e.g., adds to history), or error conditions (e.g., invalid points). For a drawing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean ('여러 점을 연결하는 선을 그립니다'), with no wasted words. It's front-loaded with the core action but could be more structured (e.g., by mentioning it's for SVG drawing). Every sentence earns its place, though it's under-specified rather than concise.
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 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover the tool's context (e.g., part of an SVG editor), return values (e.g., the drawn element), or error handling. For a moderately complex drawing tool with rich parameters but no structured support, the description should do more to compensate.
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 clear parameter descriptions in the schema (e.g., 'points' as coordinate array, 'stroke' as color). The description adds no meaning beyond what the schema provides—it doesn't explain parameter interactions (e.g., 'fill' typically 'none' for polylines) or usage nuances. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '여러 점을 연결하는 선을 그립니다' (draws a line connecting multiple points) states the basic action and resource (points/line), but is vague about the drawing context (SVG/canvas) and doesn't differentiate from sibling tools like 'draw_line' (single line) or 'draw_path' (more complex curves). It's not tautological but lacks specificity compared to 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?
No guidance on when to use this tool versus alternatives like 'draw_line' (for two points) or 'draw_path' (for Bézier curves). The description implies usage for connecting multiple points but doesn't specify exclusions (e.g., not for closed shapes like 'draw_polygon') or prerequisites (e.g., requires an active drawing context).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states '조회합니다' (retrieve), implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the history data is in. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with critical details. The brevity is a strength, but it borders on under-specification.
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 (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on what 'work history' entails, how results are structured, or any behavioral context. Without annotations or output schema, the description should provide more completeness 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 1 parameter with 100% description coverage ('limit' with clear constraints and default). The description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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 '작업 히스토리를 조회합니다' (Retrieve work history) states a clear verb ('조회합니다' - retrieve) and resource ('작업 히스토리' - work history), providing basic purpose. However, it doesn't differentiate from sibling tools like history_clear, history_goto, history_redo, or history_undo, leaving ambiguity about what specific aspect of history it accesses.
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 context, prerequisites, or exclusions, such as whether it retrieves recent actions, all history, or filtered entries. With sibling tools like history_clear and history_goto, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 sets lock status but doesn't disclose behavioral traits like whether this is a destructive operation (likely not, but unspecified), permission requirements, side effects (e.g., if locking affects other tools), or error conditions. This leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's function. It's front-loaded with the core action and resource, with no wasted words. However, it could be slightly more informative without losing conciseness.
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 for a mutation tool. It lacks details on behavior (e.g., what happens when a layer is locked), error handling, or return values. Sibling tools include other layer operations, but no context is provided to distinguish this one adequately.
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 clear parameter descriptions in Korean ('레이어 ID' for layerId, '잠금 여부' for locked). The description adds no additional meaning beyond the schema, such as explaining what a valid layerId looks like or the implications of the locked boolean. Baseline 3 is appropriate given high schema coverage.
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 states the action ('설정합니다' - sets/configure) and resource ('레이어의 잠금 상태' - layer's lock status), providing a basic purpose. However, it's vague about what 'lock status' entails (e.g., preventing editing, selection) and doesn't differentiate from sibling tools like layer_select or layer_visibility, which also control layer states.
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 prerequisites (e.g., needing an existing layer), exclusions, or compare to related tools like layer_select (which might interact with locked layers). Usage is implied only by the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('changes layer name') but doesn't disclose behavioral traits like whether this requires specific permissions, if changes are reversible, what happens to references to the old name, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the action. It's appropriately sized for a simple tool, though it could be more informative. There's no wasted verbiage, but it's under-specified rather than concise.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or side effects. Given the complexity of layer manipulation in a graphics/design context, 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%, with both parameters (layerId, newName) clearly documented in the schema. The description adds no additional meaning beyond what's in the schema, such as format constraints or examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '레이어 이름을 변경합니다' (Changes layer name) states the basic action but is vague about scope and context. It doesn't specify what type of layer (graphic, UI, etc.) or distinguish from similar tools like layer_create, layer_duplicate, or layer_reorder. The purpose is understandable but lacks specificity.
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. With many sibling tools for layer manipulation (layer_create, layer_delete, layer_duplicate, etc.), there's no indication of prerequisites, sequencing, or constraints. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('묶습니다' - groups/binds) but doesn't explain what grouping means in this context—whether it creates a new logical entity, affects object properties, requires specific permissions, or has side effects like locking objects. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 in Korean that directly states the tool's action. It's front-loaded with no wasted words, though it could be slightly more informative without losing conciseness. The structure is clear but minimalistic.
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 grouping operation (a mutation with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects like what happens to grouped objects, whether the operation is reversible, or what the tool returns. For a tool that likely modifies object relationships, more context is needed to guide 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%, with clear descriptions for both parameters: 'objectIds' as an array of object IDs to group, and 'groupId' as an optional group ID. The description adds no additional meaning beyond the schema, such as explaining what a group ID is used for or constraints on object selection. 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 '여러 객체를 그룹으로 묶습니다' (groups multiple objects together) states a clear verb+resource action, but it's somewhat vague about what 'grouping' entails operationally. It doesn't distinguish this tool from sibling tools like 'object_ungroup' or 'layer_merge', which also manipulate object collections. The purpose is understandable but lacks specificity about the grouping mechanism or outcome.
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 existing objects), exclusions, or comparisons to siblings like 'object_ungroup' for reversal or 'layer_merge' for similar grouping operations. Without such context, an 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.
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 '정보를 조회합니다' (retrieve information) implies a read-only operation, it doesn't specify what information is returned, whether authentication is required, if there are rate limits, or how errors are handled. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple tool with one parameter, though it could potentially be more structured if it included additional context about usage or behavior.
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 that this is a read operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (object properties, metadata, etc.), how the selection affects the system state, or what happens if the object ID doesn't exist. For a tool that presumably returns data, more context about the response format 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?
The description mentions 'ID로' (by ID) which aligns with the single 'objectId' parameter in the schema. With 100% schema description coverage (the parameter already has a clear description '객체 ID' - object ID), the description adds minimal value beyond what the schema provides. The baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '객체를 ID로 선택하고 정보를 조회합니다' (Select an object by ID and retrieve information) clearly states the tool's purpose with a specific verb ('선택하고 정보를 조회합니다' - select and retrieve information) and resource ('객체' - object). However, it doesn't distinguish this tool from its sibling 'object_list' which also deals with objects, or explain how selection differs from other object-related operations like 'object_move' or 'object_scale'.
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 when this tool is appropriate (e.g., for retrieving specific object details) versus when to use 'object_list' (for listing all objects) or other object manipulation tools. There's no context about prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it 'adds' an arc but doesn't clarify if this modifies an existing path object, requires a path to be active, what happens if no path exists, or any performance/error considerations. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's function. There's no wasted language, though it could benefit from being more specific about the arc's mathematical properties.
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 path manipulation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'current path', how the arc integrates, what the tool returns, or error conditions. The context demands more completeness.
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 8 parameters thoroughly with descriptions of each. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
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 states the action ('현재 패스에 호(arc)를 추가합니다' - 'adds an arc to the current path') which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'draw_path' or 'path_curveto' which also modify paths, making the purpose somewhat vague in context.
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_path' or 'path_curveto'. The description only states what it does without any context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions 'completes and adds' but doesn't disclose behavioral traits such as whether this is a destructive operation, if it requires specific permissions, what happens on failure, or the format of the result. This leaves significant gaps for a tool that likely modifies or creates SVG content.
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 in Korean that directly states the tool's action. It's front-loaded with the core purpose, though it could be slightly more informative without losing conciseness.
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 creates or modifies SVG paths, with no annotations and no output schema, the description is incomplete. It doesn't explain the result (e.g., what 'adds as an SVG element' means in practice), error conditions, or dependencies, leaving the agent with insufficient context for reliable 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%, with all 7 parameters well-documented in the input schema (e.g., fill color, stroke width). The description adds no additional meaning beyond the schema, so it meets the baseline of 3 where 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 states the tool 'completes the path builder and adds it as an SVG element,' which provides a basic verb+resource combination. However, it's somewhat vague about what 'completing' entails compared to siblings like 'path_close' or 'path_cancel,' and it doesn't specify the exact outcome (e.g., whether it creates a new path or modifies an existing one).
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active path builder), exclusions, or comparisons to sibling tools like 'path_close' or 'path_create,' leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that it 'sets' the fill, implying a mutation operation, but doesn't disclose any behavioral traits such as whether changes are reversible, if it requires specific permissions, what happens on invalid inputs, or the response format. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be more front-loaded with critical details if expanded. There is 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?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. While the schema covers parameters well, the overall context for safe and effective use is lacking, especially compared to sibling tools that may have similar styling functions.
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 description coverage is 100%, with both parameters ('objectId' and 'fill') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples or constraints on the 'fill' parameter values. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '객체의 채우기를 설정합니다' (Sets the fill of an object) clearly states the verb ('설정합니다' - sets) and resource ('객체의 채우기' - object's fill), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'style_stroke' or 'style_gradient' that also modify object styling, nor does it specify what type of objects or context this applies to.
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 when to choose this over other style tools like 'style_stroke' or 'style_gradient', nor does it indicate any prerequisites, such as needing an existing object or specific object types. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action 'applies a filter' but doesn't disclose behavioral traits like whether this is a mutation (likely yes, given the context), what permissions are needed, side effects, or how the filter interacts with the object. This leaves significant gaps for an agent to understand the tool's behavior.
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 in Korean, making it appropriately concise. However, it's under-specified rather than optimally structured, as it lacks front-loaded critical details, but it doesn't waste words.
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 (3 parameters, no annotations, no output schema, and many sibling tools), the description is incomplete. It doesn't explain what the tool returns, how filters are applied, or interaction with other style tools, leaving the agent with insufficient context for 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 parameters well (objectId, filterType with enum, params). The description adds no additional meaning beyond implying filtering, which the schema covers. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '객체에 필터를 적용합니다' (applies a filter to an object) states a clear verb+resource action, but it's vague about what kind of filter or object. It doesn't differentiate from sibling tools like 'style_remove_filter' or other style tools, leaving the specific purpose ambiguous.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with many sibling tools (e.g., 'style_remove_filter'), the lack of differentiation makes it unclear when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 removes a filter, implying a mutation, but doesn't disclose behavioral traits like whether this is destructive (likely yes, but unspecified), permission requirements, side effects, or what happens if no filter exists. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean ('객체에서 필터를 제거합니다') that directly states the action. It's front-loaded with the core purpose, though it could be more specific to improve clarity without sacrificing brevity.
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 no annotations or output schema), the description is incomplete. It lacks details on what 'filter' means in this context, the effect of removal, error conditions, or return values. For a tool that likely modifies visual styles, 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%, with the single parameter 'objectId' clearly documented in the schema. The description adds no additional meaning about parameters beyond implying an object context, so it meets the baseline of 3 where 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 states the action ('제거합니다' - removes) and target ('객체에서 필터' - filter from object), providing a basic purpose. However, it's vague about what type of object or filter is involved and doesn't differentiate from siblings like 'style_filter' (which likely adds/modifies filters) or 'object_delete' (which removes entire objects).
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 doesn't mention prerequisites (e.g., needing an existing filter), exclusions, or comparisons to sibling tools like 'style_filter' or 'object_delete'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '설정합니다' (sets), implying a mutation, but does not disclose whether this requires specific permissions, if changes are reversible, what happens to existing stroke styles, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could benefit from more detail given the lack of annotations and output schema.
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 (6 parameters, mutation operation) and the absence of annotations and output schema, the description is incomplete. It does not cover behavioral aspects like error handling, response format, or usage context, making it inadequate for an AI agent to fully understand how to invoke and interpret results.
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 description coverage is 100%, with all parameters well-documented in the input schema. The description does not add any meaning beyond the schema, such as explaining interactions between parameters or default behaviors. Given the 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 '객체의 선 스타일을 설정합니다' (Sets the stroke style of an object) clearly states the verb ('설정합니다' - sets) and resource ('객체의 선 스타일' - stroke style of an object), making the purpose understandable. However, it does not differentiate from sibling tools like 'style_fill' or 'style_gradient' beyond mentioning 'stroke', which is somewhat vague about scope and 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?
The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, such as needing an existing object, or comparisons to other styling tools like 'style_fill' or 'style_gradient', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '정의합니다' (defines) implies a creation/mutation operation, but the description doesn't disclose what happens to the original object (is it replaced? modified? copied?), whether this requires specific permissions, what happens on failure, or what the result looks like. For a mutation tool with zero annotation coverage, this is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean with no wasted words. It's appropriately sized for a basic tool description, though it could benefit from being more specific. The structure is straightforward but lacks front-loading of critical 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after symbol definition, whether the symbol becomes available for use elsewhere, what format the symbol takes, or any error conditions. Given the complexity of symbol systems in graphics tools, this leaves 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%, with all three parameters documented in the schema. The description doesn't add any parameter semantics beyond what's already in the schema (objectId, symbolId, viewBox). According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 '객체를 재사용 가능한 심볼로 정의합니다' (Defines an object as a reusable symbol) states a clear verb ('정의합니다' - defines) and resource ('객체' - object), but it's vague about what a 'symbol' means in this context and doesn't distinguish this tool from sibling tools like 'symbol_use' or other object manipulation tools. It provides basic purpose but lacks specificity about the symbol system.
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 sibling tools like 'symbol_use' (presumably for using symbols) and many object manipulation tools, there's no indication of when symbol definition is appropriate versus other operations. No prerequisites, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'places a defined symbol,' implying a creation or insertion action, but doesn't specify if this is a read-only preview, a destructive edit to a document, or requires specific permissions. It lacks details on side effects, error handling, or output format, leaving significant gaps for a tool with potential mutations.
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 in Korean, with no wasted words. It's front-loaded with the core action ('places'), but could be more structured by including key context upfront. It earns a high score for brevity, though it risks under-specification.
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 (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'symbol' is in this context, how it relates to sibling tools like 'symbol_define', what happens on success/failure, or the visual output. For a tool that likely modifies a design canvas, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 clearly documented in the schema (e.g., 'symbolId' as the symbol ID, 'x' and 'y' as coordinates). The description adds no additional meaning beyond the schema, such as explaining how 'symbolId' relates to 'symbol_define' or what units 'width' and 'height' use. 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 '정의된 심볼을 배치합니다' (Places a defined symbol) states a clear verb ('places') and resource ('symbol'), but it's vague about what 'placing' entails—whether it creates a new instance, inserts into a canvas, or modifies existing elements. It doesn't differentiate from sibling tools like 'draw_rect' or 'draw_image', which also create visual elements, leaving ambiguity about its specific role.
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?
There is no guidance on when to use this tool versus alternatives. With many sibling drawing tools (e.g., 'draw_rect', 'draw_image'), it's unclear if 'symbol_use' is for reusable graphics, icons, or templates, or what contexts favor it over direct drawing methods. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '불러옵니다' (loads) implies a read operation, it doesn't specify what 'loading' entails—does it retrieve template data, apply it to a current project, or something else? It also omits critical details like permissions needed, error handling (e.g., if the template doesn't exist), or side effects. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the action. It's front-loaded with no wasted words, making it easy to parse quickly. However, it could be slightly more structured by explicitly mentioning the parameter or output, but its brevity is generally effective.
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 read operation with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'loading' returns (e.g., template data, a success status) or behavioral aspects like error cases. For a tool in a context with many siblings (e.g., template management tools), more detail is needed to ensure proper 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 'templateName' documented as '템플릿 이름 또는 ID' (template name or ID). The description doesn't add any meaning beyond this—it doesn't clarify format, examples, or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description neither compensates for gaps nor adds value.
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 '저장된 템플릿을 불러옵니다' (Loads a saved template) clearly states the verb ('불러옵니다' - loads) and resource ('템플릿' - template), making the basic purpose understandable. However, it doesn't distinguish this tool from its siblings like 'template_list' or 'template_save', leaving ambiguity about what specifically 'loading' entails versus listing or saving templates.
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 saved template first), exclusions, or how it differs from sibling tools like 'template_list' (which might list templates without loading) or 'svg_open' (which might open files). This lack of context makes it unclear when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it's a retrieval operation ('조회'), implying read-only behavior, but doesn't mention any side effects, permissions, rate limits, or output format. For a tool with zero annotation coverage, this is insufficient—it lacks details on what 'defined animations' entails or how results are returned.
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, clear sentence in Korean that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently conveys the core action, 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 tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'defined animations' means, how results are structured, or any behavioral nuances. For a retrieval tool with no structured output, more context 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 1 parameter with 100% description coverage (objectId: '특정 객체의 애니메이션만 조회'), so the schema already documents the parameter meaning. The description adds no additional semantic context beyond what's in the schema, such as examples or constraints, resulting in a baseline score of 3.
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 '정의된 애니메이션 목록을 조회합니다' (Retrieves a list of defined animations) clearly states the verb (retrieves/조회) and resource (animations/애니메이션 목록), but it's vague about scope—it doesn't specify whether this lists all animations globally or per-object, nor does it differentiate from sibling tools like anim_css_add or anim_remove. It's adequate but lacks specificity.
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. There are no explicit instructions on when to use anim_list over other animation-related tools (e.g., anim_css_add, anim_remove) or object-related tools (e.g., object_list), 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.
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. '원을 그립니다' only states the action without revealing whether this creates a new object, modifies existing ones, requires specific permissions, has side effects, or what happens on execution. For a tool with 9 parameters and no annotation coverage, this is a significant gap in behavioral context.
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 just three Korean characters, making it front-loaded and free of unnecessary words. Every character serves the core purpose statement without waste, though this brevity comes at the cost of completeness.
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 (9 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the tool returns, how it interacts with the drawing context, or provide any behavioral context. The description fails to compensate for the lack of structured metadata, leaving significant gaps for the 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 information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 9 parameters. Since schema_description_coverage is high, the baseline score is 3 even without additional parameter semantics in the description.
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 '원을 그립니다' (draws a circle) states the basic action but lacks specificity about what resource it acts upon (e.g., an SVG canvas or drawing context) and doesn't distinguish it from sibling drawing tools like draw_ellipse or draw_rect. It's a vague purpose statement that doesn't provide enough context for the agent to understand the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_ellipse or draw_rect, nor does it mention any prerequisites or context for usage. There's no indication of when this tool is appropriate or when other tools might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this creates a permanent SVG element, requires a canvas context, has side effects, or returns anything. For a 9-parameter tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose with zero wasted words. It's appropriately sized for such a simple statement 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 complexity (9 parameters, no annotations, no output schema) and rich sibling tools (many drawing alternatives), the description is incomplete. It doesn't explain the drawing context, return values, or how this fits within the SVG tool ecosystem. The agent would struggle to use this effectively without additional context.
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 with descriptions. The description adds no parameter information beyond what's in the schema, meeting the baseline of 3 where 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 '직선을 그립니다' (Draws a straight line) clearly states the action and resource, but it's vague about the context (SVG drawing tool) and doesn't distinguish from siblings like draw_path or draw_polyline that also create lines. It's better than a tautology but lacks specificity about what kind of line or where it's drawn.
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 like draw_path (for curved lines) or draw_polyline (for multi-segment lines). The description doesn't mention prerequisites, context, or exclusions, leaving the agent to 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.
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 ('draws') but doesn't disclose key traits like whether this creates a new object in a drawing application, modifies existing elements, requires specific permissions, or has side effects (e.g., adding to a history). This leaves significant gaps for a tool with 10 parameters.
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 in Korean that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly 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 (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., a shape object, success status, or error), behavioral aspects like idempotency or side effects, or how it integrates with sibling tools in a drawing application context. This leaves the agent with insufficient information for reliable 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 description coverage is 100%, so the schema fully documents all 10 parameters with descriptions like '중심 X 좌표' (center X coordinate). The description adds no additional parameter semantics beyond implying a regular polygon is drawn, which is already clear from the tool name and 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '정다각형을 그립니다' (Draws a regular polygon) clearly states the verb and resource, but it's vague about the context (e.g., where it's drawn, such as in an SVG or canvas). It distinguishes from siblings like 'draw_polygon' by specifying 'regular', but doesn't fully clarify the difference in usage or output 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?
No guidance is provided on when to use this tool versus alternatives like 'draw_polygon' or 'draw_circle'. The description lacks context about prerequisites, such as needing an active drawing surface or specific application state, leaving the agent to infer usage from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action ('draws a star shape') without disclosing behavioral traits like whether this creates a new SVG element, modifies an existing one, requires specific permissions, has side effects, or what happens on success/failure. For a tool with 11 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single Korean sentence ('별 모양을 그립니다') that directly states the purpose. No wasted words or unnecessary elaboration, though this conciseness comes at the cost of completeness for other dimensions.
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 (11 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what the tool returns, how the star is rendered, error conditions, or integration with the broader drawing context implied by sibling tools. For a parameter-rich drawing tool, 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%, with all 11 parameters well-documented in the schema (e.g., cx/cy as center coordinates, outerRadius/innerRadius for star proportions). The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 but doesn't compensate with additional context about how parameters interact or typical values.
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 '별 모양을 그립니다' (draws a star shape) states the basic purpose with a verb and resource, but it's vague about scope and doesn't distinguish from sibling drawing tools like draw_circle, draw_heart, or draw_regular_polygon. It doesn't specify what medium or context the star is drawn in (SVG canvas, image, etc.).
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 like draw_regular_polygon (which could also create star-like shapes) or other shape-drawing siblings. The description doesn't mention prerequisites, context, or any 'when-not-to-use' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'creates' implies a write operation, it doesn't specify permissions needed, whether the layer is added to a specific document, error conditions, or what happens on success (e.g., returns a layer ID). This is a significant gap for a creation 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, earning full marks for conciseness.
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 for a creation tool. It doesn't explain what the tool returns (e.g., success confirmation or layer details), behavioral aspects like side effects, or usage context, leaving critical 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%, with both parameters ('name' and 'insertAt') documented in the schema. The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '새 레이어를 생성합니다' (creates a new layer) clearly states the verb ('creates') and resource ('layer'), making the purpose understandable. However, it doesn't differentiate from sibling tools like layer_duplicate or layer_merge, which also involve layer creation/management, so it's not fully specific.
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 document), exclusions, or comparisons to siblings like layer_duplicate or layer_list, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action (delete) but does not describe critical behaviors such as whether deletion is permanent or reversible, if it requires specific permissions, what happens to child objects, or error conditions. This is a significant gap for a destructive operation 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 in Korean that directly states the tool's action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for its minimal content.
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 destructive delete operation), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like permanence, permissions, or error handling, and does not explain return values or side effects, leaving the agent with insufficient 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?
The schema description coverage is 100%, with the parameter 'layerId' clearly documented as '삭제할 레이어 ID' (ID of the layer to delete). The description does not add any additional meaning beyond the schema, such as format examples or constraints, but the schema provides adequate baseline information, justifying a score of 3.
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 '레이어를 삭제합니다' (Deletes a layer) clearly states the verb (delete) and resource (layer), making the purpose understandable. However, it does not differentiate this tool from sibling tools like 'object_delete' or 'template_delete', which perform similar deletion operations on different resources, leaving room for ambiguity in sibling context.
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 does not mention prerequisites (e.g., whether the layer must be unlocked or selected), exclusions (e.g., cannot delete locked layers), or comparisons to siblings like 'object_delete' for deleting objects instead of layers, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('duplicates') but doesn't clarify key traits: whether this is a destructive operation (e.g., modifies original layer), requires specific permissions, has side effects (e.g., updates layer list), or what the output looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 directly states the tool's 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 the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavior, output format, error conditions, and differentiation from siblings. For a tool that modifies state, more context is needed to ensure safe and 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 description coverage is 100%, with the single parameter 'layerId' documented as '복제할 레이어 ID' (ID of the layer to duplicate). The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '레이어를 복제합니다' (Duplicates a layer) clearly states the verb (duplicate) and resource (layer), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'object_duplicate' or specify what 'duplicate' entails in this context (e.g., creates an identical copy with new ID). This makes it somewhat vague compared to more specific 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 offers no guidance on when to use this tool versus alternatives like 'object_duplicate' or 'layer_create', nor does it mention prerequisites (e.g., needing an existing layer). Without any context on usage scenarios or exclusions, the agent must infer based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 selects an active layer, implying a state change, but doesn't disclose behavioral traits such as whether this affects other layers, requires specific permissions, has side effects, or what happens if the layerId is invalid. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, 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 tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'active' entails, potential side effects, or return values, leaving gaps in understanding how this tool behaves in the context of sibling tools like 'layer_list' or 'object_select'.
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 the parameter 'layerId' documented as '선택할 레이어 ID' (layer ID to select). The description doesn't add meaning beyond this, such as format examples or constraints. 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 '활성 레이어를 선택합니다' (Selects the active layer) clearly states the action (select) and target (layer), but it's vague about what 'active' means in this context. It doesn't distinguish this tool from sibling tools like 'object_select' or 'layer_list', which also involve selection operations.
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. With sibling tools like 'object_select' (select objects) and 'layer_list' (list layers), there's no indication of whether this tool is for selecting layers for editing, visibility control, or other purposes, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('changes canvas size') which implies a mutation, but doesn't disclose whether this is destructive to existing content, requires specific permissions, has side effects, or what happens to objects outside the new bounds. 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 in Korean that directly states the tool's function. There's no wasted words or unnecessary elaboration. It's appropriately sized for a simple operation and gets straight to the point.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what 'changing canvas size' means operationally, whether content is cropped or scaled, what the return value is, or error conditions. Given the complexity of resizing operations and lack of structured documentation, 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 all parameters are documented in the schema itself. The description doesn't add any parameter information beyond what's already in the schema (width, height, scaleContent). According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 states the action ('캔버스 크기를 변경합니다' - changes canvas size) which is a clear verb+resource combination. However, it doesn't specify what type of canvas (SVG) or differentiate from sibling tools like 'object_scale' or 'svg_set_background' that might also affect dimensions. The purpose is understandable but lacks specificity.
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. There's no mention of prerequisites, when this operation is appropriate, or how it differs from similar tools like 'object_scale' or 'svg_set_background' in the sibling list. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what the tool does, not behavioral traits. It lacks details on output format (e.g., list of hex codes), performance, or any constraints like rate limits or side effects, which are critical for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse.
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 the output looks like (e.g., a list of colors), how many colors are recommended, or any behavioral context, leaving gaps for the agent to understand tool behavior fully.
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 parameters like 'baseColor' as hex and 'harmony' as an enum. The description adds no extra meaning beyond implying palette generation, aligning with the baseline for 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 tool's purpose: '추천합니다' (recommends) a '색상 팔레트' (color palette) based on a '기준 색상' (base color). It specifies the action and resource but doesn't explicitly differentiate from siblings like 'ai_analyze_colors', which might analyze rather than suggest.
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 doesn't mention sibling tools or contexts where it's preferred, such as for design inspiration versus technical analysis, 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.
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 adds CSS animation but doesn't explain what that means operationally: whether it modifies objects in-place, requires specific object types, has side effects, or returns any confirmation. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 tool with comprehensive schema documentation 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 mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after animation addition, whether there's visual feedback, error conditions, or how this interacts with other animation tools. The context signals indicate significant complexity that the description doesn't address.
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 8 parameters thoroughly. The description doesn't add any parameter-specific context beyond what's in the schema, such as explaining relationships between parameters or providing usage examples. Baseline 3 is appropriate when the schema does all 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 ('adds CSS animation') and target ('to an object'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling animation tools like anim_list, anim_remove, or anim_smil_add, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 anim_smil_add or other animation-related siblings. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '제거합니다' (removes) implies a destructive mutation, it doesn't specify whether this action is reversible, what permissions are needed, or what happens to the object after animation removal. The description lacks critical behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 unnecessary words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what happens after animation removal, whether there are side effects, what the return value might be, or how this interacts with other object properties. The minimal description leaves significant gaps in understanding the tool's behavior.
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 itself. The description adds no additional parameter information beyond what's already in the structured schema fields, so it meets the baseline expectation but doesn't provide extra 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 ('제거합니다' - removes) and target ('객체의 애니메이션' - object's animation), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling animation tools like anim_list, anim_css_add, or anim_smil_add, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are no indications of prerequisites, constraints, or comparisons with related tools like anim_list (for viewing animations) or other animation modification tools, leaving the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '추가합니다' (adds) implies a mutation operation, it doesn't specify whether this requires specific permissions, if animations persist across sessions, what happens on invalid parameters, or any rate limits. The description lacks crucial behavioral context for a tool that modifies SVG content.
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 sentence that directly states the tool's purpose and context. There's zero wasted language, and it's front-loaded with the core functionality. Every word earns its place in this minimal but complete statement.
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 12 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, side effects, or how the animation integrates with the SVG document. The description provides only basic purpose without the behavioral context 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 already documents all 12 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no additional value from the description.
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 ('객체에 SMIL 애니메이션을 추가합니다') and specifies the resource ('객체') and technology context ('SVG 내장 애니메이션'). It distinguishes from sibling tools like anim_css_add (CSS animations) and anim_remove (removal), but doesn't explicitly mention these alternatives in the description text itself.
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 anim_css_add or anim_list. It doesn't mention prerequisites (e.g., needing an existing object), nor does it explain typical use cases for SMIL animations versus other animation methods available in the toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'draws a path' but doesn't mention whether this creates a new object, modifies an existing one, requires specific permissions, or has side effects like adding to a layer. 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, 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 complexity of a drawing tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., creation vs. modification, layer integration), usage context relative to siblings, and output information, making it inadequate for full 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 7 parameters with examples and constraints. The description adds no additional parameter semantics beyond implying the 'd' parameter is central, which the schema already covers. 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 ('draws a path') and the resource ('using SVG path data (d attribute)'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'draw_line' or 'draw_polygon', which might also create path-like shapes, so it doesn't fully distinguish from 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. With many sibling drawing tools (e.g., 'draw_line', 'draw_polygon'), there's no indication of when direct SVG path data is preferred over higher-level shape tools, 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.
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 creates a path (not a direct shape), which is useful behavioral context. However, it doesn't disclose critical traits: whether this adds to the current document/layer, if it's an immediate render or deferred operation, what happens with invalid parameters, or any side effects. For a drawing tool with 10 parameters, this leaves significant behavioral uncertainty.
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 sentence in Korean that efficiently conveys the core functionality and a key feature. Every word earns its place with no redundancy or fluff. It's front-loaded with the main 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?
For a drawing tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what '패스로 그립니다' (draws as a path) means operationally, how the result integrates with the document, what happens with the fill/stroke parameters, or what the tool returns. The agent must infer too much from minimal context.
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 with their types, constraints, and basic descriptions. The description adds minimal value beyond the schema: it implies the 'radius' parameter can have per-corner variations ('모서리별 다른 반경 가능'), which isn't explicitly stated in the schema. However, this is a single additional insight for one parameter among ten.
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 ('둥근 모서리 사각형을 패스로 그립니다' - draws a rounded rectangle as a path) and resource (rounded rectangle), and mentions a key feature ('모서리별 다른 반경 가능' - different radii per corner possible). It distinguishes from sibling tools like 'draw_rect' by specifying rounded corners and path creation. However, it doesn't explicitly differentiate from other path-drawing siblings like 'draw_path' or 'draw_polygon' beyond the rounded rectangle shape.
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 when to choose this over 'draw_rect' for rectangles, 'draw_path' for custom paths, or other shape-drawing tools. There are no prerequisites, exclusions, or contextual usage hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns SVG code but doesn't describe what '현재 캔버스' (current canvas) refers to, whether this is a read-only operation, potential side effects, or output format details. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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, 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what '현재 캔버스' means in context, what the returned SVG code looks like, or how it differs from sibling export tools. For a tool that likely interacts with a graphical interface, more contextual information 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?
The input schema has 100% description coverage, with the 'format' parameter fully documented (enum: raw, pretty, minified; default: pretty). The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for 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 tool's purpose: '현재 캔버스의 SVG 코드를 반환합니다' (Returns the SVG code of the current canvas). It specifies the verb ('반환합니다' - returns) and resource ('SVG 코드' - SVG code), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'export_svg' or 'export_png', which appear to serve similar export functions.
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 sibling tools like 'export_svg' or 'export_png', nor does it specify contexts or prerequisites for usage. The agent must infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '내보냅니다' (export) implies a write operation that creates a file, but the description doesn't mention what happens if the file already exists, what permissions are needed, whether this is a destructive operation, or what happens on success/failure. For a file-writing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one short sentence in Korean. While this is efficient, it may be too brief given the tool's complexity (file export with parameters). However, every word serves a purpose and there's 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 file export tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets exported (current SVG content? selection?), what format the output takes, error conditions, or success indicators. Given the complexity of file operations and the lack of structured metadata, the description should provide more complete context.
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 (filePath and minify) with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('내보냅니다' meaning 'export') and the resource ('SVG 파일' meaning 'SVG file'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling export tools like export_png or export_code, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are multiple export tools in the sibling list (export_png, export_code, export_data_uri), but the description doesn't mention any of them or provide context about when SVG export is appropriate versus other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('move to') but doesn't disclose behavioral traits like whether this is a destructive operation (e.g., if it discards current state), what happens to unsaved changes, or if it requires specific permissions. 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 in Korean that directly states the tool's function without unnecessary words. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (implied by 'move to'), the description is incomplete. It lacks crucial details like behavioral effects (e.g., state changes), error handling, or return values, making it insufficient for safe and effective use by 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%, with the parameter 'historyIndex' documented as 'history index to move to'. The description doesn't add meaning beyond this, such as explaining how to obtain valid indices (e.g., from history_list) or what happens with invalid 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 verb ('move to') and resource ('specific point in history'), making the purpose understandable. However, it doesn't differentiate from sibling tools like history_undo, history_redo, or history_list, which are related history operations but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 history_undo/history_redo for sequential navigation or history_list for viewing history. There's no mention of prerequisites, such as needing to know the history index from history_list first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers minimal behavioral insight. It states the action ('redo canceled operations') but doesn't disclose what happens on failure, whether it's reversible, what permissions are needed, or what the tool returns. 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 that directly states the tool's function without any wasted words. It's appropriately sized for a simple tool with one parameter.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what 'redo' means in this context, what constitutes a 'step', what happens when there's nothing to redo, or what the tool returns. Given the complexity of history operations and lack of structured documentation, 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?
The schema has 100% description coverage, with the single parameter 'steps' well-documented in the schema ('다시 실행할 단계 수' - number of steps to redo). The description adds no additional parameter information beyond what the schema already provides, meeting the baseline for 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 tool's purpose with a specific verb ('다시 실행합니다' - redo) and resource ('취소한 작업' - canceled operations). It distinguishes from its sibling 'history_undo' by being the opposite operation, though it doesn't explicitly mention this distinction in the text.
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 undo history), when not to use it, or how it relates to sibling tools like 'history_undo', 'history_goto', or 'history_list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 undoing the last operation but doesn't specify what constitutes an 'operation', whether changes are reversible, if there are limitations on what can be undone, or what happens when no history exists. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly communicates the core functionality without any unnecessary words. It's perfectly 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?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after the undo operation, what errors might occur, or how this interacts with the broader history system. The context signals indicate this is part of a drawing/design application, but the description doesn't leverage that context.
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 description coverage is 100%, with the single parameter 'steps' clearly documented in the schema as 'number of steps to undo'. The description doesn't add any additional parameter semantics beyond what the schema already provides, which meets the baseline expectation for 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 ('undo') and the target ('last operation'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'history_redo' or 'history_clear' beyond the obvious directional difference, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'history_redo' or 'history_goto', nor does it mention prerequisites such as requiring an existing history. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a mutation operation ('설정합니다' - sets), which implies it changes layer properties, but doesn't mention whether this requires specific permissions, if changes are reversible, what happens on invalid inputs, or any rate limits. 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 that gets straight to the point with zero wasted words. It's appropriately sized for a tool with two well-documented parameters and no complex behavioral nuances to explain.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what happens after setting the blend mode (e.g., visual feedback, error conditions), doesn't mention dependencies or side effects, and provides no context about the broader layer system. Given the complexity of graphic editing operations, more guidance 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%, with both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain what a 'layerId' refers to in context or provide examples of when to use specific blend modes. The baseline of 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 ('설정합니다' - sets) and resource ('레이어의 블렌드 모드' - layer's blend mode), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'layer_opacity' or 'layer_visibility' which also modify layer properties, leaving room for confusion about when to choose this specific tool.
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. While the description implies it's for setting blend modes, there's no mention of prerequisites (e.g., whether the layer must exist or be unlocked), nor any comparison to similar tools like 'layer_opacity' for other visual adjustments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states 'merges two layers' but doesn't disclose critical behavioral traits: whether this is a destructive operation (source layer deletion is hinted in parameter descriptions only), what merging entails (e.g., combining properties, geometries), permissions needed, or error conditions. The description is minimal and lacks operational context.
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 in Korean ('두 레이어를 병합합니다'), with zero wasted words. It's front-loaded and appropriately sized for the tool's complexity, though it may be overly concise given the lack of behavioral details.
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 merging does, the result (e.g., a combined layer, property inheritance), or potential side effects. For a tool that likely modifies or deletes layers, this lack of context is a significant gap, leaving the agent underinformed.
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%, with clear parameter descriptions in the schema (e.g., sourceLayerId '병합할 레이어 ID (삭제됨)' meaning 'layer ID to merge (deleted)'). The tool description adds no parameter semantics beyond the schema, but with full schema coverage and only 2 parameters, the baseline is high. The description doesn't compensate but doesn't need to given the schema's completeness.
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 '두 레이어를 병합합니다' (merges two layers) clearly states the action and resource, but it's vague about what merging entails and doesn't differentiate from sibling tools like layer_duplicate or layer_reorder. It provides a basic purpose but lacks specificity about the merge behavior or outcome.
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, when merging is appropriate, or what happens to the source layer (implied by parameter descriptions but not in the tool description itself). It leaves the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it 'sets' opacity (implying a mutation), but doesn't mention permissions needed, whether changes are reversible, side effects, or what happens if the layer doesn't exist. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 with zero wasted words. It's appropriately sized for a simple tool with two well-documented parameters.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, error conditions, or how it differs from similar tools like 'style_opacity'. The agent lacks sufficient context to use this tool 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%, with both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema (layerId and opacity with range 0-1). 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 ('설정합니다' - sets/configure) and the resource ('레이어의 불투명도' - layer opacity). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'style_opacity' which might handle opacity for different elements.
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 'style_opacity' or 'layer_blend_mode'. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent to 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.
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 changes layer order, implying a mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if changes are reversible, what happens to other layers' indices, or error conditions. This is inadequate 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 in Korean ('레이어 순서를 변경합니다' translates to 'Changes layer order'). It's front-loaded with the core purpose and contains no wasted words, 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 tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on behavior, error handling, or what the tool returns, leaving gaps that could hinder an AI agent's correct invocation in a real-world context.
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 ('layerId' and 'newIndex') with descriptions and constraints. The description adds no additional meaning beyond what the schema provides, such as clarifying the ordering system or edge cases, meeting the baseline for 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 ('change order') and resource ('layers'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'object_order' or 'layer_list' that might also deal with ordering or layer management, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There's no mention of prerequisites, context, or comparison with sibling tools like 'object_order' or 'layer_list' that might handle similar ordering operations, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 sets visibility but doesn't explain if this is a reversible action, requires specific permissions, affects other properties, or has side effects. 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 that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse. Every part of the sentence contributes 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?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like reversibility or permissions, nor does it hint at the return value. For a tool that modifies state, more context is needed to ensure safe and 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 input schema has 100% description coverage, with clear parameter descriptions: 'layerId' as '레이어 ID' and 'visible' as '표시 여부'. The description adds no additional meaning beyond this, such as format details or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents the parameters.
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 tool's purpose: '레이어의 표시/숨김 상태를 설정합니다' (Sets the visibility state of a layer). It specifies the verb '설정합니다' (sets) and the resource '레이어' (layer), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'layer_list' or 'layer_select', which might also involve layer properties but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as needing an existing layer, or compare it to related tools like 'layer_list' (which might list visibility) or 'layer_opacity' (which controls transparency). Without such context, the agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 deletes an object, implying a destructive mutation, but fails to describe critical traits such as whether deletion is permanent, requires specific permissions, affects related elements, or provides confirmation. This is a significant gap for a destructive 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 is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured for its simplicity.
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 destructive nature, lack of annotations, and absence of an output schema, the description is incomplete. It does not address behavioral risks, return values, or error conditions. For a mutation tool with no structured safety information, more context is needed to ensure safe and 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 input schema has 100% description coverage, with 'objectId' clearly documented as '삭제할 객체 ID' (ID of the object to delete). The description does not add any meaning beyond this, such as format examples or constraints, but the schema adequately covers the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '객체를 삭제합니다' (deletes an object) clearly states the action (delete) and resource (object), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'layer_delete' or 'template_delete', which perform similar deletion operations on different resources, so it misses full sibling 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not specify if it's for deleting graphical objects in a design context (as suggested by sibling tools like 'draw_circle' or 'object_duplicate') or clarify prerequisites like object selection. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it's a retrieval operation ('조회합니다'), implying read-only behavior, but doesn't disclose any behavioral traits like permissions needed, rate limits, pagination, or what '모든 객체' (all objects) entails in practice (e.g., all objects in current view vs. entire canvas).
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 unnecessary words. It's appropriately sized and front-loaded, 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 lacks details on return values (e.g., format of the object list), behavioral constraints, or how it integrates with sibling tools, leaving significant gaps for a tool that likely returns 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%, with the single parameter 'layerId' documented as optional for filtering by specific layer. The description adds no additional parameter semantics beyond this, 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 ('조회합니다' - retrieve/list) and resource ('캔버스의 모든 객체 목록' - all object list in canvas), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'layer_list' or 'object_select' which also involve listing/selecting objects, missing explicit 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. With siblings like 'layer_list' (lists layers) and 'object_select' (selects objects), the description offers no context for choosing between them, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 '변경합니다' (changes) implies mutation, it doesn't specify whether this is destructive, requires specific permissions, affects other objects, or provides confirmation of success. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and immediately communicates the core functionality.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what Z-order means in this context, what visual effect the change produces, whether the operation is reversible, or what happens on success/failure. Given the tool's complexity and lack of structured metadata, 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%, with both parameters clearly documented in the schema. The description doesn't add any additional meaning about the parameters beyond what's already in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 ('Z 순서를 변경합니다' - changes Z-order) and the resource ('객체' - object), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'layer_reorder' or 'object_move', but the specific focus on Z-order provides reasonable 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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, context for Z-order changes, or how this differs from related tools like 'layer_reorder' or 'object_move' that might also affect visual stacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('취소합니다' - cancels), implying a destructive operation that might discard unsaved path data, but doesn't disclose behavioral traits like whether this requires an active path, what happens to the path data (e.g., deletion vs. reset), or any side effects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's action. It's front-loaded with the core purpose and has no wasted words, making it appropriately concise for a simple 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 complexity (a mutation tool with potential data loss), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what '패스 빌더' entails, the consequences of cancellation, or what the tool returns (e.g., success status). For a tool that likely interacts with an active drawing state, more context is needed.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable given the schema completeness. Baseline is 4 for tools with 0 parameters, as there's nothing to compensate for.
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 '현재 패스 빌더를 취소합니다' (Cancels the current path builder) states a clear verb ('취소합니다' - cancels) and resource ('패스 빌더' - path builder), but it's vague about what '패스 빌더' specifically refers to in this drawing/vector graphics context. It doesn't distinguish from sibling tools like 'path_finish' or 'path_create', which might have related functionality.
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 doesn't mention prerequisites (e.g., requires an active path builder), exclusions, or related tools like 'path_finish' that might handle path completion differently. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 what the tool does but provides no information about prerequisites (must have an active path?), side effects (modifies current path state), error conditions, or what happens after curve addition. The description is minimal and lacks essential context for safe invocation.
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 in Korean that directly states the tool's purpose. There is zero wasted language or unnecessary elaboration. It's appropriately sized for a tool with well-documented parameters in the schema.
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 path manipulation tool with 5 parameters and no annotations or output schema, the description is insufficient. It doesn't explain the tool's role in the broader path creation workflow, doesn't mention prerequisites (like needing an active path), and provides no information about what constitutes success or failure. The context signals indicate this is a moderately complex tool that needs more guidance 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 fully documents all parameters. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no value added by the description.
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 ('현재 패스에 베지어 곡선을 추가합니다' - 'Adds a Bezier curve to the current path') with a specific verb and resource. It distinguishes itself from sibling tools like path_lineto or path_arcto by specifying the curve type, but doesn't explicitly differentiate from other path operations beyond the curve aspect.
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. There are multiple sibling path tools (path_lineto, path_arcto, path_close, etc.) but no indication of when a Bezier curve is appropriate versus other path segment types or how this integrates with the overall path creation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '추가합니다' (adds) implies a mutation, it doesn't disclose important behavioral aspects: whether this requires an active path context, what happens if no path exists, whether it's reversible, or any side effects. The description is minimal and lacks operational context.
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 states the core purpose without any wasted words. It's appropriately sized for a simple operation and front-loaded with the essential 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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what '현재 패스' (current path) means contextually, what happens after the line is added, or any prerequisites. Given the complexity of path operations and the lack of structured behavioral information, this leaves significant gaps.
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 (x, y, relative). The description doesn't add any additional meaning about parameters beyond what's in the schema. The baseline of 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 ('현재 패스에 직선을 추가합니다' - adds a straight line to the current path) and identifies the resource (path). It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like 'draw_line' or 'draw_path'.
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_line', 'draw_path', and 'path_curveto', there's no indication of when this specific path-building operation is appropriate versus other drawing or path manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'Playwright MCP 연동' (Playwright MCP integration), which adds some context about the underlying technology, but fails to describe key behavioral traits: whether this opens a browser window (hinted by the parameter but not stated in description), if it's read-only or modifies state, performance implications, or what the preview output looks like. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose in a single sentence. The additional note about Playwright integration is relevant but could be more integrated. There's minimal waste, though it could be slightly more structured to separate functional and technical details.
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 doesn't explain what 'preview' entails (e.g., opens a browser tab, generates a temporary URL), the scope of the canvas being previewed, or any dependencies. For a tool with no structured behavioral data, this leaves too much ambiguity 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 one parameter ('openBrowser') fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the schema's 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 tool's purpose: '현재 캔버스를 브라우저에서 미리봅니다' (previews the current canvas in a browser). It specifies the verb ('미리봅니다' - previews) and resource ('현재 캔버스' - current canvas), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'export_png' or 'export_svg', which also involve output/viewing operations.
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 mentions Playwright MCP integration, which hints at a technical context, but doesn't specify scenarios (e.g., for testing designs vs. exporting files) or compare it to sibling tools like export functions. Without explicit when/when-not instructions, usage is implied rather than clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 sets opacity, implying a mutation, but doesn't describe effects like whether changes are reversible, permission requirements, or error handling. 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 in Korean that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no annotations and no output schema), the description is incomplete. It lacks behavioral details, usage context, and output information, leaving gaps that could hinder an AI agent's ability to use it correctly. The schema covers parameters, but overall context is insufficient.
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 ('objectId' and 'opacity') clearly documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples. 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 tool's purpose: '객체의 불투명도를 설정합니다' (Sets the opacity of an object). It specifies the verb (sets) and resource (object opacity), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'layer_opacity', which might serve a similar purpose for layers rather than objects.
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 sibling tools like 'layer_opacity' or 'style_fill', nor does it specify prerequisites or exclusions. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Opens' is ambiguous - it doesn't specify whether this loads content into memory, displays it in an interface, makes it editable, or what permissions are required. For a file operation tool with zero annotation coverage, this leaves critical behavioral aspects unexplained.
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 sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and doesn't waste space on 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 file operation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'opening' means operationally, what happens after opening, potential errors (like missing files), or the tool's role in the broader SVG editing workflow alongside siblings like 'svg_create' and 'svg_save'.
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 fully documents the single 'filePath' parameter. The description doesn't add any additional meaning about parameter usage beyond what's in the schema. This meets the baseline expectation 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 ('opens') and target resource ('existing SVG file'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'svg_create' or 'svg_save', which would require more specific context about what 'opening' entails in this system.
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 (like file existence), distinguish from 'svg_create' for new files, or indicate when to use 'svg_open' versus 'svg_load' or other file operations 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.
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. While '저장합니다' (saves) implies a write operation, the description doesn't disclose important behavioral traits: whether this overwrites existing files, what permissions are needed, whether it modifies the current canvas state, what happens on failure, or what the tool returns. For a file system operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a tool with one optional parameter and clear core functionality.
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 file system write operation with no annotations and no output schema, the description is incomplete. It doesn't explain what happens when filePath is omitted ('기존 경로 사용' - use existing path) - what existing path? It doesn't describe the return value or error conditions. Given the complexity of file operations and lack of structured safety information, the description should provide more behavioral context.
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% (the filePath parameter is fully documented in the schema), so the baseline is 3 even with no parameter information in the description. The description doesn't add any meaning beyond what the schema already provides about the filePath parameter, but doesn't need to since schema coverage is complete.
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 ('저장합니다' - saves) and resource ('현재 캔버스를 SVG 파일로' - current canvas as SVG file). It's specific about what gets saved (current canvas) and the output format (SVG file). However, it doesn't explicitly differentiate from sibling tools like export_svg, which appears to be a related export function.
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 sibling tools like export_svg and export_png available, there's no indication of when svg_save is preferred over export_svg, or what distinguishes these two SVG-related tools. No prerequisites or contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('delete') but doesn't mention whether deletion is permanent, requires specific permissions, or what happens on success/failure. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 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?
For a destructive operation with no annotations and no output schema, the description is inadequate. It doesn't explain what 'delete' entails (permanent? reversible?), what confirmation or response to expect, or how to obtain the required templateId parameter.
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 the single parameter 'templateId' clearly documented in the schema. The description doesn't add any parameter details beyond what's already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('delete') and resource ('saved templates'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'object_delete' or 'layer_delete', which perform similar deletion operations on different resource types.
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. While 'template_list' and 'template_load' are obvious siblings, the description doesn't mention prerequisites (e.g., needing a template ID from 'template_list') or warn about irreversible deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states it retrieves a list, but doesn't disclose important behavioral traits like whether this is a read-only operation (implied but not stated), what format the list returns, whether there's pagination, authentication requirements, rate limits, or any side effects. For a list operation with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 unnecessary words. It's appropriately sized for a simple list operation and front-loads the core functionality.
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 the return value looks like (list format, structure, fields), doesn't mention any behavioral constraints, and provides minimal context for a tool with filtering parameters. For a list tool with three parameters and no structured output documentation, this should do more.
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 (category, tags, search) with descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 ('조회합니다' - retrieves/list) and resource ('저장된 템플릿 목록' - saved template list). It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like template_load or template_save, which have different purposes.
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. There's no mention of when this tool is appropriate compared to template_load (which loads a specific template) or template_save (which saves templates), nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it's a save operation, implying mutation, but doesn't disclose behavioral traits like whether it overwrites existing templates with the same name, requires specific permissions, returns a confirmation or ID, or has side effects (e.g., clearing the canvas). The description is minimal and lacks critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean with zero waste. It's front-loaded with the core action and appropriately sized for the tool's purpose, 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 tool's complexity (mutation with 4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on what 'current canvas' includes, behavioral aspects like overwrite behavior or return values, and usage context. For a save operation that likely modifies persistent data, this is inadequate.
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 (name, description, tags, category). The description adds no additional meaning beyond implying the template is based on the 'current canvas'. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like parameter interactions or examples.
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 ('현재 캔버스를 템플릿으로 저장합니다' - 'Save the current canvas as a template') with a specific verb and resource. It distinguishes from siblings like template_load and template_delete by focusing on creation rather than retrieval or deletion. However, it doesn't explicitly mention what 'current canvas' encompasses (e.g., all objects, styles, layers).
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., must have a canvas open), when not to use it (e.g., if canvas is empty), or compare with related tools like template_load or svg_save. Usage is implied from the action but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 analyzes colors but doesn't disclose behavioral traits such as what the analysis returns (e.g., color palette, usage frequency), whether it's read-only or has side effects, or any performance considerations. This is a significant gap for a tool with no structured safety hints.
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 in Korean that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis entails or what results to expect (e.g., a list of colors, statistics). For a tool that likely returns data about canvas colors, this omission leaves the agent uncertain about the tool's behavior and output, reducing its effectiveness in context.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully covers the lack of parameters, and the description doesn't need to compensate.
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 ('analyzes') and target ('colors used on the current canvas'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'ai_suggest_colors' or 'style_fill', but the verb 'analyze' implies examination rather than suggestion or application, which provides some 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active canvas), exclusions, or comparisons to siblings like 'ai_suggest_colors' (which might recommend colors) or 'style_fill' (which applies colors). This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '그립니다' (draws) implies a creation/mutation operation, but the description doesn't specify where the heart is drawn (e.g., on a canvas, in a document), whether it's interactive, what happens to existing elements, or any side effects like requiring specific permissions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's function without any fluff. It's appropriately sized and front-loaded, with every word earning its place.
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 the tool's moderate complexity (8 parameters, mutation implied) and no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidance, and output details. With 100% schema coverage for parameters, it's not completely inadequate but has clear gaps in other areas.
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 8 parameters well-documented in the schema (e.g., cx as center X coordinate, size with minimum 0). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 where 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 tool's purpose: '하트 모양을 그립니다' (draws a heart shape). It uses a specific verb ('그립니다' - draws) and resource ('하트 모양' - heart shape), making the function unambiguous. However, it doesn't differentiate from sibling drawing tools like draw_circle or draw_rect, which would require a 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. There are many sibling drawing tools (draw_circle, draw_rect, draw_star, etc.), but the description doesn't indicate when a heart shape is appropriate versus other shapes, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 creates something, implying a write/mutation operation, but doesn't specify what happens after creation (e.g., whether the canvas becomes active, if it's saved automatically, or if it requires subsequent export). For a creation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 wasted words. It's appropriately sized for a straightforward creation tool and is front-loaded with the essential action. Every word earns its place.
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 the tool's moderate complexity (5 parameters, creation operation) and the absence of both annotations and an output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context (e.g., what the output is, whether creation is immediate/permanent) and usage guidance. The high schema coverage helps, but for a creation tool with no output schema, more completeness would be beneficial.
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 5 parameters clearly documented in the schema (width, height, viewBox, background, preserveAspectRatio). The description adds no parameter-specific information beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 ('새 SVG 캔버스를 생성합니다' translates to 'creates a new SVG canvas') and identifies the resource (SVG canvas). It distinguishes from siblings like svg_open (opens existing SVG) and svg_resize (modifies existing canvas). However, it doesn't explicitly differentiate from other creation tools like layer_create or path_create, which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 empty workspace), when not to use it (e.g., when modifying existing canvases), or point to sibling tools like svg_open for existing files or svg_resize for dimension changes. 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.
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. It states the tool sets the background color, implying a mutation, but doesn't disclose behavioral traits like whether it requires an active canvas, if changes are reversible, or any side effects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's purpose. It's front-loaded with no unnecessary words, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage and no output schema, the description is minimally adequate. However, as a mutation tool with no annotations, it lacks details on behavior, error handling, or output, leaving gaps in context that could hinder 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 the 'color' parameter documented as accepting hex, rgb, or color names, and empty for transparent. The description doesn't add any meaning beyond this, so it meets the baseline of 3 where 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 ('캔버스 배경색을 설정합니다' translates to 'Sets the canvas background color') and identifies the resource (canvas). It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like 'style_fill' or 'style_gradient' which might also affect colors, but the focus on background is clear.
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 lacks context about prerequisites, such as whether a canvas must be open, or exclusions, like not applying to specific objects. It's a basic statement of function without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it retrieves lists, implying a read-only operation, but doesn't specify aspects like whether it returns all layers at once, if there's pagination, error conditions, or performance considerations. 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, clear sentence in Korean that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently communicates the core functionality, making it easy to understand at a glance.
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 the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context. For a simple list tool, this might suffice, but it doesn't provide full context for reliable agent use without additional inference.
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, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required, but it also doesn't compensate for any gaps since none exist.
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 '모든 레이어 목록을 조회합니다' (Retrieves all layer lists) clearly states the action (retrieves) and resource (layer lists). It distinguishes from siblings like layer_create, layer_delete, or layer_select by focusing on listing rather than modifying or selecting specific layers. However, it doesn't explicitly differentiate from object_list, which might list objects rather than layers, leaving slight 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. It doesn't mention prerequisites, such as needing layers to exist, or compare to other list-related tools like object_list or history_list. Without such context, users must infer usage based on 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.
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 closes the current path and connects to the starting point, but lacks details on effects (e.g., whether it finalizes the path for editing, modifies existing objects, or requires specific states), permissions, or error conditions, leaving 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 in Korean that directly states the tool's action without redundancy. It's front-loaded with the core purpose ('현재 패스를 닫습니다') and adds clarifying detail in parentheses, making every word count.
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 0 parameters and no output schema, the description is minimally adequate but incomplete. It explains what the tool does but lacks behavioral context (e.g., side effects, state requirements) that would be crucial for safe invocation, especially without annotations to compensate.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information 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 ('닫습니다' - closes) and the resource ('현재 패스' - current path), specifying it connects to the starting point. However, it doesn't differentiate from sibling tools like 'path_finish' or 'path_cancel' which might have similar path-related functions, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., requires an active path), exclusions, or comparisons with siblings like 'path_finish', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '조회합니다' (retrieves) implies a read-only operation, it doesn't disclose what specific information is returned, whether there are any side effects, or any behavioral constraints. For a tool with zero annotation coverage, this minimal description leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple tool with no parameters, and the information is front-loaded without unnecessary elaboration.
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 zero-parameter tool with no output schema, the description provides basic purpose but lacks important context about what specific canvas information is returned. Without annotations or output schema, the description should ideally specify what '정보' (information) includes - dimensions, metadata, current state, etc. - to be complete enough for an agent to understand what to expect.
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 the schema fully documents the absence of parameters. The description appropriately doesn't discuss parameters since none exist, which is correct. The baseline for 0 parameters is 4, and the description doesn't incorrectly mention parameters that don't exist.
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 ('조회합니다' meaning 'retrieves/inquires') and resource ('현재 캔버스의 정보' meaning 'current canvas information'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'object_list' or 'layer_list' that might also retrieve information about different aspects of the SVG editor.
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 many sibling tools that retrieve information (like 'object_list', 'layer_list', 'history_list'), there's no indication whether this tool provides broader canvas metadata, summary information, or something distinct from those other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the tool starts a path builder and references follow-up tools, but doesn't disclose critical behavioral traits: whether this creates a persistent object, what happens if used multiple times, whether it requires specific permissions, or what the expected workflow is. For a tool that likely creates mutable state, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that efficiently communicate the tool's purpose and usage pattern. Every word earns its place, and the information is front-loaded with the core action first, followed by workflow context.
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 2 parameters with full schema coverage and no output schema, the description provides adequate basic information about purpose and workflow. However, for a tool that likely creates mutable graphical state as part of a sequence, the description should address more behavioral aspects like what happens to incomplete paths, whether multiple paths can exist simultaneously, or error conditions.
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 (startX and startY as coordinates). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained why these coordinates matter for path building.
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 ('새 패스 빌더를 시작합니다' - starts a new path builder) and the resource (path builder). It distinguishes from siblings like 'draw_path' by focusing on path construction rather than drawing a complete path. However, it doesn't explicitly differentiate from 'path_curveto' or 'path_lineto' which are mentioned as follow-up tools rather than alternatives.
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 provides clear context about when to use this tool: as the starting point for path construction, followed by path_lineto, path_curveto, etc., and ending with path_finish. It implicitly suggests this is part of a sequence but doesn't explicitly state when NOT to use it or mention alternatives like 'draw_path' for simpler paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it mentions the output format (Data URI) and a use case (image tags), it doesn't describe important behavioral aspects like whether this is a read-only operation, what happens with invalid input, if there are size limitations, or what the return value looks like. For a conversion tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded. The first sentence states the core functionality, and the second sentence in parentheses provides valuable additional context about use cases. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (conversion operation with one parameter), no annotations, and no output schema, the description provides adequate but incomplete context. It covers the what and a key use case but lacks information about behavioral traits, error handling, and return values. For a tool with no annotations or output schema, it should do more to compensate for these gaps.
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 well-documented parameter ('encode' with enum values and default). The description doesn't add any parameter-specific information beyond what the schema provides. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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's purpose with a specific verb ('변환합니다' - converts) and resource ('SVG를 Data URI 형식으로' - SVG to Data URI format). It distinguishes itself from sibling tools like export_png and export_svg by specifying the output format (Data URI) and a key use case ('이미지 태그에 직접 사용 가능' - can be used directly in image tags).
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 provides clear context for when to use this tool: when you need to convert SVG to Data URI format for direct use in image tags. However, it doesn't explicitly state when NOT to use it or mention alternatives like export_png or export_svg for different export needs. The guidance is helpful but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. The description reveals this is a file export operation (implying file system writes) and mentions a limitation about current PNG export quality (recommending SVG+separate conversion instead). However, it doesn't disclose other important behavioral traits like error conditions, performance characteristics, or what happens when the file already exists. The note about SVG conversion adds useful context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences: a clear purpose statement followed by a helpful note. Every word earns its place, and the most important information (what the tool does) comes first. The parenthetical note provides valuable context without unnecessary elaboration.
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 this is a file export tool with 3 parameters, no annotations, and no output schema, the description provides adequate but minimal context. It states the purpose and includes a practical limitation note, but doesn't cover important aspects like what the tool returns, error handling, or performance considerations. For a tool that writes files to the filesystem, more behavioral context would be helpful, though the concise description covers the essentials.
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 (filePath, scale, background) with their descriptions, types, constraints, and defaults. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 tool's purpose: 'PNG 파일로 내보냅니다' (Exports to PNG file). This is a specific verb+resource combination that indicates it creates PNG files. However, it doesn't explicitly differentiate from sibling tools like 'export_svg' or 'export_data_uri' beyond the note about SVG conversion.
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 provides clear context about when to use this tool: 'PNG 파일로 내보냅니다' (Exports to PNG file). The parenthetical note offers guidance about current limitations: '(참고: 현재는 SVG를 저장하고 별도 변환 도구 사용 권장)' (Note: Currently, it's recommended to save as SVG and use a separate conversion tool). This gives practical advice about alternatives, though it doesn't explicitly name when NOT to use this tool versus other export options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes the tool's destructive nature ('삭제합니다' - deletes) and irreversible consequence ('되돌릴 수 없음' - cannot be undone), which is critical for a mutation tool. However, it lacks details on permissions, side effects, or what 'history' specifically refers to in this context.
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 and front-loaded, consisting of one sentence that states the action and a parenthetical warning. Every word earns its place, with no redundancy or unnecessary information, making it highly efficient for an AI agent to parse.
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 the tool's high complexity (destructive, irreversible action) and lack of annotations or output schema, the description is somewhat complete but has gaps. It covers the core action and warning, but does not specify what 'history' entails (e.g., undo/redo stack, session data) or confirm successful deletion, which could leave ambiguity for an AI agent.
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 does not mention parameters, which is appropriate. A baseline score of 4 is given as it compensates adequately for the lack of parameters by focusing on the tool's action and warning.
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's purpose with a specific verb ('삭제합니다' - deletes) and resource ('모든 히스토리' - all history). It distinguishes itself from sibling tools like history_list, history_undo, and history_redo by focusing on deletion rather than listing or navigation.
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 provides clear context for when to use this tool through the warning note ('주의: 되돌릴 수 없음' - caution: cannot be undone), which implies it should be used when permanent deletion of all history is intended. However, it does not explicitly mention alternatives like history_list for viewing or when not to use it (e.g., for partial deletions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![svg-canvas-mcp MCP server](https://glama.ai/mcp/servers/kim62210/svg-canvas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kim62210/svg-canvas-mcp)

Score Badge

Copy to your README.md:

[![svg-canvas-mcp MCP server](https://glama.ai/mcp/servers/kim62210/svg-canvas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kim62210/svg-canvas-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kim62210/svg-canvas-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server