Skip to main content
Glama
chriz-3656

Pencil2D Model Context Protocol (MCP) Server

by chriz-3656

pencil2d_export

Renders Pencil2D .pclx animation projects to MP4, animated GIF, or image sequences, with optional frame range, resolution, camera layer, and transparency settings.

Instructions

Render a Pencil2D animation project to video (MP4), animated GIF, or image sequence using the Pencil2D AppImage CLI.

Input Schema

NameRequiredDescriptionDefault
widthNoOptional output width in pixels.
cameraNoName of camera layer to use.
heightNoOptional output height in pixels.
end_frameNoLast frame to include in export.
output_pathYesOutput rendered file (e.g., animation.mp4, preview.gif, frames.png).
start_frameNoFirst frame to include in export.
project_pathYesPath to the .pclx file.
transparencyNoEnable transparency when exporting images or formats that support it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
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 usefully discloses that rendering happens via the Pencil2D AppImage CLI, but says nothing about overwrite behavior for output_path, whether export is long-running/blocking, failure modes, or what is returned. For a file-writing tool with zero annotation coverage 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.

Conciseness4/5

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

A single front-loaded sentence with no filler that puts the action and output formats first. It is efficient, though arguably too terse for an 8-parameter export tool.

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 8 parameters, no annotations, and no output schema, the description should cover overwrite semantics, format selection, and return behavior, but covers none of them. An agent knows what the tool does but not how to call it safely or what to expect back.

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 8 parameters including start/end frame, camera, and transparency. The description adds no extra semantics (e.g., format inferred from output_path extension, default frame range) beyond what the schema provides, so the baseline 3 applies.

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 (render/export), resource (Pencil2D animation project) and the three concrete output formats (MP4, GIF, image sequence), which distinguishes it from siblings like pencil2d_extract_frames and pencil2d_create_spritesheet. It does not explicitly name those siblings, so routing is inferred rather than spelled out.

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 never says when to use this versus pencil2d_extract_frames or pencil2d_create_spritesheet, nor does it state prerequisites (project must exist/validate, AppImage installed). Usage is only implied by the list of output formats.

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