inkscape-mcp

by jjjsood

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose, reinforced by 'When to use' sections that explicitly differentiate it from related tools. Even similar operations like create_rect vs create_circle vs create_ellipse are well-distinguished.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., create_rect, set_fill, export_document). No mixing of conventions or ambiguous verbs.
Tool Count1/5
With 87 tools, the count far exceeds the calibration's 'extreme mismatch' threshold for a single server. While each tool may have its place, the sheer volume risks overwhelming an agent and suggests insufficient consolidation.
Completeness4/5
The tool surface covers nearly all core SVG editing operations—creation, styling, transforms, grouping, export, live editing, validation, and optimization. Minor gaps exist (e.g., boolean operations, filters), but agents can accomplish most tasks without dead ends.
Average 4.8/5 across 87 of 87 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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?
The description claims idempotency ('IDEMPOTENT: a second call ... reports changed=False'), but the annotation sets idempotentHint=false, creating a direct contradiction. This is a critical failure and override any positive behavioral disclosures.
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 well-structured with sections (purpose, when to use, key params, behavior, return shape, example, warning) and front-loads the core purpose. It is slightly verbose when repeating return shape details, but overall efficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the idempotency contradiction, the description covers usage, behavior, error cases, and a warning. With an output schema existing, it provides ample context for a one-parameter tool. The contradiction slightly undermines completeness, but the description is otherwise thorough.
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% description coverage, so the description must compensate. It clearly states 'Key params: none beyond doc_id', identifying the sole parameter and implying no others. While it doesn't detail doc_id's format, the context of a single required parameter makes it adequate. Baseline for 0 params is 4, and this fits.
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 action: 'Fit the document's root viewBox to its CONTENT bounding box.' It uses a specific verb and resource, and distinguishes from siblings like resize_canvas and normalize_viewbox by explicitly contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (cropping the page to frame the drawing) and when to use alternatives (resize_canvas for explicit page size, normalize_viewbox for repairing viewBox). This leaves no ambiguity for the agent.
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?
The description claims destructive behavior (deletes snapshots/frames), but the annotation has readOnlyHint: true, which contradicts. Per rules, score 1 for contradiction. The description is otherwise detailed but the contradiction invalidates trust.
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?
Well-structured with clear sections: purpose, when to use, key params, return shape, example, risk class. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers retention policy details, what is kept, what is deleted, output shape (PruneResult), and risk class. Output schema exists so explaining return values is unnecessary. Complete for agent decision-making.
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?
Only one parameter doc_id with no schema description. Description mentions it's the only key param and gives an example, but does not elaborate on its format or constraints. Schema coverage 0% means description should compensate more, but it's adequate for a simple param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a retention policy to prune superseded snapshots and live-frames, using specific verbs like 'pruning' and 'reclaiming disk'. It distinguishes from siblings like `restore_snapshot` and `list_snapshots`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (reclaim disk), when not (roll back use restore_snapshot, list use list_snapshots), and notes it's an explicit maintenance sweep, not triggered implicitly.
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?
The description claims a write operation ('write-new snapshot') while annotations declare readOnlyHint=true, creating a direct contradiction. Despite providing additional context like risk class, the inconsistency severely undermines 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?
Four sentences, well-structured with clear sections (purpose, usage, params, return shape, risk). No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, key params, return shape (SnapshotInfo with metadata), example, and risk class. Despite annotation contradiction, the description itself is complete for what the tool does.
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?
With 0% schema coverage, the description adds meaningful detail: label is optional, length-bounded, and over-cap results in rejection. The example demonstrates usage. Could mention doc_id type/format but overall compensates well for schema gaps.
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 verb 'snapshot the current working copy of a document and index it,' specifying both action and resource. It distinguishes itself from sibling tools list_snapshots and restore_snapshot by stating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (checkpointing before risky edits) and when not to (browsing or rollback should use other tools). Also notes that mutating tools auto-snapshot, so this is an explicit manual checkpoint.
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?
The description contradicts the readOnlyHint annotation (true) by detailing that dry_run=False writes files to the workspace. This is a serious inconsistency; the description itself is otherwise transparent about behavior, but the contradiction forces a score of 1.
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 front-loaded with the core action in the first line, well-structured with sections for usage, parameters, return shape, and example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no schema descriptions, presence of output schema), the description covers purpose, usage context, parameter details, return shape, example, and risk class. It is comprehensively informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, including format options, optional fields, default values, and special behaviors like byte_budget and sandbox-checked out_dir.
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 exports a bounded batch of typed export specs. It distinguishes from sibling tools like export_document and export_object for single exports and create_icon_set for icon sets, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (exporting many sizes/formats/objects in one call) and when not to (single exports or standard icon sets), naming alternatives. Provides clear guidance on dry-run vs real execution and budget constraints.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds risk class 'low (read-only)' and references ADR-005, providing extra context without contradiction.
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 and well-structured with bullet points, bold for emphasis, and an example. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient detail on return shape (InspectDocumentResult with fields), includes an example, and covers risk. Output schema exists, so detailed return specs are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Only states 'Key params: doc_id only (read-only)' but does not explain what doc_id represents or how to obtain it, leaving ambiguity.
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?
Clear verb 'inspect' and resource 'loaded document' with specific aspects listed (tree, layers, styles, etc.). Explicitly distinguishes from siblings like find_objects, quality_report, validate_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('go-to overview') and when not, with specific alternative tools for filtering (find_objects), quality (quality_report), and validation (validate_document).
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?
Annotations indicate write operation (readOnlyHint false) but not destructive. Description adds context: 'reversible write-new', validation of fill/stroke like set_fill/set_stroke, and advice to preview before trusting. However, annotations already convey the basic safety profile.
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?
Description is well-structured with core purpose, usage, params, return, example, risk. Front-loaded but includes some redundancy (e.g., validation detail). Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, output schema exists, and annotations provide base info, the description adds all needed context: return shape, example, risk class, validation behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains key parameters: width/height >0, rx/ry optional, parent_id must exist, object_id pins id, fill/stroke validated like set_fill. Provides meaningful guidance beyond raw schema types.
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?
Description clearly states it creates a `<rect>` element with position, size, and optional radii. Distinguishes from siblings like create_circle, create_ellipse, create_path by explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('drawing a rectangle / square / box') and when not (ellipse, freeform). Also provides risk class and revertibility advice.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that the whole set is rejected on any single failure (no partial results) and labels risk as low, composing the per-doc engine. This adds useful behavioral context beyond annotations.
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 well-structured with clear sections (purpose, when to use, key params, return shape, example, risk class) and is front-loaded with the main action. It is concise for the complexity but could potentially be shortened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, output schema, and complex behavior, the description covers all necessary aspects: purpose, usage, parameter semantics, return shape (per_doc, total_items, total_bytes, consistency with detailed cross-doc verdict), and a concrete example. It feels complete and self-contained.
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?
With 0% schema description coverage, the description compensates by explaining key params: doc_ids must be non-empty and duplicate-free, specs is identical to export_batch's list, and dry_run/byte_budget/out_dir/name_prefix behave exactly as in export_batch. It also notes name_prefix is recommended to avoid collisions. Not all six params are fully detailed, but the critical ones are well-covered.
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 explicitly states 'Batch-export a SET of documents in one call' with specific outputs (per-doc results + aggregate + verdict). It distinguishes from siblings like export_batch and create_icon_set, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section gives explicit context for multi-document exports and names alternatives (export_batch for single documents, create_icon_set for icon sets). This provides clear guidance on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, but the description adds significant behavioral details: modal socket bridge (GUI freezes), no_freeze mode via DBus, which operations are available in each mode, and clean failure when no transport is available. This far exceeds what annotations convey.
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 dense and informative but slightly lengthy. It uses well-placed line breaks and headings, but some sentences could be tightened. Every sentence adds value, but overall conciseness could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (starting a live session with transport selection), the description covers purpose, usage, parameters, behavior, return shape (LiveSession), and risk class. It does not explain the output schema in detail, but that is acceptable since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. It explains the 'prefer' parameter with two options: 'read' (default, modal, full surface) and 'no_freeze' (limited but non-blocking). It details the trade-offs and available operations for each, providing clear semantics.
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 'Connect to a running Inkscape over the best-ranked available transport (enables live).' It specifies the action (connect) and the resource (running Inkscape), and distinguishes from sibling tools like live_disconnect and check_live_support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage context: 'When to use: starting a live session before any other live_* tool. To probe first use check_live_support; to tear down use live_disconnect.' This clearly guides when to use this tool and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false. Description adds 'Risk class: low (read-only; document unchanged)' and details return shape including fields and structure. Adds significant context beyond annotations.
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?
Well-structured with clear sections (purpose, usage, params, return shape, example, risk). Each sentence adds value, though slightly verbose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema existence, description comprehensively covers validation findings, metrics, opportunities structure. Single param is simple. No gaps for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but tool has only one parameter doc_id. Description mentions 'Key params: none beyond doc_id' and includes it in example, but does not explain its purpose or format. Adequate for a simple single-param tool but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'build' and resource 'machine-readable quality report for a document'. Distinguishes from siblings validate_document and svg_web_optimize by scope and use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (assessing document health) and when not (pass/fail correctness -> validate_document, stripping opportunities -> svg_web_optimize). Provides clear alternatives.
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?
Describes return shape (CreateResult with object_id and pipeline fields), warns about rendering before trusting, and classifies risk as medium (reversible write-new). This adds context beyond annotations, though no auth or rate limit details.
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?
Compact yet comprehensive: one paragraph with clear sections (action, usage, key params, return shape, example, risk warning). Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers everything needed: what it does, when to use, parameter details, return shape, example, and safety warning. No gaps for an agent to misuse.
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?
With 0% schema description coverage, the description compensates well by explaining stops (with format), cx, cy, r, fx, fy and their defaults. An example is provided. However, doc_id and object_id are not explained, but they are standard parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a radialGradient to the document defs, and distinguishes from the sibling tool add_linear_gradient by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (centred/radial colour fade), when not to (directional fade -> use add_linear_gradient), and how to apply the gradient afterwards with set_fill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it creates a new element, mentions reversibility via restore_snapshot, and risk class medium. Adds context beyond annotations.
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?
Organized with clear sections: purpose, usage, params, return, example, safety. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: function, parameters, return shape, example, safety. Output schema exists for return values, and the description completes the picture.
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?
Explains key parameters like r>0, cx, cy, fill, stroke, stroke_width, parent_id, object_id with validation notes. With 0% schema coverage, it compensates well, though doc_id is only in example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a `<circle>` with center (cx,cy) and radius r. It distinguishes from siblings by mentioning alternatives for ovals and rectangles.
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?
Explicitly says 'When to use: drawing a circle / disc' and provides alternatives. Lacks explicit when-not but gives sufficient context.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds significant context: 'Risk class: medium (creates a new tracked document; no existing state mutated),' explains the generated document is validate_document-clean, and mentions the output shape and tracking features. It could be slightly more concise, but adds value beyond annotations.
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 well-structured with clear sections: summary, usage, key parameters, return shape, example, and risk class. Every sentence adds value, though it is a bit long. A minor trim would make it more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 params, no enums, and an output schema, the description covers everything: parameter details, default behavior (viewBox synthesis), return shape references (OpenDocumentResult), risk class, and even an example. It is complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does: explains width/height are in user units (>0), viewBox is optional with format 'minx miny w h' and synthesized default, background is validated colour types with anti-injection. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a blank, tracked working-copy document from scratch — NO source file required.' and distinguishes from siblings like open_document and set_document_svg, making the purpose very clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear 'When to use' section: 'starting fresh authoring...when there is no SVG to open.' It also states when not to use: 'To open an EXISTING file use open_document; to set the whole SVG body afterwards use set_document_svg.' This gives explicit guidance with alternatives.
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?
Discloses that out-of-range sizes are rejected before Inkscape runs, out_dir is sandbox-checked, and no partial set is written. Describes return shape and risk class. Adds value beyond annotations which already indicate readOnlyHint=true and destructiveHint=false.
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?
Well-organized with sections: purpose, when to use, key params, return shape, example, risk. Every sentence earns its place; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, presence of output schema, and annotations, description covers usage, param details, output format, example, and risk. Fully sufficient for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains key parameters: sizes constraint (positive integer ≤ cap), out_dir anchoring to workspace root, name_prefix tagging. Adds meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Export a multi-size square PNG icon set from the source document.' Distinguishes from siblings export_web_profile and export_batch by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use: 'producing a standard square icon set in one call.' Directs to alternatives for other needs, giving clear usage boundaries.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds return shape details, risk class 'low (read-only listing)', and clarifies the series parameter behavior, providing context beyond annotations.
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?
Well-structured with clear sections (summary, when to use, key params, return shape, example, risk class). Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given low complexity: covers purpose, usage, parameters, return shape, and risk. Output schema exists, so detailed return description is not needed. Includes an example for clarity.
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?
Despite 0% schema coverage, description explains the key `series` parameter: sanitized identically to `capture_frame`, defaults to `run`. This adds meaningful context that is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists frames of a `capture_frame` series, ordered by index. It distinguishes from sibling `capture_frame` by specifying when to use this tool vs producing frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'When to use: gathering a whole run's PNGs at the end without re-deriving paths.' Also directly contrasts with `capture_frame` for producing frames.
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?
Annotations already declare readOnlyHint=true. Description adds context: requires established session, return shape (LiveDocumentRef), example, and risk classification. No contradictions.
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?
Five well-structured sentences covering purpose, usage, parameters, return, example, and risk. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, prerequisites, return object, example, and risk class. With an output schema present, no further details 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?
No parameters, schema coverage 100% (empty schema). Description notes 'Key params: none', which is sufficient. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'identify' and resource 'document' in a connected live instance, and explicitly distinguishes this tool from siblings like live_get_scene and live_get_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section states the exact use case: confirming which document is open. Also provides alternatives (live_get_scene, live_get_selection) and prerequisite (requires live_connect session).
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds value by disclosing 'Not available over DBus (`no_freeze`) — stays on the modal socket transport' and 'Requires an established session (`live_connect`)', which are beyond annotations.
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?
Well-structured with distinct sections: purpose, when-to-use, limitations, prerequisites, return shape, example, risk. Every sentence adds unique value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, transport constraint, session requirement, return shape (mentioning `LiveSelection` with count and ids), and an example. Output schema exists, so return details are complete. No gaps for a simple zero-parameter read-only tool.
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?
No parameters in schema; description mentions 'Key params: none' and gives an example call. Baseline for zero-parameter tools is 4, and description adds no further semantics but is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Read the current selection in the live instance as object ids (read-only)' with a specific verb and resource. Clearly distinguishes from siblings by referencing `live_inspect_selection` for semantic detail and `live_get_scene` for the whole scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'getting the ids the user selected in the GUI.' Provides clear alternatives ('For their semantic detail use `live_inspect_selection`; for the whole scene use `live_get_scene`') and notes transport limitation and session requirement.
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?
Description adds context beyond annotations: read-only, transport restriction (no DBus), session prerequisite, and return shape. Annotations already cover safety, but the description enriches understanding.
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?
Description is efficient and well-structured with clear sections (When to use, Key params, Return shape, Example, Risk class). Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description covers prerequisites, constraints, return shape, and example. It is fully complete for the tool's complexity.
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?
No parameters exist, and schema coverage is 100%. Description correctly states 'Key params: none.' No further detail needed; baseline is met and slightly exceeded by explicitly noting lack of params.
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?
Description clearly states verb 'Inspect', resource 'selected objects', and context 'live instance, read-only'. It distinguishes from siblings by specifying the alternative tools for ids and whole scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (structured detail of GUI selection) and when not (not over DBus). Names alternatives `live_get_selection` and `live_get_scene`. Also mentions requirement of established session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal info (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds rich behavior: idempotency for valid viewBox, synthesis/recovery for absent/malformed, reversibility on working copy, return shape with diff, and risk warning. No contradiction with annotations.
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?
Description is well-structured with clear sections: purpose, usage, key params, return shape, example, risk warning. Every sentence adds value and the most important information (what it does) is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers all needed aspects: purpose, when to use, behavior, return, risk, and references to siblings. It is fully complete for an agent to select and invoke 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 has 1 param (doc_id) with 0% description coverage. Description mentions 'Key params: none beyond doc_id', acknowledging the parameter but adding no further details about its type or usage. For a single simple parameter, this is adequate but minimal added value.
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 normalizes/repairs the root viewBox. It specifies the action and resource, and distinguishes from siblings fit_to_content and resize_canvas by naming them as alternatives for 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: tidying/repairing a missing or malformed root viewBox.' and provides when-not-to-use guidance with alternative tool names, offering clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark as readOnlyHint=true and destructiveHint=false; description adds details like rendering full canvas without UI chrome, indexing behavior (monotonic, survives restart, no clobber), and risk class (low, no overwrite). No contradiction with annotations.
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?
Well-structured with sections (purpose, when to use, key params, return shape, example, risk). Slightly lengthy but all information is valuable and front-loaded. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and output schema, description covers indexing, artifact path, return shape (FrameResult fields), inline vs. structured, and risk. Example provided. Completeness is high.
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 has 0% description coverage, but description explains key parameters: series (sanitized, defaults to run), label (folded into name), inline (controls output), and max_output_bytes. Width_px is not elaborated, so not fully exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool captures the next numbered PNG screenshot in a per-run frame series. Distinguishes from siblings by mentioning render_preview for one-off checks and list_frames for gathering series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (documenting scripted edit sequences) and when not to, with alternatives: render_preview for one-off, list_frames for finished series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deep-copy, scaling behavior, grid fill order, cell bound, reversibility, risk class; annotations are minimal so description carries full burden and excels.
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?
Well-structured with sections (purpose, when to use, key params, return, example, caution). Slightly verbose but every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (10 params, output schema exists), description covers purpose, usage, behavior, parameter semantics, return shape, and risk. Output schema handles return details.
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?
Adds meaning beyond schema: explains source mode (doc_ids vs object_ids+source_doc_id), scale_to_fit default, gap/padding, target_doc_id. With 0% schema coverage, description compensates well but not every param is detailed.
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?
Specifies verb 'compose', resource 'grid of different assets', scope 'one reversible call', and distinguishes from siblings 'tile' and 'insert_svg_fragment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (multi-asset sheet) and when not (use 'tile' for repeating one object, 'insert_svg_fragment' for single subtree), plus key param guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive, and the description adds significant behavioral context: it's a write-new operation on the working copy, reversible, medium risk. It also recommends using render_preview to verify, which aligns with the annotations and provides actionable safety information.
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 well-structured with sections (purpose, usage, key params, return shape, example, risk). While it is relatively long, every sentence adds value and is front-loaded with essential information. Could be slightly trimmed but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 5 required, output schema exists), the description covers all necessary aspects: creation semantics, parameter constraints, optional styling, return shape, example, and risk/revert guidance. It provides complete context for correct usage.
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?
With 0% schema description coverage, the description compensates well by explaining all key parameters (cx, cy, rx, ry, fill, stroke, stroke_width, parent_id, object_id) and their constraints. Only doc_id is not explicitly described but is clear from context. It adds meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates an `<ellipse>` element with specific parameters (cx, cy, rx, ry). It clearly distinguishes from sibling tools `create_circle` (for perfect circles) and `create_rect` (for boxes), providing a clear and specific verb-resource mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: drawing an oval / ellipse' and directs to alternatives for other shapes. It also provides constraints (rx/ry > 0, parent_id must exist) and a risk classification, offering thorough usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses multiple behavioral details beyond annotations: d validation (strict charset, length-bounded, not fully parsed), optional paint parameters validated like set_fill/set_stroke, default unpainted, parent_id requirement, return shape with bbox=None, and risk class 'medium reversible write-new'. The annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the full burden and does so thoroughly.
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 well-structured with clear sections (When to use, Key params, Return shape, Example, Render advice, Risk class). It is slightly lengthy but every section adds value. Front-loading the main purpose helps quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: purpose, usage conditions, parameter behavior, return shape with example, risk assessment, and integration with sibling and preview tools. Given the tool's complexity and the presence of an output schema (mentioned), the description is highly complete.
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?
With 0% schema description coverage, the description explains most key parameters: d (validation details), parent_id (must exist or default), fill/stroke/stroke_width (optional, validated, default None). However, doc_id and object_id are not explicitly described, leaving a minor gap. Overall, it adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'create' and resource 'path', with explicit differentiation from sibling tools like create_rect, create_circle, and editing paths via simplify_path. The description includes specific when-to-use guidance, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (freeform/bezier/curve geometry) and when not (prefer primitives for simple shapes; use paths tools for edits). Includes a recommendation to render and inspect via render_preview before trusting the edit, and mentions restore_snapshot for reversion. This offers clear context for safe and appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral details beyond annotations: deletion is reversible, silently skips non-existing ids, cannot delete document root, requires approval_token, and return shape details. Annotations already indicate destructiveHint=true, so no contradiction.
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?
Well-structured, front-loads purpose, then usage guidelines, parameter details, return shape, example, and caution. Slightly long but all content is useful; no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return shape (DeleteResult with all EditResult fields plus affected_ids) and edge cases. Also provides risk class and safety steps (render preview, restore_snapshot). Fully adequate.
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 has 0% description coverage, but description provides substantial meaning: object_ids as non-empty list with silent skip behavior, approval_token required for high risk (minted out of band), and doc_id implied. This compensates well for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Delete objects by id from a document in ONE reversible, snapshot-backed operation.' Distinguishes from reparent_object and rename_object, providing explicit alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (dropping elements without full rebuild), when not to use (moving or renaming), and where to get ids (find_objects/inspect_document). Also covers prerequisites like approval_token for high risk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint. The description adds valuable behavioral context: output always differs from plain PDF due to PDF version pinning, exports to sandbox-checked dir, no original overwrite.
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 well-structured with sections (When to use, Key params, Return shape, Example, Risk class) and front-loaded with the main purpose. Slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description explains the return shape and provides an example. It covers complexity well, ensuring an agent can use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains out_dir (anchors to workspace root, sandbox-checked) and name_prefix (tags file). doc_id is not explicitly described but is implied. This compensates for the schema gap.
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 exports a print-oriented PDF with specific properties. It distinguishes from sibling tools like export_web_profile and export_document by stating when each should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines: use for press-safe PDF, not for web assets (use export_web_profile) or plain export (use export_document).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false. Description adds risk class (low), no original overwrite, sandbox checking, and pixel-capping behavior. No contradiction with annotations.
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?
Well-structured with sections (purpose, usage, key params, return shape, example, risk). Slightly verbose but each sentence adds value. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 0% schema coverage, and an output schema, the description covers parameter interactions, return shape, typical usage, and risk. Output schema is mentioned but not detailed, which is acceptable since it exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains key parameters: widths, scales, width_px interaction, out_dir semantics (relative to workspace root, sandbox-checked), and name_prefix. Doc_id is not explained, but the description provides significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports a web-oriented asset set (responsive PNGs plus SVG). It distinguishes from siblings like export_print_profile, create_icon_set, and export_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section and alternative tools provided. Clearly specifies when this tool is appropriate and when to use siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals that objects keep their transforms/styles, only parent changes, and specifies the return shape (CreateResult). It also states risk class 'medium (reversible write-new)'. No contradiction.
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 well-structured with sections like 'When to use', 'Key params', 'Return shape', 'Example', and 'Risk class'. It is efficient and front-loaded, but could be slightly more concise by combining some sentences. However, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description explains return shape and pipeline fields. It covers usage guidelines, parameter details, behavioral notes, an example, and a safety note about rendering and restoring. It is fully complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains object_ids (≥1, all must exist) and object_id (to pin new group id). The doc_id parameter is mentioned but not detailed, which is acceptable as it's a common parameter. Overall adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool wraps existing objects into a new group, using the verb 'Wrap' and the resource 'objects'. It distinguishes from sibling tools create_group and reparent_object by specifying their different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'collecting several existing objects under one group.' It also includes when-not-to-use by directing to alternatives for empty groups (create_group) and single object moves (reparent_object).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses launching headful Inkscape, installing helper, display requirement, clear failure on headless, session reuse, and risk class. No contradiction with annotations; adds value beyond readOnlyHint, destructiveHint etc.
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?
Description is detailed but efficient; each sentence adds value. Slightly long but appropriate for complexity. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, return shape (SocketArmResult), example, risk. Output schema exists; description completes context for tool with side effects and prerequisites.
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?
No parameters in schema; description confirms 'Key params: none'. Baseline 4 applies as no param info needed and description acknowledges absence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Auto-arm' and resource 'extension-socket helper' with effect of getting 'FULL live surface'. Distinguished from siblings like live_connect, live_install_helper, check_live_support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: bringing up full command set without human click, programmatic launch otherwise limited. Mentions post-action call to live_connect, alternative tools for installation and readiness check, and reuse of existing session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond annotations: deterministic rendering via transport (not OS screenshot), caching mechanism, data source (get_scene command), requirement for established session, and read-only nature. The risk class is also stated. No contradiction with annotations; readOnlyHint is consistent.
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 well-structured with clear sections: purpose, when to use, parameter details, behavioral notes, return shape, example, and risk class. While thorough, it is not excessively verbose; every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema exists, annotations present), the description covers all critical aspects: purpose, parameters, behavior, return shape (LiveSceneFrame with render and scene), an example, and risk classification. The presence of an output schema means detailed return fields are documented elsewhere, so the summary is sufficient.
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?
With 0% schema coverage, the description adds significant value by explaining how region/scale/fast work, including constraints (w/h > 0, scale > 0) and behavior (fast=True for preview, explicit scale wins). This compensates well for the schema's lack of descriptions.
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 captures a live frame as both a PNG and a structured LiveScene. It distinguishes from sibling tools live_render_view (pixels only) and live_session_step (one loop iteration), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('core perception step') and when not to use, including direct mentions of alternative tools (live_render_view, live_session_step). This provides clear guidance for tool selection.
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?
The description explains the tool writes files (copies helper), requires opt-in, and does not touch the workspace document. Annotations already provide non-read-only status, but description adds useful context. No contradiction.
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?
Well-structured with clear sections: action, usage, params, return shape, example, risk class. Every sentence is informative and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of output schema, the description covers prerequisites, return shape, file operations, and risk class. No gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is 100%. The description adds value by naming the specific files copied (inkscape_mcp_live.py + .inx) and linking to output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs the extension-socket helper into Inkscape's user extensions directory. It is distinct from sibling tools like live_connect or check_live_support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates 'When to use: one-time setup' and suggests subsequent steps: 'probe with check_live_support then live_connect'. Also mentions requirement for the master gate.
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?
Annotations already provide readOnlyHint and destructiveHint. Description adds details on deterministic rendering, caching, and risk class, enhancing beyond annotations.
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?
Concise yet comprehensive: covers usage, parameters, example, return shape, and risk. Well-structured with clear sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all aspects: parameters, output schema, caching, rendering source, and risk. No missing information given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains all parameters: region constraints, scale, fast, and ordering rules. Provides context on validation and caching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Rasterize the live canvas to a PNG' with a specific verb and resource. Distinguishes from siblings like 'live_get_scene' and 'live_export_selection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (pixels-only view) and when not to (pixels+scene or selection), with alternative tool names and an example.
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?
Describes working-copy model, that original is never mutated, edits are reversible, and risk class. Annotations already indicate readOnly and non-destructive, but description adds valuable behavioral context beyond annotations.
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?
Well-structured with clear sections (When to use, Key params, WORKING-COPY MODEL, Return shape, Example, Risk class). Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an output schema, the description covers all necessary context: working copy model, return shape details, example, and risk assessment. Complete for an entry-point tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no description for the path parameter, but the description provides extensive semantics: relative vs absolute paths, sandbox validation, rejection conditions, and alignment with sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool opens an SVG into a tracked workspace document, returns id and summary. Distinguishes from siblings like create_document, set_document_svg, reload_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (entry point for existing file) and when not to (alternatives provided). Lists sibling tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses reversible pipeline, no-op behavior, whole-set rejection on failure, snapshot creation, and risk class 'medium', adding significant context beyond minimal annotations.
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?
Well-structured with sections, but somewhat lengthy. Every sentence contributes value; minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity, output schema existence, and no sibling tool covers set optimization, the description provides all necessary input, behavior, output, and risk details for correct invocation.
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?
With 0% schema coverage, description compensates by explaining doc_ids constraints, and referencing precision/keep_ids from sibling tool. However, keep_ids purpose is not fully detailed, relying on agent's knowledge of svg_web_optimize.
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 verb 'Web-optimize' and the resource 'SET of documents', and contrasts with single-document and inspection tools, making it distinguishable from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (losslessly shrinking a multi-document system), and when to use alternatives (svg_web_optimize for single docs, quality_report_set for inspection). Also recommends post-use preview.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable context: no snapshot/Operation Record written, all-or-nothing rejection, and cross-doc consistency check. Does not contradict annotations.
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?
Well-structured with labeled sections (intro, when to use, key params, return shape, example, risk class). Every sentence serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameter constraints, return shape description, and risk class. Despite having an output schema, the description adds necessary context for the agent to understand the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds critical semantics: `doc_ids` must be non-empty and duplicate-free, and the entire set is rejected if any ID is invalid (no partial results).
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?
Description clearly states it quality-reports a SET of documents with per-doc reports, aggregate, and verdict. It distinguishes from siblings `quality_report` (single doc) and `optimize_set` (action vs audit).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section advises for auditing multi-doc systems and directly names alternatives: `quality_report` for single doc and `optimize_set` for stripping opportunities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which mark readOnlyHint false and destructiveHint false), the description discloses important behavioral traits: rejection if new parent is self/descendant, change in inherited coordinate space affecting visual position, and the recommendation to render a preview before trusting. These details add significant 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 well-structured and front-loaded with the core action. It uses separate paragraphs for usage, key params, return shape, and example. Every sentence adds value, though a slight tightening could be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema ('CreateResult'), the description appropriately covers return shape, key constraints, and risk. It also provides a concrete example and a safety warning. The tool is moderately complex, and the description fully equips an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden. It explains the meaning of `object_id` and `new_parent_id` ('both must exist') and gives an example, but does not explicitly describe `doc_id`. However, `doc_id` is a common document identifier and the context likely implies it. The description adds meaningful semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Move an object under a new parent'. It explicitly distinguishes from sibling tools 'group_objects' (wrapping several) and 'move_object' (repositioning without re-nesting), ensuring the agent selects the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section that sets precise context and names alternatives. It provides an example and a risk class ('medium'), giving the agent clear guidance on when this tool is appropriate and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=true), description adds critical details: security scrubbing (rejects scripts, handlers, external refs), requirement for non-empty approval_token, that original file is untouched, return shape, and advice to preview and restore if wrong. No contradiction with annotations.
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?
Well-structured with clear sections: purpose, when to use, key params, return shape, example, risk class. Front-loaded with core action. Slightly lengthy but every sentence adds value. Could be trimmed marginally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (destructive, idempotent, 3 params, output schema), description covers all needed context: purpose, alternatives, security constraints, required token, return shape, example, risk level, and preview advice. No gaps identified.
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 has 0% description coverage, so description must compensate. It explains svg must be <svg> root and lists security constraints, and clarifies approval_token must be non-empty for execution. Doc_id is not explained, but it's a common parameter. Overall adds significant meaning beyond schema for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action as REPLACE the whole working copy with an agent-composed SVG string, distinguishing it from sibling tools insert_svg_fragment (add) and create_document (blank start).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: adopting a full SVG composed in memory, replacing wholesale. Explicit alternatives: insert_svg_fragment for addition, create_document for blank start. Provides clear context and guidance.
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?
Description adds detail beyond annotations: explains failure behavior (first failing entry causes whole call to fail with stable message) and risk class (read-only, no mutation). Annotations already indicate read-only, so description enriches.
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?
Well-structured: purpose statement, usage section, key params, return shape, example, risk class. Every sentence adds value; no redundancy. Front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a stat tool: covers purpose, usage, parameter, return shape (output schema exists), and risk. No gaps given the tool complexity and existing structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'paths' is thoroughly described: non-empty list, resolution logic (same as stat_artifact), sandbox/symlink validation, size-cap, and failure behavior. Schema has 0% description coverage, so description compensates fully.
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?
Description clearly states the tool stats a SET of artifacts, listing per-file size, sha256, and aggregate byte total. It distinguishes from the sibling stat_artifact tool which handles a single file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section guides when to use this tool (verify a whole produced collection, readback of batch export) and when not (single file -> use stat_artifact). Clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), description adds risk class 'medium (reversible write-new on working copy; original untouched)', advises rendering before trusting, and mentions restore_snapshot as revert option. This provides valuable 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?
Well-structured with clear sections: purpose, when-to-use, parameter details, return shape, example, and risk note. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a gradient-adding tool: describes return shape (CreateResult with object_id and bbox=None), provides usage example, risk assessment, and verification steps. Output schema exists but description sufficiently explains output.
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?
With 0% schema description coverage, the description compensates by explaining stops parameter in detail (offset, color, opacity) and vector coordinates (x1,y1 to x2,y2) with defaults. Not every parameter is fully detailed (doc_id implied, object_id not mentioned), but the essential semantics are covered.
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 adds a <linearGradient> to the document <defs>, with a specific verb and resource. It distinguishes from sibling add_radial_gradient by explicitly contrasting usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (directional colour fade) and when not (centred/radial fade, recommending add_radial_gradient). Provides a usage example and mentions applying the gradient via set_fill, giving clear context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it describes atomicity, reversibility, two-phase validation (validate-then-apply), all-or-nothing rollback, risk classification (medium vs high based on delete_object), requirement for approval_token for high risk, and the snapshot mechanism for revert. Annotations only indicate destructiveHint: true; the description enriches this with detailed operational 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 well-structured and front-loaded with the core purpose, then usage guidance, parameter details, validation, risk, and return shape. However, it is relatively verbose; while every sentence adds value, a slightly more condensed presentation could be achieved without losing clarity. Still, it's highly effective and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch edits with many op types), the description is remarkably complete: it covers purpose, when to use, parameter semantics, validation behavior, risk levels, return shape (BatchEditResult with pipeline fields), and includes an example. The schema and annotations are supplemented well, and the description leaves no major gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for top-level parameters, so the description bears the full burden. It thoroughly explains the `edits` parameter: a non-empty ordered list (max 64) of typed edits, each with an `op` field, lists all supported ops, and provides examples. It also explains `approval_token` context (required for high risk). This adds extensive meaning beyond the schema's raw structure.
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: 'Apply an ordered list of typed DOM edits to a document as ONE atomic, reversible operation.' It distinguishes from siblings by specifying that for a single edit use the dedicated tool, and for path geometry or cross-document composition use those tools directly. This provides a specific verb+resource and differentiates 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'When to use' section: 'making SEVERAL edits to one document in a single call... instead of N separate tool round-trips.' It also states: 'For a single edit, call the dedicated tool... for path geometry or cross-document composition use those tools directly (they are NOT batchable).' This gives clear when-to-use and when-not-to-use guidance, referencing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show destructiveHint=true; description adds validation fails before mutation, single snapshot for reversal, risk class, and return shape. Discloses preview recommendation.
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?
Well-structured with sections, but slightly lengthy. Front-loaded with purpose. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, return shape, error handling, risk, and preview recommendation. Output schema exists, so return is explained. Complete for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description explains mapping validation (typod colors rejected with ToolError), scope_ids confinement, and provides example. Fully compensates.
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?
Clear verb+resource: 'Apply many colour replacements in a single reversible operation.' Distinguishes from siblings like replace_color, set_fill, set_stroke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 're-theming / rebranding a document's colours in one shot.' Provides alternatives: for single swap use replace_color; for specific objects use set_fill/set_stroke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond annotations: return shape (`CreateResult` with fields), reversibility via `restore_snapshot`, risk class medium, and warning to render before trusting. No contradictions with annotations.
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?
Well-structured: action, usage guidelines, key params, return shape, example, warning. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage, parameters, return shape, example, and risk. Output schema exists, so description focuses on key points, and example provides minimal but sufficient guidance.
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?
Adds meaning beyond schema: `parent_id` must exist, `object_id` is for pinning the id. Schema coverage is 0%, so description compensates well, though `doc_id` is not elaborated (but is obvious).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an empty `<g>` group inside a parent. It distinguishes from siblings by specifying when to use `group_objects` and `reparent_object` for wrapping existing objects or moving one object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (making an empty group to populate later) and when not to use (alternatives for wrapping or moving objects). Includes a risk class and advice to render before trusting, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds context: risk class 'medium (reversible write-new)', mentions rendering and revert options, and explains that the original is untouched. This goes well beyond the annotations.
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 well-structured but slightly verbose. It front-loads purpose and usage, then details parameters, return shape, example, and risk. However, the return shape explanation is somewhat redundant given the output schema exists, and there is minor repetition (e.g., 'render and look before you trust'). Still clear and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 5 required, 0% schema coverage, and the presence of an output schema, the description covers everything: purpose, usage, parameter details, return type with field explanations, example, risk classification, and post-usage actions. It is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains each parameter (x1, y1, x2, y2, doc_id, stroke, stroke_width, object_id, parent_id), notes that line is unfilled (no fill), and describes default behavior (unpainted, parent_id default). This adds critical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a line segment with specific endpoints (x1,y1 to x2,y2). It distinguishes from sibling tools like create_polyline (multi-segment open) and create_polygon (closed shape), fulfilling the need for specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'a single straight segment'. Provides direct alternatives: use create_polyline for multi-segment open runs and create_polygon for closed shapes. This gives clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds valuable behavioral context: it creates a new object, inserts into a parent, optionally paints, and notes the risk class as 'medium (reversible write-new).' It also advises rendering a preview before relying on the edit, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: first line states purpose, then usage guidance, key parameters, return shape, an example, and finally safety advice. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, output schema present), the description covers all essential aspects: purpose, usage context, parameter details, return format, concrete example, and risk mitigation. It feels fully complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage. The description compensates by explaining key parameters: points must be ≥1 (x,y) pairs, parent_id must exist or default to document, object_id pins the id, and fill/stroke/stroke_width are optional. However, doc_id is not explained beyond being required. Overall, it adds significant meaning over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Create an open <polyline> from points (≥ 1 (x, y) pairs).' It clearly names the resource and action, and differentiates from siblings by specifying when to use create_polygon, create_line, or create_path instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'a connected open run of segments.' It also gives specific alternatives for closed shapes, single segments, and curves, making it easy for the agent to choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations. It details the return shape (CreateResult with fields), the translate-scaling trap (x/y as translation before transform, warning not to mix with scaling transform), validation (only same-document #id, rejected external/javascript/url), and risk class (medium, reversible write-new). Annotations already indicate write and non-destructive, which is consistent.
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 well-structured, starting with purpose, then usage guidelines, key params with warnings, return shape, example, and safety advice. It is front-loaded with essential information. While it is relatively long, every sentence adds value, and the organization makes it easy to parse. A slight trim could improve conciseness, but it remains highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, complex SVG behavior, and an output schema, the description is exceptionally complete. It covers the placement trap, validation rules, return shape, and provides a concrete example. The advice to use render_preview and restore_snapshot further ensures safe usage. All aspects necessary for correct invocation are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description comprehensively explains key parameters: href_id must name existing element, parent_id must exist or default, x/y translation behavior, and transform usage with the scaling trap. It also notes default parent, object_id optional, and includes an example. This fully compensates for the lack of schema descriptions.
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 'Create a `<use href="#href_id">` referencing an existing same-document object' and distinguishes from siblings by specifying alternatives for deep-copy (duplicate_object) and grid-repeat (tile). The verb and resource are specific, and the tool's unique role in SVG instancing is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' context is provided: 'instancing / cloning an existing element so edits to the original propagate.' It also gives clear when-not-to-use examples: 'To deep-COPY (independent) use duplicate_object; to grid-repeat use tile.' Additionally, it advises to render and inspect before trusting, and mentions restore_snapshot for reversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: re-runs every call, refreshes cache, reports missing backends in notes without crashing, and clarifies risk class as low. This complements the readOnlyHint and destructiveHint annotations with actionable 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 well-structured: purpose sentence, usage guidelines, key params, return shape, example, and risk class. Every sentence is informative and concise, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (runtime probe with multiple outputs) and the presence of an output schema, the description fully explains the return shape (version, actions, formats, etc.) and side effects (cache refresh). It is complete for agent decision-making.
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?
With zero parameters and 100% schema coverage, the description adds minimal but helpful confirmation ('Key params: none'). This avoids ambiguity, though it does not add extensive new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it probes the local runtime and returns a capability matrix, using specific verbs ('probe') and noun ('capability matrix'). It distinguishes from siblings by explicitly naming alternatives: list_capabilities (cached) and check_live_support (live-transport detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use ('to FORCE a fresh probe') and gives alternatives ('for a cheap cached read use list_capabilities'). It also states key params are none, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only operation. Description adds extensive behavioral details: validation of object_id charset, sandbox checking for out_dir, inline PNG behavior gated by max_output_bytes, and return shape including stale flag.
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?
Well-organized with front-loaded purpose, clear paragraphs, and an example. Slightly verbose in explaining inline behavior but still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 8 parameters, explains return shape (ExportResult), mentions risk class, and gives usage context with sibling differentiation. Output schema exists, but description adds value for inline image handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully. It explains the role and constraints of object_id, format, out_dir, name_prefix, inline, and max_output_bytes, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export a single object (by id) to PNG, PDF, or SVG.' It distinguishes from siblings by naming 'export_document' and 'export_batch' as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: exporting one object, clipped to its own bbox' and provides when-not scenarios with specific sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds risk class (low, read-only guidance), explains it executes nothing, and details return shape (three possible outcomes). No contradictions with annotations.
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?
Well-structured with sections: purpose, usage, params, return shape, example, risk class. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameter and output schema, the description covers all needed context: return cases, exclusions, and references to design documents. Complements sibling tools well.
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?
With 0% schema coverage, the description compensates by explaining the 'goal' parameter as a natural-language description with examples. Provides clear semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps natural-language goals to inkscape-mcp tools, distinguishing it from siblings like list_capabilities and find_objects. Uses specific verb 'map' and resource 'natural-language goal to tools'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you know what you want in words but not which typed tool does it'), when not to use, and alternatives (list_capabilities, find_objects). Also references ADR-002/003 for design constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: hardening (safe-parse, strict allowlist), approval_token requirement, reversibility via restore_snapshot, original file untouched, return shape with validation. No annotation contradiction.
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?
Well-structured with sections for usage, parameters, return, example, and risk. Comprehensive but slightly lengthy; every sentence adds value so still highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameters, behavior, return value, examples, safety precautions. With output schema present, return shape is summarized appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains svg should be one element subtree, unwrap behavior with examples, parent_id requirement, approval_token necessity. Schema coverage is 0% so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Insert an agent-composed SVG fragment under a parent or document root.' Distinguishes from siblings by mentioning set_document_svg for replacement and create_* tools for single shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (grafting composed subtree), when not (use set_document_svg for replace, create_* for single shapes), and suggests using render_preview before trusting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's labeling as 'read-only manifest' is consistent and adds context. It also describes the return shape and provides an example, going beyond annotations.
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?
Description is efficiently structured with headings, uses only 5 sentences, and every sentence adds value—no fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description covers usage, return shape, example, and risk. Sibling tools are numerous but the description clearly differentiates. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It identifies the sole parameter `doc_id` and says 'none beyond doc_id,' which is accurate but does not elaborate on its type or constraints. However, given the single parameter and clear naming, this is sufficient for an agent.
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?
Description clearly states the verb+resource: 'List a document's snapshots in order, with metadata.' It also specifies the use case 'choosing which checkpoint to roll back to,' which distinguishes it from siblings like create_snapshot and restore_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('choosing which checkpoint to roll back to'), when not (use create_snapshot to make one, restore_snapshot to roll back), and includes a risk class note ('low (read-only manifest)').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds beyond annotations: 'ARTIFACT-ONLY — no mutation, no Operation Record routing, no approval, no network' and 'Risk class: low'. It explains frame resolution via operation_id, sandbox validation, and size mismatch error, providing full 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: main purpose, when to use, key params, and details. It is front-loaded and each sentence adds value. Slightly long but appropriate for the complexity; minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown), the description covers return shape: LiveDiffResult with overlay path, operation_id, changed_bbox, and highlighted_ids. Also explains link to diff_artifacts. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, operation_id, with 0% schema description coverage. The description adds meaning: 'Key params: `operation_id` names the Live Operation Record' and clarifies frames are resolved via operation_id, never a raw client path. This compensates for lack of schema description.
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 produces a focused, annotated before/after visual diff of a live operation. It specifies the resource (live operation diff) and action (visual diff), and distinguishes from siblings by noting when to use alternatives like live_apply_to_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: visualizing what one live mutation changed.' It also provides alternative tools for producing mutations and mentions that live_session_step calls this internally, giving clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: idempotent, safe with no session, return shape, risk class. No contradiction with annotations (readOnlyHint, destructiveHint are consistent with 'no document mutation').
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?
Very concise, well-structured with sections (description, when to use, key params, return shape, example, risk class). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple tool with no parameters and supportive annotations. Covers purpose, usage, behavior, example, and risk class. Output schema likely provides return details.
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?
No parameters; baseline 4 applies. Description correctly notes 'Key params: none,' but adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Disconnect the current live session (the X1 disable switch). Idempotent.' Identifies the specific resource and action, and distinguishes from siblings like live_connect and live_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use ('ending a live session (or as a hard kill switch)') and alternatives: 'To start one use live_connect; to check state use live_status.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), description adds 'read-only feedback (no mutation, no approval, no Operation Record),' 'Risk class: low,' and return shape. No contradictions with annotations.
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?
Description is concise (5 sentences) with front-loaded action, structured sections (When to use, Key params, Return shape, Example, Risk class). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description covers all necessary context: when to use, prerequisites, output shape, example, risk class, and differentiation from siblings. Complete.
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?
Input schema has zero parameters, and schema coverage is 100%. Description confirms 'Key params: none,' which meets the baseline of 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Export just the current live selection to a PNG under the live artifacts dir.' It distinguishes from sibling tools `live_render_view` (whole canvas) and `live_get_scene` (pixels+structure), making purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: a PNG of only the GUI selection' and provides alternatives for different needs. Also mentions prerequisite 'Requires an established session,' giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond annotations: svg_fragment is safely parsed (no entities, no external DTD, no network) and size-bounded. Clearly states 'high risk' and requirement for approval_token. No contradiction with annotations (readOnlyHint=false consistent with write operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: brief action statement, usage guidance, key params, risk info, return shape, and example. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (live insertion, high risk), the description covers purpose, usage, parameters, risk, return output (LiveEditResult with before/after renders), and an example. The output schema is referenced, providing complete context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates partially. It mentions key params (svg_fragment and approval_token) and adds safety context for svg_fragment. However, it does not fully describe each parameter's type or constraints beyond what schema provides. With only 2 params, the context is adequate but could be more precise.
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 'Insert an SVG fragment into the running document.' It uses a specific verb and resource, and distinguishes from siblings by noting alternatives for styling (live_apply_to_selection) and headless equivalent (insert_svg_fragment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: grafting composed markup into the live document.' Provides alternative tools for different use cases. Also states prerequisites: 'REQUIRES an explicit approval_token' and notes high risk, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. Description adds that it never raises exceptions and cleanly returns 'not connected' or 'none available', which is beyond annotation info.
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 efficient: first sentence states purpose, then usage guidelines, parameter note, return shape, example, and risk class. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately covers the return shape and usage context. It is complete for a simple read-only status tool.
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?
No parameters, schema coverage 100%. Description correctly notes 'Key params: none'. Baseline 4 is appropriate as no further parameter details needed.
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?
Description clearly states the tool reports live-session state with specific fields. It distinguishes from sibling 'check_live_support' by specifying that this tool covers overall state, not per-host details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'when to use: checking whether a session is live before issuing live tools' and provides a direct alternative ('For per-host transport detail use check_live_support').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: path validation, no overwrite, session requirement, subfolder creation, recording of operation and snapshot, risk class.
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?
Well-structured with purpose first, usage, params, behavior, return shape, example, risk. Slightly long but all information is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: prerequisites, constraints, behavior, return shape, risk class. Output schema mentioned so no need to detail return fields further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Highly detailed description of dest_path parameter including relative path behavior, sandbox constraints, and rejection conditions, compensating for zero schema description coverage.
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?
Clear verb 'save ... as a NEW tracked document', distinct from sibling tools live_render_view and save_document_as.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use and provides alternatives with specific differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deep-copy behavior, id re-minting, non-mutation of source, translation/scaling, snapshot/operation record creation, and risk class 'medium'. Annotations only provide basic hints; description adds critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when-to-use, key params, return shape, example, risk). Slightly verbose but every sentence adds value. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, and existence of output schema, the description covers all essential aspects: operation details, parameter constraints, return shape, example, risk, and verification guidance. Complete enough for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Explains the required mutual exclusivity of `source_doc_id` and `object_id`, the effect of `scale` and `(x, y)`, and provides annotated examples. Adds meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Place an existing document or object INTO another document at (x, y) with scale.' Distinguishes from siblings by naming `compose_grid`, `insert_svg_fragment`, `create_use`, and explaining when each is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 're-composing existing geometry cross-document without re-authoring or extracting SVG by hand.' Provides clear alternatives for other use cases, such as `compose_grid` for many assets and `insert_svg_fragment` for grafted markup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides detailed behavioural flow: pre-reload snapshot, re-resolving source, validation, rejection message. Discloses that create_document reloads from blank seed, and risk class (low, reversible, only working copy rewritten). Adds context beyond annotations.
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?
Well-organized with clear front-loaded purpose, usage, behavioral details, return shape, example, and risk. No superfluous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, parameter, return shape (output schema exists), example, and risk. Complete for the tool's complexity and single parameter.
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?
With schema coverage at 0%, description compensates by explaining doc_id must be open and is the only parameter. Could elaborate more on doc_id format or constraints, but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool refreshes a working copy from its source under the same doc_id, discarding edits. Distinguishes from siblings restore_snapshot and open_document by specifying different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (external edits changed source, want to resync in place), when not to use (for undo or opening different file), and names alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and destructiveHint=false. The description adds valuable context: risk class 'low' with rationale (render/export to artifact dir, no original overwrite), behavior on oversized requests (rejected before Inkscape runs), and that successive calls do not clobber (unique frame names). It also explains the inline image gating by max_output_bytes. Everything adds beyond the annotations.
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 well-structured with clear sections (purpose, when to use, key params, return shape, example, risk class). It front-loads the core purpose, then adds detail in a logical order. However, it is somewhat lengthy (8 sentences), and might be slightly more concise by merging the return shape description into the param section. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema exists), the description covers everything needed: purpose, usage boundaries, parameter details, return shape (referencing output schema), an example call, and risk assessment. The output schema is mentioned but not redundantly detailed, which is appropriate since the schema itself provides structure. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description bears full responsibility for parameter meaning. It covers all 5 parameters: width_px (scaling, omit for intrinsic), name (file tag, uniqueness), inline (boolean, default true, inline image behavior), max_output_bytes (gating threshold), and doc_id (implied required). Each parameter's effect and defaults are explained, providing complete semantics.
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 renders a PNG preview of the whole document to the artifacts directory. It distinguishes from sibling tools by explicitly naming alternatives (export_document, export_object, capture_frame), making the specific resource and action obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section that specifies the scenario (quick visual check) and provides explicit guidance on when to use alternative tools for final files, single objects, or ordered runs. This leaves no ambiguity about appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral details: `<tspan>` children are dropped, content collapses to single run, edit is on working copy only and reversible. Annotations already indicate `destructiveHint: true` and `readOnlyHint: false`, but description adds nuance about reversibility and risk level. No contradiction.
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?
Well-structured with sections for purpose, usage, params, return shape, example, and risk. However, some sentences are slightly verbose (e.g., 'Render and look before you trust this edit'). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, params, behavior (child handling), return shape, example, and risk. Output schema exists but description still explains `EditResult` fields. Complete for a medium-risk text editing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates by explaining `object_id` must be a text-bearing element and `text` has length and character restrictions. Also provides concrete example mapping parameters.
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?
Description clearly states it replaces text content of text-bearing elements like `<text>` and `<tspan>`, with specific examples. Distinguishes itself from siblings like `set_font` and `rename_object`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (changing what text says) and when not to (for font/size use `set_font`; for renaming use `rename_object`). Provides example and links to `find_objects` for obtaining IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses risk class ('medium') and mechanism ('reverts working copy via Operation Record; never touches the original'), adding context beyond annotations. Return shape details help caller verify recovery, compensating for the lack of output schema in the input.
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?
Well-structured with clear sections: purpose, usage, key params, return shape, example, risk class. Every sentence adds value with no redundancy. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params) and the presence of annotations (destructiveHint) and mention of output schema, the description fully covers what an agent needs: purpose, when to use, params, return shape, and risk. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries burden. It explains snapshot_id ('names the target checkpoint, must exist') and provides a full example. However, doc_id is not explicitly described, though it's clear from context. Still, the description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Revert a document's working copy to a chosen snapshot', clearly stating the verb (revert) and resource (working copy). This differentiates it from siblings like create_snapshot and list_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: undoing/rolling back to an earlier checkpoint' and provides sibling references for related actions (list_snapshots, create_snapshot), giving clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations, such as path resolution rules, sandbox checks, symlink handling, and overwrite requirements. It adds valuable context not captured in annotations.
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 well-structured with clear sections and every sentence adds value, but it is somewhat lengthy. Could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema present), the description is complete. It covers all key behaviors, edge cases (path escaping, symlinks), return shape, and risk class. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description fully compensates by explaining dest_path semantics (relative/absolute, subfolder creation, sandbox checks), overwrite requirement, and approval_token. This is crucial for correct usage.
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: 'Save a document's current working-copy state to a NEW file in the workspace.' It uses specific verbs and resources, and distinguishes itself from siblings like export_document and create_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use the tool ('persisting the working copy to disk') and when not to (use export_document for raster/PDF, create_snapshot for in-server state). Also notes that original and source files are never touched, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: scaling about parent origin, non-finite/non-positive factors rejected, edit lands on working copy (reversible), returns EditResult with details, risk class medium, and recommends rendering before trusting. Annotations only provide readOnlyHint=false, destructiveHint=false.
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 concise (~150 words), well-organized into sections: action, when to use, key params, return, example, risk. Every sentence adds value and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, output schema exists, and annotations provided, the description is complete. It covers usage, parameters, return shape, risk, and an example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. Explains sx as scale factor, sy defaults to sx for uniform, and constraints about origin and valid values. doc_id and object_id are mentioned but not elaborated, though they are standard identifiers.
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 scales an object/group by factor sx, with optional sy defaulting to sx for uniform scaling. It specifies the verb 'scale' and the resource 'object/group', and distinguishes from siblings like move_object, rotate_object, and resize_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: resizing one object, and that object_id comes from find_objects. Provides clear alternatives for repositioning (move_object), rotating (rotate_object), and resizing the whole page (resize_canvas).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), description explains the edit is reversible, lands on working copy, and risk class is medium. No contradiction with annotations; adds useful behavioral details.
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?
Well-structured with sections (When to use, Key params, Return shape, Example, etc.), front-loaded with purpose. Slightly lengthy but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage: input, behavior, output (EditResult described), safety guidelines, and risk. Given output schema exists, description is complete and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining opacity range [0,1], its effect on fill+stroke, and provides an example. Adds meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets element-level opacity of objects, distinguishing it from fill/stroke opacity. It uses specific verb+resource and differentiates from siblings set_fill and set_stroke, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (making whole objects transparent) and when to use alternatives (set_fill/set_stroke for fill/stroke-only opacity). Also advises to render and check before trusting, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false. The description adds significant context beyond annotations: path validation rules (workspace-relative/absolute, sandbox validation, rejection of escapes, symlinks), file existence/size limits, streaming sha256 computation, and low risk class. No contradictions.
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 well-structured with sections: main purpose, when to use, key params, return shape, example, risk class. Every sentence adds value, though it is slightly verbose for a simple read-only tool. Could be tightened slightly, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, read-only, one output), the description covers all relevant aspects: purpose, usage guidelines, parameter details, return shape, and risk assessment. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'path' with no description (0% coverage). The description compensates fully by explaining path semantics: workspace-relative (anchored to first root), absolute allowed, validation rules, and rejection conditions. Also provides an example. This is thorough for a single parameter.
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 returns 'on-disk byte size + sha256 digest of one sandboxed artifact', specifying the verb 'return', the resource 'sandboxed artifact', and the outputs. It distinguishes from sibling 'stat_artifacts' which handles a set, and mentions alternatives for image dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: to VERIFY what you wrote' and provides scenarios like verifying exports, renders, saved SVGs. Also states when not to use: for a whole set use 'stat_artifacts', for image pixel dimensions use other tool's result fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses key behaviors: reversible operation (one snapshot), deep copies with unique IDs, intra-clone reference rewriting, cell (0,0) stays as target, row/col and dx/dy constraints, risk class medium, and advice to preview first. No contradiction with annotations.
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?
Well-structured with sections: purpose, when to use, key params, return shape, example, risk note. Every sentence adds value, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 required params with 0% schema coverage, the description covers usage, behavior, constraints, return shape, example, and risk. Adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains rows, cols, dx, dy (grid spacing, constraints) and provides example. doc_id and object_id are not explicitly described but are standard parameters understood from context. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lay out a rows x cols grid of an object in ONE reversible operation.' It distinguishes from siblings like duplicate_object, move_object, scale_object, rotate_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section with clear alternatives: to move/scale/rotate one object use respective tools, to copy once use duplicate_object. Includes example and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavioral context beyond annotations: reversible via snapshot, dry_run default, risk class, approval_token for delete, and the atomic batch kernel. No contradictions with annotations.
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?
Well-structured with front-loaded purpose, when-to-use, key params, caution, return shape, example, and risk. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, nested objects, many siblings), the description covers all necessary aspects: purpose, usage, parameters, behavioral traits, return shape, example, risk, and reversibility. Output schema exists for return values, so further detail not 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?
Schema description coverage is low (17%), but the description provides rich semantic detail for selector (same as find_objects) and operation (oneOf each op with same params minus ids), plus explains dry_run, max_matches, and approval_token. This compensates well for the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies one typed operation to every object a selector matches, using specific verbs and nouns. It distinguishes itself from sibling tools like find_objects and apply_edits by describing the select-then-apply fan-out pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (bulk editing by predicate) and when not to (known id lists use dedicated tools or apply_edits). Also lists operations that are NOT accepted, and provides safety guidelines like dry_run and max_matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds rich behavioral context: return shape details, what findings are covered (missing fonts, glyph coverage, etc.), and risk class. No contradictions.
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?
Well-structured: purpose, usage, params, return shape, example, risk class. Each sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema is mentioned (ValidationReport) and description covers the output fields and checks performed. Given the tool's complexity, the description is sufficiently complete for an agent to understand behavior and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but only one param 'doc_id'. Description states 'Key params: none beyond doc_id' and provides example call, which clarifies usage. Could specify that doc_id refers to a loaded document ID.
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?
Description clearly states it validates a document and returns structured findings. It distinguishes from siblings 'quality_report' and 'svg_web_optimize' by specifying their 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'a pass/fail correctness check on a document.' Provides clear alternatives: 'quality_report' for metrics/optimize and 'svg_web_optimize' for size fixes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds significant context: probes extension-socket and DBus independently, safe regardless of live mode, and no session assumption. No contradictions.
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?
Well-structured with bullet points, front-loaded purpose, and every sentence adds value. Efficient use of words with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and output schema reference, the description is complete: covers usage, behavior, return shape, example, and risk class.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description explains that no params are needed, and adds value by describing the probe behavior and return shape.
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 reports which live transports are available, specifies it's read-only and no-connection, and distinguishes from siblings like live_connect, live_install_helper, and list_capabilities. It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('checking live readiness before live_connect') and lists alternatives ('live_install_helper', 'list_capabilities'). Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (write, not destructive), description adds risk class (medium, reversible write-new), warns to render before trusting, and notes that changes are reversible via restore_snapshot.
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?
Well-structured into sections (purpose, usage, params, return, example, caution, risk), each sentence adds value, no redundancy, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, all parameters, return shape, example, and risk; sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains points as at least one (x,y) pair, parent_id must exist or uses default, object_id to pin id, and fill/stroke/stroke_width validated like set_fill/set_stroke with defaults.
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?
Explicitly states creation of a closed `<polygon>` from points, and distinguishes from siblings by specifying that create_polyline is for open runs and create_path for curves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'When to use' section with explicit alternatives for open runs and curves, and mentions that parent_id must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses text constraints (length-bounded, no control chars except tab/newline/carriage return), parameter validation (fill/stroke like `set_fill`/`set_stroke`), return shape, and risk class medium (reversible write-new). No contradiction with annotations.
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?
Well-structured with labeled sections (When to use, Key params, Return shape, Example, Caution). Every sentence adds value without redundancy. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (4 required), output schema exists, and annotations present, the description covers all critical aspects: creation effect, parameter details, return format, example, and safe usage advice. Fully complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains key parameters: `text` constraints, `parent_id` default behavior, `fill`/`stroke`/`stroke_width` painting semantics, and `x`/`y` as anchor. Provides example using `fill` parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a `<text>` element at specific coordinates. It distinguishes from sibling tools like `replace_text` and `set_font`, providing precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (adding new label/caption) and when not (for existing text use `replace_text`, for font use `set_font`). Includes caution to render before trusting and mentions reversibility via `restore_snapshot`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: the clone re-ids every contained id, rewrites internal references, generates a validated safe new_id, and is reversible (lands on working copy only). Also gives risk class 'medium (reversible write-new)'. No contradiction with annotations.
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?
Well-structured with clear sections: main function, when to use, key params, return shape, example, and caution. Every sentence adds value without redundancy. Efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, parameters, return shape (EditResult with summary), example, and safety note. Despite having an output schema, the description adds context about what to expect (e.g., 'the new top id is reported in the summary'). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description compensates by explaining what each parameter does: 'the clone re-ids every contained id uniquely... an optional `new_id` (validated safe and unused) names the clone's top element; otherwise a suffixed id is generated.' Includes an example call.
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 uses a specific verb+resource: 'Duplicate an object or group in place, inserting the clone right after the original.' It distinguishes from siblings by naming alternatives (tile, create_use, rename_object) later in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use ('copying one object once') and when-not-to-use with clear alternatives: 'To copy into a grid use `tile`; to instance via `<use>` use `create_use`; to change an id without copying use `rename_object`.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes sandbox-checked directory, inline behavior, format-specific parameter handling, and return shape. Annotations only indicate readOnly hint; description adds crucial behavioral context beyond annotations.
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?
Well-organized with sections for purpose, usage, key params, return shape, example, and risk class. Every sentence is informative and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and output schema, the description covers return shape, inline image handling, parameter behavior, and risk class. It is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains key parameters (format, width_px, out_dir, name_prefix, inline, max_output_bytes) with constraints and behaviors, adding significant meaning.
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 'Export the whole document to PNG, PDF, or SVG,' specifying the verb, resource, and supported formats. It distinguishes from siblings like export_object, export_batch, and profile tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'producing a final file of the whole document' and lists alternatives for one object, batch, or bundle, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds details on matching (CSS cascade), return shape, risk class, accurate_bbox behavior, and limitations (objects without id never returned). No contradiction.
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?
Front-loaded with clear purpose, then usage, param details, return shape, example, risk. Every sentence adds value; well-organized and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a complex tool with 8 parameters and output schema. Covers all key aspects: when to use, parameter semantics, return format, edge cases (no-id objects, accurate_bbox fallback), and risk level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter in detail (tag, fill/stroke, text, id_prefix, bbox, accurate_bbox) with matching rules and default filters.
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 'Find addressable object ids in a tracked document by tag / paint / text / id-prefix / bbox', which is specific and distinguishes it from siblings like inspect_document and how_do_i.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: before an id-taking edit...' and mentions alternatives (inspect_document, how_do_i), providing clear guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the result is cached and probed once, which is beyond the annotations (readOnlyHint, destructiveHint). It explains return shape includes intents and tools sections, and states risk class as low. No contradiction with annotations; adds valuable context about caching.
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 highly concise with front-loaded purpose, then sections for usage, parameters, return shape, example, and risk class. Every sentence provides essential information without redundancy. Structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description covers all necessary aspects: what it returns (including details on intents and tools sections), an example call, risk class, and usage guidance. It is complete for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description explicitly says 'Key params: none' and explains why (cached call with no inputs). This adds meaning beyond the schema by confirming the parameterless nature.
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 returns the cached runtime capability matrix, and distinguishes it from siblings by specifying when to use diagnose_runtime and how_do_i. The verb 'Return' with the specific resource 'cached runtime capability matrix' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use ('cheap default for what can this host/server do'), when-not-to-use ('To FORCE a re-probe use diagnose_runtime; to map a single goal use how_do_i'), and notes there are no key parameters. This gives clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations by stating the high risk of mutating a user session, the requirement for an explicit approval_token, and that it's semantic-only with no arbitrary code. This adds critical context beyond the readOnlyHint=false annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating purpose, followed by usage guidance, parameter details, return shape, an example, and risk classification. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, high risk, mutation), the description covers all essential aspects: when to use, parameter constraints, return value (LiveEditResult with before/after renders), and risk class. The presence of an output schema is supplemented by description of the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter's semantics: color validation, CSS length for stroke_width, opacity range, transform constraints (dx/dy required together, positive scale, degrees for rotate), and the at-least-one-input requirement.
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 applies a validated style/transform to the current live selection. It distinguishes from siblings by naming alternatives like live_insert_svg and live_set_selected_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section guides the agent to use this for live style/transform editing and lists sibling tools for different tasks (insert, text, headless edits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses risk: 'high when it acts (routes through `run_live_mutation` — HIGH + approval); low when perceive-only (read-only).' It also explains the approval token requirement. Annotations already indicate destructiveHint=true, but the description adds valuable context beyond annotations.
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?
Well-structured with sections: purpose, usage, key params, return shape, example, risk class. Front-loaded with main purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage, parameters, return type (references output schema), example, risk, and design decisions (ADR references). Complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains key parameters: `action` enum, parameter dependencies per action, and the role of `approval_token`. It adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run ONE perceive→decide→act→observe iteration of the live-view loop.' It distinguishes from sibling tools by referencing standalone tools like `live_apply_to_selection`, `live_insert_svg`, and `live_set_selected_text`, and explains when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section explains the tool is for repeated loop steps, with `live_wait_for_change` between steps. It also notes when to use standalone tools instead. Clear and actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: length-bounded text, control-character rejection, no markup injection, high risk requiring approval token, and return shape as LiveEditResult with canvas renders. No contradiction with annotations.
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?
Concise, well-structured with sections for purpose, usage, key params, return shape, example, and risk class. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameters, risk, return (with output schema mentioned), and example. Complete for a mutation tool with high risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description fully compensates by explaining `text` constraints (length-bounded, no markup injection) and the `approval_token` requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Replace the selected text object's content in the running document,' using a specific verb and resource. Differentiates from siblings like `live_apply_to_selection` and `replace_text`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('changing the selected text object's words live'), provides alternatives for restyling and headless case, and notes high-risk nature requiring approval token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces annotations by declaring VIEW-ONLY, no Operation Record, no approval, and mentions server-side bounds checking. No contradiction with annotations.
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?
Well-structured with clear sections, no filler, each sentence adds value. Efficiently covers purpose, usage, params, example, risk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, description compensates fully. Includes return shape mention (LiveViewportResult). Usage and safety covered. Complete for this view-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description fully explains each mode's parameter requirements (zoom needs zoom/center, pan needs dx/dy, fit modes take no numerics), adding critical meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'control' and resource 'live canvas viewport', and explicitly distinguishes from siblings like live_render_view and live_apply_to_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' guidance and names alternatives for rendering and editing, making it clear when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal polling mechanism, parameter bounds (timeout_s clamped, poll_interval_s floored), cheap token nature, transport-agnostic property, socket limitation, and return shape details. Goes far beyond annotations.
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?
Well-structured: starts with purpose, then usage, then parameter behavior, then return shape, then example. Every sentence is informative and efficient; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: purpose, when-to-use, parameter constraints, internal behavior, return shape, example, risk class, and session requirement. Complete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds semantic meaning to both parameters: explains timeout_s is bounded to 60s, poll_interval_s is floored, and describes impact on polling behavior. With 0% schema coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool blocks until live state changes or timeout, read-only. Distinguishes itself by context between live_session_step and live_get_scene, and explicitly notes it is for reacting to user GUI edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (between live_session_step iterations) and what to use after (live_get_scene). Also notes session requirement and exclusion of code/raw-Action path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds context: 'the edit lands on the working copy only (reversible),' 'a translate(dx,dy) is prepended to the target's transform (child geometry untouched),' and a risk warning. It also advises to render and look before trusting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, usage guidelines, key parameters, return shape, example, and safety note. Every sentence is informative and no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description thoroughly covers the tool's behavior: return shape (EditResult details), reversibility, and the need for preview. It is complete for a move operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the key parameters: 'dx/dy are a delta in the parent coordinate space,' and includes an example call. It adds meaning to all four required parameters beyond the schema types.
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 action: 'Translate an object/group by (dx, dy) in its parent coordinate space.' It uses a specific verb ('translate') and resource ('object/group'), and distinguishes itself from sibling tools like scale_object, rotate_object, and tile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: 'repositioning one object; get its id from find_objects.' It also lists alternatives: 'To resize use scale_object, to spin use rotate_object, to lay out copies use tile.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description explains id validation, reference rewrites, working copy modification (reversible), and risk class. No contradictions; adds substantial 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 efficiently structured: one-line summary, bulleted usage, key params, return shape, example, and risk note. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no schema descriptions, but has output schema), the description covers purpose, parameters, return, examples, safety notes, and usage guidance. It is fully complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by naming `new_id` and `label`, stating at least one required, detailing validation for `new_id` and meaning of `label`. This adds crucial meaning missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes an object's `id` and/or `inkscape:label`. It distinguishes itself from `duplicate_object` and `svg_web_optimize`, making the purpose specific and differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (stable/human id or label), contrasts with alternatives (`duplicate_object` for copying, `keep_ids` in `svg_web_optimize`), and advises to render a preview before trusting. This fully satisfies the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), description adds color matching behavior (case- and hex-shorthand-insensitive, covers inline and presentation attributes), scope_ids validation, return shape EditResult, reversible nature, and preview recommendation. No contradiction with annotations.
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?
Well-structured: one-sentence purpose, usage guidance, key params with details, return shape, example, safety note. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a mutation tool with 4 params: explains parameters, behavior, return shape, side effects, and risk mitigation. No gaps given annotations and output schema (EditResult described).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, description explains scope_ids (confines to subtrees, ids must exist), from_color/to_color validation and matching semantics, and provides an example. Compensates fully for missing schema descriptions.
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?
Description clearly states 'Replace one colour with another' with explicit scope (document or scope_ids subtrees). Differentiates from siblings like apply_palette and set_fill/set_stroke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section with clear guidance on when to use this tool vs alternatives (apply_palette for multi-colour, set_fill/set_stroke for specific objects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description covers all behavioral traits: child geometry unchanged, viewBox preservation vs adjustment, bleed behavior with viewBox growth and background rect, mutual exclusivity of bleed and adjust_viewbox, and return shape with EditResult. Annotations provide readOnlyHint, destructiveHint, idempotentHint; description adds risk class and working copy edit details.
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?
Well-structured with clear sections, each sentence adds value. No filler. Includes purpose, usage, key params, return shape, example, and caution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage for a 6-parameter tool with 3 required, no nested objects, and output schema. Describes all parameters, edge cases, return value, and provides example. Agent has sufficient info to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully compensates. It explains each parameter in detail: width/height as validated CSS lengths, bleed opt-in with viewBox growth and color, adjust_viewbox default false, mutual exclusivity, and example usage.
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?
Description explicitly states 'Set the document canvas width/height to validated CSS lengths' and distinguishes from sibling tools like fit_to_content, normalize_viewbox, and scale_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'When to use' directive for changing PAGE size and explicitly lists when not to use with alternative tools. Also includes caution to render preview before trusting and notes reversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return shape (EditResult with operation_id, snapshot_id, changed, before/after preview), states the edit is reversible on the working copy, and includes risk class. Annotations are minimal (false flags), but description adds substantial behavioral context without contradiction.
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?
Well-structured with a clear opening sentence, then sections for usage, key params, return shape, example, and caution. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, output schema present, and the tool's medium complexity, the description covers purpose, parameters, usage alternatives, return details, risk, and post-edit verification steps. It is fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains degrees, cx/cy rotation behavior ('when BOTH given otherwise about origin'), and provides an example. It also links object_id to find_objects. All parameters are meaningfully described.
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 'Rotate an object/group by degrees about a point', using a specific verb and resource. It also distinguishes from siblings by explicitly mentioning when to use move_object or scale_object instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'When to use: spinning one object; get its id from find_objects.' It also gives alternatives and notes that rotation center behavior depends on cx/cy presence. Additionally advises to render and check before trusting, with revert option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, non-destructive), the description reveals the edit lands on a reversible working copy, advises rendering before trusting, and assigns a risk class, offering full 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 well-structured with front-loaded purpose, followed by usage, key parameters, return shape, example, and caution. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, output schema exists), the description covers usage, parameter details, return shape (EditResult fields), example, and risk advisory, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates thoroughly: it explains color format (hex, rgb, named, url references), rejection of unsafe inputs, opacity range [0,1], and provides an example clarifying object_ids usage.
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 sets the fill colour and optional opacity for one or more objects, distinguishing it from siblings like replace_color, apply_palette, and set_stroke by specifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (recolouring specific objects' fill) and when not (document-wide colour change or outline), providing specific alternative tools: replace_color, apply_palette, set_stroke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by explaining the edit is reversible, lands on the working copy, and includes risk class and detailed return shape with glyph coverage handling. No contradiction with annotations.
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?
Well-structured with sections: core purpose, use guidelines, key params, return shape, example, caution note, and risk class. Front-loaded with primary action; every sentence adds value; no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, output schema), the description covers all essential aspects: purpose, usage, parameters, return values (including edge cases like uncovered characters), example, and risk. Nothing is missing for an agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining key parameters: family, size, weight (at least one required), validation, and effect. It provides an example and clarifies the required fields (doc_id, object_ids) implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets font-family/font-size/font-weight on text objects, distinguishing from sibling tools like replace_text (for words) and set_fill/set_stroke (for non-font styling). The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'When to use: restyling text typography' and contrasts with alternatives: 'To change the words use replace_text; for non-font fill/stroke use set_fill / set_stroke.' This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. Description adds critical behavioral details: edit lands on working copy only (reversible), security constraints (rejection of external urls, javascript:, CSS-injection), and a 'Risk class: medium' tag. No contradictions.
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?
Well-structured with clear sections: main action, when to use, key params, return shape, example, rendering advice, risk. Every sentence is informative and earns its place. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema (EditResult), description focuses on usage and behavior. Covers parameter constraints, security, reversibility, and post-edit validation. Complete for a styling tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must carry full burden. It explains key params: 'at least one of color, width, opacity must be supplied', describes color as a colour or url(#id) reference, width as CSS length, opacity in [0,1], and security filtering. This adds substantial meaning beyond the schema types.
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 explicitly states 'Set the stroke colour, width, and/or opacity of one or more objects' with a specific verb and resource. It distinguishes from siblings by mentioning 'set_fill' for interior and 'stroke_to_path' for converting to outline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'When to use' section (styling outline/border) and clear alternatives: 'For the interior use set_fill; to turn a stroke into a filled outline path use stroke_to_path'. Also advises to render and inspect before trusting, and to use restore_snapshot for reversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description details the exact transformations: removal of editor metadata, unreferenced defs/ids, and coordinate rounding. It notes that re-running does nothing further, implying idempotency, and states the risk class as 'medium.' It also mentions the result is reversible via snapshots, which the annotations do not cover. This provides rich behavioral 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 well-structured and front-loaded with a one-line summary. Each section serves a purpose: when to use, key parameters, return shape, example, and safety advice. Every sentence earns its place without redundancy. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all necessary aspects: purpose, usage, parameters, behavior, idempotency, return shape, and risk. The output schema is referenced but not detailed, which is acceptable. The description is self-contained enough for an agent to select and invoke the tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: `precision` (rounding decimals 0-8, default 2), `keep_ids` (allowlist to preserve ids, unknown ids ignored), and `doc_id` (implied via example). It also clarifies the effect of re-running, which is crucial for idempotence. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Web-optimize an SVG: strip editor metadata, drop dead structure, reduce coordinate precision.' It distinguishes from siblings by explicitly mentioning alternatives: 'To inspect what WOULD be stripped first use `quality_report`; for lossy node reduction use `simplify_path`.' The verb 'optimize' combined with specific actions makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'losslessly shrinking an SVG for the web (direct-DOM, non-destructive).' It also provides clear alternatives and conditions: 'To inspect what WOULD be stripped first use `quality_report`; for lossy node reduction use `simplify_path`.' Additionally, it advises to 'render and look before you trust this edit' and mentions `restore_snapshot` for reversion, offering complete usage context.
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:

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

Score Badge

Copy to your README.md:

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

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/jjjsood/inkscape-mcp-server'

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