inksmcp

Overview Schema Source Related Servers Discussions Admin

document_create

Create a new blank SVG document with defined width, height, and unit, make it current, and optionally add a full-page background rectangle.

Instructions

Create a new blank document and make it current. The viewBox matches width/height, so coordinates are in unit. background (e.g. '#ffffff') adds a full-page rect with id 'background'.

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": {
      "width": "<width>",
      "height": "<height>"
    },
    "name": "document_create"
  }
}

Input Schema

Name	Required	Default
`unit`	No	px
`width`	Yes
`height`	Yes
`background`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A3.5/5.0

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 and does meaningful work: it discloses the side effect of making the document current, the coordinate-system contract ('viewBox matches width/height, so coordinates are in unit'), and the exact artifact the background option creates (a full-page rect with id 'background'). It omits lifecycle concerns such as whether an existing unsaved document is discarded.

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 short sentences, front-loaded with the primary action and followed by the two non-obvious behavioral facts. No filler, though the backtick-heavy phrasing is slightly dense.

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?

Covers the creation action and coordinate/background semantics, but with no annotations and no output schema it leaves gaps around persistence (a save appears to be required via the document_save sibling) and the fate of any currently open document.

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, and it does for all four parameters: it ties width/height to the viewBox, explains unit governs coordinates, and gives a concrete background example plus the resulting element id.

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 specific verb and resource ('Create a new blank document') and adds the state effect ('make it current'). The word 'blank' implicitly distinguishes it from document_open, but no sibling is named explicitly.

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 statement of when to use this versus document_open, import_file, or split, and no mention of prerequisites or what happens to an already-open document. Usage must be inferred entirely from the tool name.

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