proofcut

Overview Schema Source Related Servers Discussions Admin

card_render

DestructiveIdempotent

Rasterise an SVG card into a PNG that card: cues resolve to, keeping the source for re-editing and reporting font substitutions.

Instructions

Rasterise assets/cards/<name>.svg into the PNG card:<name> shows.

Author the SVG under the project's assets/cards/, then render it here; both files are kept, so a card can be re-edited rather than redrawn. The PNG is what a card: cue resolves to, so a card is not usable until this has run.

width/height are given together or not at all and set the render size — the document is drawn at that scale rather than rasterised and resampled — and they fit rather than distort, so a size at a different aspect from the document's comes back smaller on one axis. Omitted, the document renders at its own declared size.

Every call reports the fonts the document names and what fontconfig will actually draw. Read font_warnings: a card naming a face this machine lacks renders pixel-identically to one naming a face it has, so nothing downstream can catch the substitution.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The card to rasterise: `assets/cards/<name>.svg` becomes the PNG that `card:<name>` resolves to.
`path`	No	The project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing.
`width`	No	Render width. The document is drawn at this scale rather than resampled, so text stays sharp, and it fits rather than distorts. Given together with `height` or not at all; omitted, the document renders at its own declared size.
`height`	No	Render height, given together with `width` or not at all.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.25.0Sep 16, 2026

removedInput schema / properties / height / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / height / description

Added value: +"Render height, given together with `width` or not at all."

removedInput schema / properties / height / title
```
Removed value: -"Height"
```
addedInput schema / properties / height / type
```
Added value: +[
+  "integer",
+  "null"
+]
```

addedInput schema / properties / name / description

Added value: +"The card to rasterise: `assets/cards/<name>.svg` becomes the PNG that `card:<name>` resolves to."

removedInput schema / properties / name / title
```
Removed value: -"Name"
```

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / path / description

Added value: +"The project directory to act on. Omit it — the usual case — when this server is bound to a project (started as `proofcut -C DIR mcp`, or inside a project; `ping` says which): it then resolves to that one bound project, a relative path resolves against it, and a path outside it is refused by name. Unbound, `path` is the whole address and omitting it refuses rather than guessing."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```

addedInput schema / properties / path / type

Added value: +[
+  "string",
+  "null"
+]

removedInput schema / properties / width / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / width / description

Added value: +"Render width. The document is *drawn* at this scale rather than resampled, so text stays sharp, and it fits rather than distorts. Given together with `height` or not at all; omitted, the document renders at its own declared size."

removedInput schema / properties / width / title
```
Removed value: -"Width"
```

addedInput schema / properties / width / type

Added value: +[
+  "integer",
+  "null"
+]

removedInput schema / title
```
Removed value: -"card_renderArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only state idempotent and destructive hints, but the description goes far beyond them: it explains that both source and output are kept, that rendering at a different scale draws rather than resamples, that fit behavior shrinks one axis on aspect mismatch, and critically warns about font substitution producing pixel-identical renders that cannot be caught downstream. This is exactly the kind of behavioral context an agent needs and that annotations do not provide.

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 longer than a couple of sentences, but every paragraph earns its place: purpose, workflow, size semantics, and font warnings are each distinct and necessary. It is front-loaded with the core purpose and organized by concern, with no filler or redundancy beyond a minor overlap with schema descriptions.

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 moderate complexity, a full output schema, and strong annotations, the description is remarkably complete. It covers the entire lifecycle (author → render → use), explains the size constraints with real behavioral detail, and preempts the hardest-to-detect failure mode (font substitution). An agent can call this tool correctly with no additional knowledge.

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% and the schema already documents width/height pairing and omission behavior. The description adds genuine value by explaining the non-resampling render behavior, the fit-not-distort constraint, and the consequence of aspect ratio mismatch. That extra semantic depth moves it above the baseline of 3.

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 a specific verb and resource: 'Rasterise `assets/cards/<name>.svg` into the PNG `card:<name>` shows.' This clearly differentiates it from sibling tools like card_new or card_templates, which create or edit card definitions rather than render them. The purpose is unambiguous and immediately front-loaded.

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 workflow context: author the SVG under assets/cards, then render it to make it usable; it also explains that the PNG is what a card: cue resolves to. It does not explicitly name alternatives or provide when-not-to-use guidance, but the implied usage is strong and sufficient for an agent to decide when this tool is the right one.

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

Deploy Server