Skip to main content
Glama
chriz-3656

Pencil2D Model Context Protocol (MCP) Server

by chriz-3656

pencil2d_add_audio

Attach a WAV or MP3 sound clip to a sound layer at a chosen keyframe, so you can sync audio with animation timing.

Instructions

Attach a sound clip (WAV/MP3) to a sound layer at a specific keyframe in the animation.

Input Schema

NameRequiredDescriptionDefault
frameNoKeyframe number where audio starts playing (default 1).
audio_pathYesPath to audio file (.wav, .mp3) to embed.
layer_nameNoSound layer name (default 'Sound Layer').
project_pathYesPath to the .pclx file.

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?

With no annotations, the description carries the full behavioral burden, yet it does not disclose whether the .pclx is saved/mutated on disk, what happens if the named sound layer does not exist, whether audio is embedded vs referenced, or any error behavior. Only the media format constraint (WAV/MP3) is added, which is minimal for an unannotated write-style operation.

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 well-formed sentence with the core action front-loaded and no filler. It is efficiently sized, though it leaves little room for the behavioral detail an unannotated tool needs.

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-parameter mutation tool with no annotations and no output schema, the definition covers the 'what' and the media formats but omits persistence behavior, layer-existence assumptions, and return/error semantics. The rich schema compensates partially, leaving it adequate but incomplete.

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 all four parameters (including defaults for frame and layer_name) are already documented in the schema. The description restates the keyframe and sound-layer concepts but adds no syntax, constraints, or format detail beyond the schema, 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 ('Attach') and resource ('sound clip') with the target ('sound layer at a specific keyframe'), so the action is unambiguous. It implicitly distinguishes itself from siblings since it is the only audio-related tool, but it never names or contrasts with any sibling to reinforce that.

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 use this versus alternatives, no prerequisites (e.g., must a sound layer already exist?), and no exclusions. The agent must infer the entire usage context from the verb alone.

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