Clip Studio MCP

get_character_film

Read-only

Fetch a Character Film render or project. Pass renderId from generate_character_film or continue_character_film, or projectId from plan_character_film. Returns status, stage, blocksDone, blocksTotal, outputUrl, and canContinue. Poll until status is completed or failed. Submit and poll; do not wait on generate for the full render.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`renderId`	No	Render id from generate_character_film or continue_character_film. Required unless projectId is set.
`projectId`	No	Project id from plan_character_film. Required unless renderId is set. Includes canContinue for the remaining range.

Output Schema

TableJSON Schema

Name	Required	Description
`range`	No	opening or remaining for the render being reported.
`stage`	No	Pipeline stage: planning, narrator, keyframes, voice, shots, score, edit, or done.
`blocks`	No	Rendered or planned blocks for this film.
`status`	No	Job status such as pending, queued, in_progress, completed, or failed.
`project`	No	Project record when loaded.
`renders`	No	All renders on this project when loaded.
`videoId`	No	Library clip id for this job, when one exists.
`refunded`	No	True when a failed render returned that job’s allowance.
`renderId`	No	Render id when this lookup is for a render, or the latest render on the project.
`outputUrl`	No	Download or playback URL when the job has finished.
`projectId`	No	Project id.
`blocksDone`	No	Blocks finished in this render.
`blocksTotal`	No	Blocks in this render.
`canContinue`	No	True when the opening has completed and the remaining range has not been filmed yet. Call continue_character_film.
`failureCode`	No	Stable failure code when status is failed.
`failureStage`	No	Pipeline stage that failed, when known.
`billingSource`	No	How this render was billed.
`failureDetail`	No	Sanitized provider detail (endpoint, HTTP status, first 300 characters). Never a prompt.
`creditsCharged`	No	Usage already consumed from this month’s generation allowance (internal units).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 26, 2026

addedOutput schema / properties / failureDetail

Added value: +{
+  "description": "Sanitized provider detail (endpoint, HTTP status, first 300 characters). Never a prompt.",
+  "type": "string"
+}

addedOutput schema / properties / failureStage

Added value: +{
+  "description": "Pipeline stage that failed, when known.",
+  "type": "string"
+}

AddedSep 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only and non-destructive behavior. The description adds the polling behavior, the terminal statuses to watch for, and the exact returned fields, which is useful behavioral context beyond the structured annotations. No contradiction.

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

Conciseness5/5

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

Four tight sentences, zero filler. It front-loads the purpose, then gives parameter wiring, return fields, and the polling instruction – every sentence earns its place.

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?

The description covers the complete usage pattern: submit, pass the right ID, poll to terminal states, and what the result contains. Combined with the output schema and annotations, nothing essential is missing for an agent to call this tool correctly.

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%, so both parameters are already documented. The description adds provenance for the IDs, linking renderId to generate/continue and projectId to plan, plus reiterating that projectId includes canContinue – this helps the agent wire the asynchronous workflow correctly.

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 first sentence, 'Fetch a Character Film render or project,' states a specific verb, resource, and the two modes (render vs. project). It further names the sibling tools that produce the required IDs, distinguishing it from other get_* and generation tools.

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 explicitly tells the agent where to get the IDs ('from generate_character_film or continue_character_film' and 'from plan_character_film') and gives the polling workflow ('Poll until status is completed or failed'). It lacks explicit alternatives/exclusions, but the context is clear enough for an agent to know when to call this tool.

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

All Clip Studio MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?