inkscape-mcp-server

by code-and-crypto

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
Disambiguation4/5
Most tools are cleanly separated by subsystem (paths, objects, SVG document, export, raw actions), and the prefix helps agents route. A few adjacent tools could be confused—object_clone vs object_compose's clone operation and svg_validate vs svg_analyze's quality checks—but the descriptions draw enough of a boundary.
Naming Consistency4/5
The set is uniformly lowercase snake_case with a domain prefix (object_, path_, svg_, export_, action_), which reads predictably. It is not a strict verb_noun pattern throughout—path_geometry, server_info, and path_effect are noun/adjective entries—so it falls just short of perfect consistency.
Tool Count3/5
At 23 tools the surface is in the heavy range for an MCP server, and an agent must digest a large catalog before acting. The breadth is defensible because Inkscape is a huge domain and each tool packages many underlying operations, but several aggregator tools could have been split or trimmed.
Completeness4/5
Core workflows—querying, editing, styling, path operations, document structure, optimization, export—are well covered, and action_run/extension_run provide escape hatches for the long tail of Inkscape actions. Obvious lifecycle gaps remain (no dedicated document load/save or object creation/deletion tool), but they can often be worked around through raw actions or existing file context.
Average 3.6/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists operations but does not explain side effects, whether operations are destructive, how input/output paths interact, or what happens when output_path is omitted. For a tool that can 'remove overlaps,' this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the main operations, but its brevity skims over important behavioral and usage details that the agent would need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and no output schema, the description leaves too much unsaid. Most critically, the valid values for kind are not explicitly enumerated, and the relationship between value, object_ids, select_all, input_path, and output_path is not clarified beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds some context for the kind parameter by implying the valid operation categories, but it does not enumerate exact values, and the schema's kind description punts to 'the tool summary' without fully delivering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear set of operations—align, distribute, remove overlaps, and raise/lower stacking order—tied to arranging objects. It is specific enough to convey the tool's general purpose, though it does not explicitly contrast it with siblings like object_transform or object_style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as object_transform or path_boolean. The description states what the tool can do but gives no context about when it is appropriate versus when a sibling would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it only lists capabilities. It does not explain side effects such as whether source objects are modified, whether output_path is required, how keep_source affects the operation, or whether trace bitmap rasterizes content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler words, and it packs a useful list of operations into a compact form. However, the dense comma-separated list could be better structured to group related variants, and it omits operational detail that the tool's complexity warrants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 10-parameter multi-variant tool with no annotations and no output schema, yet the description provides only an operation list. It does not explain which parameters apply to which variant, whether input_path/output_path are required for certain operations, or how the composition result is returned. The description is not sufficient for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The tool description adds a high-level catalog of variants but does not map specific parameter values of `kind` to operations or clarify how `value`, `target`, and `select_all` interact. It provides marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Compose objects') and enumerates the supported operations, including text on path, clipping, masking, grouping, and tracing. It conveys the tool's scope well, though it does not explicitly differentiate it from overlapping siblings like object_clone or path_boolean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations a user might perform, so usage context is loosely implied, but it gives no guidance on when to prefer object_compose over related tools such as object_clone, path_boolean, or path_effect. No alternatives, exclusions, or selection conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that operations include listing and applying preset filters, but it does not state whether applying modifies the input file, requires an output path, or has destructive side effects on existing objects. The description adds operational mode information but omits side-effect and workflow behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally compact and front-loaded, capturing scope, content categories, and operation modes in a single line. Every phrase earns its place; the capitalized '212 PRESET FILTERS' and 'whole Filters menu' immediately establish the resource. There is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has nine parameters, three operation modes, nested objects, and no output schema, so a minimal one-line description is insufficient for correct invocation. The description does not explain how operations map to input_path, output_path, object_ids, select_all, or tweaks, nor what the return value looks like for list versus apply. An agent would need external examples or additional context to call this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by enumerating valid operation values and listing filter categories, which the operation parameter's schema description defers to. However, it does not clarify which parameters are needed for which operation, nor how tweaks, object_ids, select_all, or output_path interact, leaving much of the parameter semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Inkscape's 212 preset filters, covering the entire Filters menu with concrete categories like bevels, metal, glass, shadows, and glows. It also lists the operation modes (list, menus, apply), which anchors the tool's function. However, it does not explicitly contrast with similar sibling tools like extension_run or object_style, so the differentiation is mostly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operation values (list, menus, apply) but gives no guidance on when to choose this tool over alternatives such as extension_run, path_effect, or object_style. There are no explicit when-to-use or when-not-to-use instructions, and no workflow hints for selecting among the three operations. This leaves the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, this carries the full burden. It lists operations but never discloses side effects (file overwrites, in-place mutation, idempotency, destructive nature of fracture/break-apart), nor whether selection filters apply to all variants. The only safety hint, output_path overwrite behavior, is in the schema, not the description.
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?
Single compact sentence with a scannable list, and the 'Set with kind' instruction is appropriately terse. The long comma-separated list is readable though not structured with line breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 6-parameter, multi-variant tool with no output schema and no annotations. The description fails to explain the role of value, the relationship among object_ids/select_all and operation kinds, and the input/output file flow. It provides the variant list but leaves operational semantics largely to schema field descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description partially compensates by listing the variant names, but it does not specify exact kind string format (e.g., 'object-to-path' vs 'object_to_path') or which variants require the value parameter. Since there are no enums, ambiguous mapping reduces the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Convert') and resource ('paths and shapes'), and enumerates a dozen specific operations, distinguishing it from siblings like path_boolean and path_geometry. The phrase 'Set with kind' signals the parameterized nature. Could be improved by explicitly naming the sibling it is not, but the operation list is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to choose this over path_boolean, path_geometry, object_transform, or object_compose. The description neither states exclusivity nor conditions such as 'for boolean ops use path_boolean.' Relies on the operation list alone to imply coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does reveal that clones are true <use> links and that a duplicate operation exists, but it omits the file-based input/output workflow, side effects on output files, and behavior when keep_source is used. For an unannotated tool with mutation potential, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense sentence with no filler, and the core behavior is front-loaded. It earns its place by conveying the key distinction from Inkscape actions in very few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter, file-writing tool with no annotations and no output schema, so the description must compensate heavily. It does not explain the input/output file flow, the exact operation values, or what happens with keep_source, and it leaves an agent to infer essential call semantics from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already explains the parameters. The description adds modest context by indicating what the operation parameter likely offers—tiled cloning and duplicating—but it does not provide exact valid values or explain how geometric params combine to shape the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's core operations—creating tiled clones as real <use> links and duplicating objects—and notes that these are not available as Inkscape actions, which helps set expectations. It is not a tautology, though it is telegraphic and does not explicitly contrast with sibling object tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Neither exists as an Inkscape action at all' implies this tool exists to fill gaps where action_run/action_find would not help, but it never names alternatives or states when to choose object_clone over sibling tools such as object_transform or object_arrange. Usage guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It usefully explains that the quality operation runs 11 weighted checks and explains every deduction with a fixing tool call, which is valuable behavioral detail. However, it does not state whether the tool is read-only, what output shape it returns, or any side effects, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose and operation list immediately, then adds the most important behavioral detail about the quality operation. The only minor issue is the sentence fragment 'Document analysis.' but overall there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five operations and no output schema, yet the description does not explain what each operation returns, what the default operation is, or whether input_path is effectively required despite being listed as optional. This leaves an agent without enough information to reliably invoke the tool and interpret its results across all modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds real value by specifying the valid operation values that the schema only refers to via 'See the tool summary for valid values.' It also clarifies what the quality operation does with its 11 weighted checks, giving the agent useful parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Document analysis' and enumerates concrete operations (statistics, structure, dimensions, quality, full), which makes its purpose reasonably clear. It does not explicitly contrast itself with sibling tools like svg_validate or svg_optimize, but the analysis-focused terminology is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the available operations but gives no guidance on when to choose this tool over sibling tools such as svg_validate or svg_optimize, nor when to prefer one operation over another. There is no mention of prerequisites, default behavior, or cases where an alternative should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral burden. It does disclose that animation is applied to existing objects by id and lists supported operation categories, presets, easing curves, and motion paths. However, it does not mention side effects such as file overwriting, whether the source file is mutated, or how existing animations are replaced.
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 three short sentences with the core behavior front-loaded and no filler. The final sentence about Inkscape's lack of animation support earns its place as differentiation context, though the operation list could have been formatted more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 22-parameter tool with no required parameters, no output schema, and no annotations, the description is not complete enough. It does not explain which parameters apply to which operation, how object_ids and input/output paths interact, or what the tool returns or writes. Schema-level parameter descriptions help, but operation-level workflow guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description can rely on the schema for per-parameter meaning. It adds value by supplying the operation enum values that the schema omits, and by stating capability constraints like 12 presets, 7 easing curves, and motion along any path in the document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific function: applying SMIL/CSS animation to existing document objects by id, and lists the operation modes. It distinguishes itself from sibling transform/style tools by noting that Inkscape has no animation action of any kind, though the individual operations remain under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The phrase 'objects ALREADY IN THE DOCUMENT' implies a constraint, and the note that Inkscape has no animation action gives context, but it does not tell the agent when to prefer object_transform for transforms or object_style for color work, nor does it explain which operation fits which task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does add some useful context with 'Real geometry, headless' — indicating true geometric changes rather than style-level effects. However, it omits side-effect information such as whether the input file is preserved, whether operations are reversible, and what happens on failure.
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 exceptionally short and front-loaded, with no filler words. Both sentences earn their place: the first states the operation set and the second adds the key behavioral qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter semantics and selection precedence, but the description does not provide the valid values for 'kind' despite the schema telling the agent to see the tool summary. Without an output schema or annotations, the agent must infer usage details from the sentence alone, leaving meaningful gaps for a tool with six parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter such as object_ids, select_all, and output_path. The description's verb list loosely suggests possible 'kind' values but does not enumerate them or clarify the ambiguous 'value' parameter, so it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names concrete geometric operations ('Move, scale, rotate, grow and flip objects') applied to a clear resource ('objects'), so an agent can tell this is a transform tool. It does not explicitly contrast with siblings like object_arrange or path_geometry, and 'grow' is imprecise, but it is far from tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings such as object_style, object_clone, object_arrange, or path_geometry. The phrase 'headless' hints at scripted use, but there are no explicit conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, but it does not disclose side effects, file overwriting behavior, object creation, or the result/return behavior of applying a path effect. The only behavioral signal is the terse 'operation: list | apply,' which is too thin for a mutation-capable tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key distinguishing information: the eight supported effects. The grammar is telegraphic and the final 'operation: list | apply' line could be more integrated, but every sentence earns its place without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested objects, no output schema, and no annotations, this description is not complete enough to invoke correctly. It omits how input_path, output_path, and object_id relate, what list returns, whether apply mutates in place or creates a new object, and how params should be structured for each effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real value by enumerating the allowed effect values and operation values (list | apply) that the open-ended schema fields do not provide. It also indicates that params and defaults come from Inkscape's lpe-*.cpp source, helping an agent understand where parameter semantics originate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource—live path effects—and enumerates the exact supported set (sketch, rough_hatches, spiro, etc.), while exposing the two operations list and apply. It partially differentiates from siblings by claiming these effects have no other headless route, though it does not state in full-sentence form what the tool does to an SVG object or file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'no other headless route' provides clear context that this tool exists specifically for these eight effects, which helps an agent choose it over object_transform or path_boolean. However, it gives no guidance on when to use list versus apply, nor how operation choices interact with object_id, input_path, and output_path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure and does add useful detail: it checks scope first and reports failures as window-scoped, a dead registry entry, or a typo. However, it does not disclose potential side effects of running arbitrary action chains or what a successful run returns, which is a meaningful gap for such a powerful tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core purpose front-loaded and the failure-diagnosis detail compactly included in the second. There is no filler, redundancy, or unnecessary structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented and the description provides valuable failure diagnostics, but there is no output schema and no statement about return values or destructive side effects. For a tool that can run arbitrary action chains, a note about what happens on success or about file mutation would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds some context by explaining the scope check that relates to `ignore_scope` and the failure categories, but it does not add significant parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run any raw Inkscape action chain.' This clearly positions it as the generic action-execution tool among more specialized siblings. It does not explicitly contrast itself with `action_find` or the higher-level helpers, so it falls just short of the top tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'any raw Inkscape action chain' implies it should be used when a raw action is needed, but the description does not explicitly say when to prefer it over dedicated tools or when not to use it. There is no mention of alternatives, leaving the agent to infer the selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a genuine context fact (this is the 'only headless route' vs window-scoped layer actions) but reveals nothing about per-operation side effects, whether operations mutate the input file or require output_path, reversibility of node-level edits and canvas resizing, or what the tool returns. For a mutation-capable tool covering operations like 'resize' and 'set-viewbox', this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, dense with information, with the core scope front-loaded ('Document structure. area: ...') and each sentence earning its place: scope, domain enumeration with operation examples, and the key routing fact about headless vs window-scoped actions. No filler or repetition beyond an acceptable restatement of scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 28 parameters, 6 sub-areas, no annotations, and no output schema, the description is a solid overview but not complete enough for reliable invocation. It does not map operations to their required parameters (e.g., resize needs width/height, set-viewbox needs coordinates), does not enumerate the full operation set, and gives no hint about return values even though the tool performs 'font enumeration' and 'canvas geometry (info)' queries that presumably return data. An agent would still need significant trial and error to call this 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 description coverage is 100%, so the baseline is 3. The description adds real value on top: it enumerates the valid values for 'area' (layers | gradient | pages | nodes | fonts | canvas) that the schema leaves open, lists example operations for 'operation' (info, fit-to-drawing, resize, set-viewbox, set-units), and clarifies gradient types (linear/radial/MESH). It still fails to enumerate the 24 layer-* operation values referenced by the operation parameter, so it does not fully compensate for the schema's open-ended operation field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear resource domain ('Document structure') and enumerates the specific sub-areas and operations it covers: 'area: layers | gradient | pages | nodes | fonts | canvas', plus concrete canvas operations like 'fit-to-drawing', 'resize', 'set-viewbox', and 'set-units'. It distinguishes itself from the object_*, path_*, and export_* sibling groups by scope, and the 'only headless route' note differentiates it from Inkscape's action layer-*. It is a broad multi-operation dispatcher rather than a single verb+resource, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing context: 'Inkscape's 24 layer-* actions are all window-scoped, so this is the only headless route.' This tells an agent exactly when to reach for this tool for layer operations in a headless context. It does not, however, name sibling tools (object_transform, path_boolean, etc.) as explicit alternatives, so the boundary with object- and path-level tools is left implied rather than stated.
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?
No annotations are provided, so the description carries the burden, and it does substantial work by disclosing a non-obvious failure mode: Inkscape exits 0 on an empty export, so this tool verifies the output exists and is non-empty. It does not explicitly restate the overwrite behavior of output_path, but that is already documented in the schema, and the verification detail adds real value beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler: the first front-loads the formats and key controls, the second adds the critical verification behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the headline formats and a key failure mode, which is useful for a tool with 19 optional parameters. However, it leaves important context implicit: how the export format is selected (presumably by output_path extension) and what the default export scope is when no area/id/margin options are provided. With no output schema and no annotations, a bit more orientation would make this fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description groups parameters into meaningful categories (dpi, size, margin, area, background, text-to-path, compression) which aids orientation, but it does not add semantic details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Export') and the target resource formats ('PNG, SVG, PDF, PS or EPS'), and it gives a concrete sense of the tool's capability with 'full control' and its option list. It does not explicitly differentiate from sibling tools like export_batch or export_preview, so the distinction is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus export_batch or export_preview, nor any exclusion criteria. The phrase 'with full control' hints that this is the more configurable single-file export path, but the agent is left to infer the routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose a valuable non-obvious behavior: paint detection reads style= attributes, presentation attributes, and inherited paint, preventing false empty reports for Inkscape-authored files. However, it does not mention return format, side effects, permissions, or what happens on validation failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the core purpose and operation list are front-loaded, followed by a single high-value behavioral note about paint detection. Every clause earns its place, and the structure makes the operation vocabulary immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the operation list is useful, the agent cannot determine which parameters are required for each operation—for example, whether validate needs input_path, whether size_limits needs max_dimension/max_file_size_mb, or whether audit_web needs a pattern. With no annotations and no output schema, the missing operation-to-parameter mapping and undefined return behavior are significant gaps 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?
Schema description coverage is 100%, and the description adds the allowed operation values that the schema defers to ('See the tool summary for valid values'). It also clarifies that audit_pack operates on a whole directory. The remaining parameters are already described well in the schema, so the description appropriately supplements without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'SVG quality assurance' and then lists six concrete operations (validate, viewbox, stroke_fill, size_limits, audit_web, audit_pack), making it clear this is a multi-mode validation/audit tool. It does not explicitly contrast with svg_analyze, but the QA framing and operation names distinguish it from editing, animation, and export siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through terms like 'quality assurance', 'audit_web', and 'audit_pack (a whole directory)', so an agent can infer this is for validating or auditing SVG files. However, it never states when to prefer this tool over svg_analyze or svg_optimize, nor does it list exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates the operation sets values, but does not disclose side effects, file modification behavior, selection resolution semantics, or what happens with output_path. This is thin for a mutation-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences: the first states the action and scope, the second adds a uniqueness claim. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, this description is too sparse. It does not clarify how kind maps to the two variants in practice, which parameters are needed for a valid call, or what the tool returns or modifies beyond setting a 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 100%, so the baseline is 3. The description adds value by revealing the valid kind values (object-set-attribute / object-set-property) and by clarifying the scope as XML attributes and CSS properties, which enriches the otherwise terse 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 a specific action (Set) and resource (XML attribute or CSS property) on a selection, and identifies the underlying variants (object-set-attribute / object-set-property). It distinguishes this generic setter from the more specialized sibling tools like object_transform and object_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for arbitrary attribute/property setting and claims uniqueness across Inkscape MCP servers, but it does not explicitly state when to prefer it over siblings or when not to use it. Context is clear enough for a generic setter, but explicit alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context: semantics are read from Inkscape's own source so results match the GUI. However, it does not disclose side effects such as output_path overwrite behavior, whether the source object is modified, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. The core purpose and the key differentiator ('Semantics read from Inkscape's own source so results match the GUI') are front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no required parameters, no annotations), the description is lean. It does not explain which parameters apply to which variant or what the output artifact is. The complete schema descriptions compensate partially, but an agent still lacks enough operational context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema individually documents all 15 parameters. The description adds minimal parameter-level value beyond listing valid kind variants in the summary, which is useful but does not explain parameter combinations or required fields per variant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation type ('path geometry') and lists concrete variants: offset/inset, fillet, chamfer, powerstroke, taper, mirror, and radial-repeat. It clearly identifies what the tool does, though it does not explicitly contrast itself with sibling tools like path_boolean or path_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Inkscape's one real headless gap' provides context that this tool fills a specific void in headless Inkscape, and the listed variants make its intended use clear. It does not give explicit when-not-to-use guidance or name alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that this uses Inkscape's --query-all and returns real bounding boxes, implying a read-only query. However, it does not clarify output structure, whether object_ids changes the 'every object' scope, or how force_full behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core purpose, implementation detail, and suggested usage without redundancy. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough to understand the tool's role, and the schema covers parameters. However, with no output schema, the tool does not describe what the returned bounding-box data looks like or how output relates to object_ids, leaving a meaningful gap for an agent deciding whether this tool returns what it needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-specific detail beyond what the schema states, which meets the baseline but does not compensate for any ambiguity around scope.
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 names a specific verb and resource: querying real bounding boxes for every object via Inkscape's --query-all. It also states the practical purpose of discovering object ids before acting on them, which clearly distinguishes it from the object_* mutation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this to discover object ids before acting on objects. It does not explicitly name alternatives or exclusion cases, but the 'before acting on them' guidance makes the intended workflow obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains what each operation does and adds a useful behavior: per-item success reporting so one bad layer does not hide the rest. It does not cover overwrite behavior or return details, but the core write behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with 'Batch export,' and every sentence adds distinct value: scope, operation details, and error-reporting behavior. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains operations and success reporting, and parameter schemas are complete, but it never clarifies which parameters are required for each operation, how dpi and dpis relate, or what the return/report format looks like. Given no output schema and no annotations, this is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds meaningful semantics for the operation parameter by listing the valid values and their effects, which the schema itself defers to the tool summary.
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 names the tool's function ('Batch export') and specifies the two operation modes with concrete behavior, which also helps distinguish it from the single-file siblings like export_file and export_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of batch export is clear and operation descriptions imply usage, but the description never explicitly tells the agent when to choose this tool over export_file or export_preview, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does explain that this runs .inx scripts properly and supports list/describe/run operations, which is useful. However, it does not disclose potential side effects of running extensions, such as file mutation or non-deterministic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences deliver purpose, example scope, operation values, and a crucial warning—all without waste. The most important constraint (headless extension execution) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a 5-parameter tool with full schema coverage, but there is no output schema and the description does not say what list/describe/run return. Since the tool can execute arbitrary bundled scripts, a bit more context about side effects or output behavior would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful value by specifying the valid operation values (list | describe | run), which the schema only vaguely references as 'See the tool summary for valid values.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (run), a specific resource (157 bundled Inkscape extensions), and a headless execution context. It also differentiates itself from Inkscape actions, which is especially relevant given the sibling tool action_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for extensions, not for regular Inkscape actions, because calling them as actions silently does nothing. It could name alternatives explicitly, but the warning provides enough directional guidance to steer correct 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?
With no annotations, the description carries the behavioral disclosure burden. It adds the non-obvious trait that the tool returns the rendered image, and explains why that matters (making blank output visible). It doesn't mention the file-write side effect, but the schema already covers output_path overwriting, so this goes beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core behavior is front-loaded, and the second sentence provides a concise rationale without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers what it does, what it returns, and why to use it. It could more explicitly route to export_file for file-only use cases, but the essential information an agent needs to call and interpret the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so dpi, input_path, and output_path are already documented with adequate descriptions. The tool description doesn't add per-parameter semantics, but it frames the overall operation as rendering to PNG, which is consistent with the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Render to PNG and RETURN THE IMAGE'. The emphasis on returning the image clearly differentiates it from sibling export tools like export_file and export_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: when the model needs to visually verify its own work, using the blank-canvas example as a concrete rationale. It does not explicitly name alternatives or exclusions, but the usage context is strong enough for selection among the export siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does so well: it explains automatic object-to-path insertion, warns that booleans silently no-op on rect/circle without it, and reveals Inkscape's two-object limitation that motivates chaining. It does not discuss other possible side effects such as how layers, styles, or malformed inputs are handled, which keeps it from a 5.
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 compact and front-loaded with purpose and options. The phrase about using the correct path-* action names is slightly implementation-oriented, but it is not redundant with the schema and supports behavioral transparency. Overall it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential behavioral facts: operation values, no-op risk on basic shapes, and multi-object chaining. The input schema covers parameter syntax and overwrite behavior. It is complete enough for an agent to invoke it correctly, though it does not spell out error handling or the exact output format.
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?
Although all parameters are already described in the schema, the description adds crucial meaning to the `operation` parameter by listing the valid values, which the schema's description only refers to indirectly. It also clarifies how object_ids are interpreted for non-path shapes through the object-to-path insertion note. This exceeds the baseline 3 for full schema 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?
The description opens with 'Boolean path ops' and enumerates the exact operations (union, difference, intersection, exclusion, division, cut), giving a specific verb, resource, and operation set. This clearly distinguishes the tool from siblings like path_geometry or path_convert. It also mentions the underlying path-* action names, which further anchors what the tool invokes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: use this tool for boolean combinations of paths, with explicit operation names. It adds practical guidance about auto-inserting object-to-path and pairwise chaining for more than two objects. It does not explicitly name alternatives or exclusion conditions, so it falls just short of full when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful behavior beyond the schema: the registry source is the Inkscape source, the total action count is 348, and window-scoped actions cannot run headlessly. It could mention pagination or limit defaults, but the disclosed scope caveat is genuinely valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action and resource appear first, followed by the key differentiator (headless compatibility) and supporting statistics. Every sentence adds information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter search tool with no output schema, the description is nearly complete: it names the resource, the searchable fields, and the crucial operational constraint about window-scoped actions. It doesn't explicitly describe the output format or pagination behavior, but the core calling context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining what 'scope' means (app = headless, win = GUI only) and implicitly that query searches across name, scope, source file, and parameter type. This goes beyond the schema's terse field descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search'), a precise resource ('action registry extracted from the Inkscape source'), and the fields returned (name, scope, source file, parameter type). This clearly distinguishes it from action_run and other sibling tools: it is the lookup/discovery tool, not an execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical context: it searches a known registry of 348 actions and warns that 130 window-scoped actions can never work headlessly. It doesn't explicitly say 'use this before action_run' or list exclusions, but the context strongly implies the appropriate usage without needing deep inference.
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?
No annotations are present, so the description carries the behavioral burden. It discloses that selftest 'round-trips a real document through both Inkscape and the pure-Python path,' revealing a meaningful dependency and behavior beyond the raw operation names. It implies a non-mutating health check, though it never explicitly states 'read-only' or describes potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences plus a short value list, all front-loaded with the core purpose. There is no filler, repetition, or unnecessary detail; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-light diagnostic tool with no output schema, the description covers what operations exist, the notable selftest behavior, and when to run the tool. It does not detail the return format of each operation, but the self-descriptive operation names and health-check framing make the tool usable without that.
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 already documents both parameters with 100% coverage, but the description adds the valid operation values, which the schema refers back to the tool summary for. It also clarifies the selftest's Inkscape/pure-Python round-trip, which helps the agent understand what require_inkscape controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Server health and self-check' and enumerates specific operations (status, version, config, diagnostics, selftest, help), making the tool's purpose concrete and distinct from sibling object/document/export tools. An agent can immediately tell this is a diagnostic server tool, not a transformation or export tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Run this FIRST when anything behaves oddly.' It does not enumerate exclusions or alternatives, but no sibling tool is a server-diagnostic tool, so the context is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden: it states the destructive transformations (prune, strip, drop, remove, minify) and adds that the tool reports bytes saved. It does not mention permissions or failure modes, but the schema's output_path note covers overwrites and the transformation list is explicit.
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 tight: the first sentence front-loads the operation list and the second explains the implementation choice plus the output summary. The 'VERIFIED' and 'REAL' emphasis is slightly colorful but conveys reliability context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema and no annotations, the description provides a solid conceptual model and mentions the key output behavior of reporting bytes saved. It could state defaults or required input/output paths more explicitly, but the schema already documents each parameter and the description covers the high-level behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds value by mapping its listed operations to the parameter families (minify, precision, strip_metadata, drop_empty_groups, strip_default_style, prune_defs). It does not describe every parameter such as keep_ids and strip_unused_ids, which remain schema-only, so it does not earn a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation (optimize) on a specific resource (SVG) and enumerates concrete transformations: pruning unreferenced defs, stripping metadata, dropping empty groups, rounding coordinates, removing default style, and minifying. This scope makes it easy to distinguish from sibling tools like svg_analyze and svg_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by explaining why the tool exists (reliable headless SVG optimization) and explicitly warns against Inkscape's vacuum-defs as a verified silent no-op with window-scoped cleanup. It does not name sibling alternatives or state an explicit 'use when...' rule, so it falls just short of perfect usage routing.
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/code-and-crypto/inkscape-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/code-and-crypto/inkscape-mcp-server)

Score Badge

Copy to your README.md:

[![inkscape-mcp-server MCP server](https://glama.ai/mcp/servers/code-and-crypto/inkscape-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/code-and-crypto/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/code-and-crypto/inkscape-mcp-server'

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