inksmcp

Overview Schema Source Related Servers Discussions Admin

run_actions

Run raw Inkscape actions on selected object IDs, e.g., object-align or transform-rotate. File, export, window, and quit actions are blocked.

Instructions

Escape hatch: run raw Inkscape actions (e.g. "object-align:left last", "transform-rotate:30") after selecting select ids. File, export, window and quit actions are blocked. Extensions (org.inkscape.*) always act on the whole document, so they can't be combined with select.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "actions": "<actions>"
    },
    "name": "run_actions"
  }
}

Input Schema

Name	Required	Description	Default
`doc_id`	No
`select`	No
`actions`	Yes
`preview`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does add real behavioral value: it discloses that file/export/window/quit actions are blocked and that org.inkscape.* extensions act on the whole document. However, it says nothing about the `preview` flag's effect, error behavior, or what a run returns, which is a notable gap for a mutation tool.

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

Conciseness4/5

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

Three dense sentences, front-loaded with the defining "Escape hatch" label, then prerequisite, restrictions, and a caveat. Almost every clause earns its place; only the trailing extension caveat is arguably a second-order detail.

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

Completeness3/5

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

For a 4-param, no-annotation, no-output-schema tool, the description covers purpose, prerequisites, and action restrictions well, but omits the meaning/effect of `preview` and `doc_id` and offers no sense of the result. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It gives meaningful semantics for two of four params: `actions` (raw Inkscape action syntax, with examples) and `select` (ids must be selected before actions run). It leaves `doc_id` and `preview` completely unexplained, so the compensation is only partial.

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+resource ("run raw Inkscape actions") and frames it distinctively as an escape hatch with two concrete examples ("object-align:left last", "transform-rotate:30"). The example action names overlap with siblings like align/path_operation, but the "raw actions" framing makes the distinction clear without opening a schema.

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 "escape hatch" framing tells the agent this is the fallback when dedicated tools don't cover a need, and it specifies the prerequisite "after selecting `select` ids". It also states when NOT to combine actions with select for extensions. It stops short of naming which sibling tool to prefer, so no explicit routing like the top-tier example.

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