Control and monitor a local Blender-based 3D model-to-animation pipeline through MCP tools.
Check the installed runner and Blender without changing configuration (environment_info).
Create an isolated pipeline config for a model and workspace without overwriting an existing config (pipeline_init).
Read cached stages, failures, pending calibration, and review requirements (pipeline_status).
Start/resume pipeline stages as background jobs, optionally through a specified stage (pipeline_run).
Run trusted local Blender Python scripts in a hidden background process (blender_script).
Poll background job completion and read its log tail (job_status).
Record real candidate-bound visual review from an existing evidence JSON file (record_review).
Diagnose and record an established stage failure cause before retrying (diagnose_stage).
Display an existing PNG/JPEG artifact inside a model workspace, up to 10 MiB (view_artifact).
Provides tools to control background Blender jobs for a 3D character and companion animation pipeline, including inspection, calibration, animation baking, GLB export, numerical verification, probe rendering, and packaging.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Companion Animation Pipeline MCP Server Inspect character.glb, calibrate bones, bake walk cycle, export verified GLB."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Inspect → calibrate → animate → export → verify → review → package.
A standalone Blender pipeline for 3D characters and companions, with a Python CLI, an installable AI skill, and a local MCP server that controls background Blender jobs. Keep model-specific work resumable, source files intact, and successful export separate from successful animation.
The public showcase uses only newly generated synthetic geometry. It contains no private models, game code, customer data, or recordings from another product. See the showcase and its evidence.
Related MCP server: Blender Universal & Token-Efficient MCP Server
The installer sets up uv, Python 3.12, the CLI, MCP dependencies, an AI skill, and Blender. It reuses an existing Blender or installs a portable, checksum-verified Blender 4.5.3 build in your user data directory. No separate Blender add-on, Node.js, Git installation, API key, or subscription is required.
Invoke-RestMethod https://raw.githubusercontent.com/arabianguy08/3d-model-to-animation-pipeline/v0.1.1/install.ps1 -OutFile install.ps1
.\install.ps1 -Client codexcurl -LsSf https://raw.githubusercontent.com/arabianguy08/3d-model-to-animation-pipeline/v0.1.1/install.sh -o install.sh
sh install.sh --client codexChoose codex, claude-code, claude-desktop, cursor, or generic instead.
The first four configure their MCP connection automatically; restart the AI
client afterward. That client's normal tool-approval rules still apply.
auto registers a uniquely detected Codex/Claude CLI; otherwise it writes a
portable companion-mcp.json rather than guessing which app to change.
Use -ManagedBlender / --managed-blender to install the pinned build even when
Blender is already present. Use -Blender / --blender for your own executable.
Client applications themselves are not installed. See setup details.
companion-animation doctor
companion-animation demo ./my-first-demoThe demo creates an original synthetic rig and face, bakes real actions, exports a GLB, reopens it, verifies deformation/timing and renders inspection evidence. Packaging still requires real visual review. Nothing is uploaded.
For your own model:
companion-animation init model.json --model ./character.glb --workspace ./work
companion-animation inspect model.json
companion-animation status model.jsonTell your agent:
Use the companion-animation-pipeline skill and MCP tools. Inspect my model, calibrate its anatomy and named bones, preserve its original proportions and authored motion, and produce a numerically verified GLB with playback for review.
Then follow the usage guide.
Shared stages: inspection, job isolation, baking, GLB export, numerical checks, probe rendering, cache invalidation, resumption and packaging.
Model-specific work: anatomical fitting, weights, bone mapping, clip selection, facial geometry and believable motion. An AI can do this through the included Blender tools, but an arbitrary upload is not a guaranteed one-click rig.
Numerical certification checks the persisted GLB, not just an animation name. Temporal/artistic quality still needs inspection. Supplied clips keep their exact timing, loop/hold behavior and action-slot binding.
VFX examples show presentation and timing. Projectile movement, collision, combat logic and mobile performance belong to the consuming application.
python -m pip install .
python -m unittest discover -s tests -v
python tests/test_pipeline.py --blender /path/to/blender BlenderTests -vThe runner itself uses the Python standard library; Blender supplies bpy,
NumPy and mathutils. The MCP interface uses the official MCP Python SDK 1.x.
Verification distinguishes real Blender checks, unit
tests, visual review and untested platforms.
The MCP server uses stdio and opens no HTTP port. blender_script executes
trusted local Python with your account permissions; this is not a sandbox.
Adapters and models stay local unless you explicitly share them. Read install
scripts before running downloaded code.
Pipeline code and synthetic showcase material: MIT. Blender is a separate application with its own license. Dependency licenses remain with their respective projects.
Run a trusted local Blender Python script in a hidden background process.
The script must be inside workspace; scripts have normal user permissions, not a security sandbox. Author to derivative paths; never overwrite the source. sys.argv after -- contains the workspace path.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | ||
| workspace | Yes | ||
| blend_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does add real context: hidden background process, normal user permissions (explicitly not a sandbox), workspace confinement, and the sys.argv contract. However, it omits failure behavior, timeouts, and whether blend_file/environment state is mutated, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action before the safety and argv constraints. Nothing is repeated from structured fields and each sentence conveys a constraint. It is slightly terse given the tool's complexity but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary local scripts with no annotations and no output schema, the description covers safety posture and the argv contract but leaves return values, error behavior, and two of three parameters unexplained. It is adequate but with clear gaps an agent would want filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across all 3 parameters, so the description is the only source of parameter meaning. It clarifies 'workspace' (script must be inside it, and its path is passed via sys.argv after --), but the 'script' and 'blend_file' parameters are never explained in either the schema or the description, leaving two of three undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: running a trusted local Blender Python script in a hidden background process. That is unambiguous and an agent can tell what the tool executes. It does not name or contrast with any sibling, but none of the siblings (pipeline_run, view_artifact, etc.) appear to overlap with script execution, so differentiation is implicit rather than necessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context ('trusted local Blender Python script', 'script must be inside workspace') and gives an authoring rule ('derivative paths; never overwrite the source'), but never says when to reach for this tool versus pipeline_run or the other siblings. Usage is implied rather than stated, which is the definition of a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an established failure cause before retrying a stage. Does not relax tolerances.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| stage | Yes | ||
| config | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only discloses one cryptic trait ('does not relax tolerances') and omits what state is recorded, whether it mutates anything, permission requirements, or whether it is idempotent. For a write/record operation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and no wasted words. However, the closing clause is vague enough that it earns less than a full concise, informative statement would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 3-parameter, all-required tool with no annotations, no output schema, and 0% param coverage needs more than two terse sentences. The description leaves the meaning of 'config', the return/effect of recording, and permissions unexplained, so an agent lacks enough to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all three parameters (config, stage, note) are undocumented in the schema. The description hints at 'stage' and the failure-cause note but never explains the 'config' parameter or the expected format for any of them. It does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Record an established failure cause' tied to a stage. An agent can grasp the core action, though it is not sharply differentiated from siblings like record_review or pipeline_run. The trailing phrase 'Does not relax tolerances' is cryptic and does not clarify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one timing hint: 'before retrying a stage.' That implies when to call it, but no alternatives are named (e.g., pipeline_run for the retry itself) and there is no explicit when-not guidance. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the installed runner and Blender without changing configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose one meaningful trait: the check is non-mutating toward configuration. However, it says nothing about what is reported back (versions, paths, availability) or what happens if Blender is absent, which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The action and its non-mutating guarantee are packed into one clause pair and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter probe this is close to adequate, but with no output schema the description should say what the check returns (runner/Blender versions or paths) so an agent knows what it will learn before calling. That gap keeps it at minimum-viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema imposes nothing to interpret. Per the baseline for param-less tools, a 4 is appropriate; there is no parameter surface the description needs to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('installed runner and Blender'), making the tool's function immediately legible. It does not explicitly name a sibling to differentiate from, but the environment-inspection scope is distinct from pipeline_run, blender_script, and the status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus alternatives such as diagnose_stage or pipeline_status, and no prerequisites or ordering guidance. The clause 'without changing configuration' is a safety property rather than usage guidance, so the agent is left to infer the call context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read background job completion and its log tail. Does not infer visual approval.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the response includes completion info and a log tail, and it flags a limitation around approval inference. However, it says nothing about permissions, log truncation, or how completion/failure states are represented, which is a meaningful gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action, with no filler. The second sentence is terse to the point of being cryptic, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description covers the gist but leaves out how status values are structured and how to interpret the log tail. It is adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never mentions the single parameter job_id – what form an ID takes or where to obtain it. The name is fairly self-evident, but the description does nothing to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('background job completion and its log tail'), which is more precise than a tautology like 'get job status'. It does not, however, explicitly contrast itself with the sibling pipeline_status, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Does not infer visual approval' gives one useful boundary – this tool reports completion, not approval decisions – but there is no positive guidance on when to prefer it over pipeline_status or diagnose_stage. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an isolated config for a supplied model; never overwrite an existing config.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| config | Yes | ||
| workspace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states a key behavioral trait: 'never overwrite an existing config', which is crucial for safe usage. It does not explain permissions, error handling, or return format, but for a simple creation tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and a critical constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters with zero schema coverage and no output schema, the description is incomplete. It provides the key constraint but falls short on parameter meaning and operational context. An agent would need to infer or experiment to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and all three parameters (model, config, workspace) are undocumented in both schema and description. The description mentions 'supplied model' but does not clarify what config or workspace refer to, leaving users to guess. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (create) and resource (isolated config for a supplied model). It distinguishes from sibling tools like environment_info and pipeline_run, which do not create configs. However, it lacks detail on what an 'isolated config' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use to initialize a pipeline config for a model. No explicit when/when-not or alternative tools are mentioned. Sibling tools like pipeline_run and pipeline_status suggest this is a setup step, but the description does not state prerequisites or related workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start/resume stages as a background job. Poll job_status; exit 2 means work/review remains.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | ||
| through | No | preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose non-obvious traits: asynchronous background execution and the exit-code convention (exit 2 = work/review remains). It omits side effects, idempotency of resume, and permission requirements for a tool that mutates pipeline state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded and no filler. It is arguably under-sized for a 2-param, zero-coverage, annotation-free tool, which slightly undercuts 'appropriately sized'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 0% schema coverage mean the description must cover parameters, side effects, and return behavior, and it covers none of them. Only the async/polling hint is provided, leaving the agent without enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and neither 'config' (required) nor 'through' (default 'preview') is explained anywhere. The description says nothing about what config contains or what stage/scope 'through' selects, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Start/resume stages') and adds the execution model ('as a background job'). It is clearly distinct from pipeline_status, but it never explicitly differentiates itself from the sibling pipeline_init, which an agent could easily confuse with 'run'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful next-step guidance ('Poll job_status; exit 2 means work/review remains'), which is implied usage. However it gives no condition for choosing this tool over pipeline_init or pipeline_status, and no prerequisites, so usage is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read cached stages, failures, pending calibration and review requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It hints at read-only cached data, but says nothing about cache staleness, whether it triggers recalculation, permission requirements, or what the returned structure looks like for a status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded and free of filler. However, the terseness reflects under-specification rather than disciplined economy, so it is only adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an undocumented required parameter, the description does not supply enough for an agent to call this tool correctly. Essential context about the 'config' argument and the status response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required 'config' parameter, and the description says nothing about it. The agent cannot tell whether 'config' is a path, an identifier, or an inline config object, so the gap is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names what is read (cached stages, failures, calibration, review requirements) which implies a pipeline-status read, but it never states the tool's purpose in a verb+resource form like 'Return pipeline status'. It is distinguishable from pipeline_run or record_review by its read framing, but only loosely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no indication of how it differs from siblings such as job_status or diagnose_stage, and no mention of prerequisites or alternatives. The agent is left to infer that this is the polling/status check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record real candidate-bound visual review from an existing evidence JSON file.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | ||
| evidence | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a write/mutation (recording a review) and hints at validation ('real', 'candidate-bound'), but says nothing about side effects, where the review is stored, whether it overwrites prior reviews, required permissions, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler, and the action verb and source file are front-loaded. It is efficient, though the brevity borders on under-specification for a tool with two undocumented required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a pipeline tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. Missing are the meaning of 'config', the expected evidence file format, what gets persisted, and how this step fits between view_artifact and job_status in the pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that 'evidence' is an existing JSON file path, but the required 'config' parameter is never mentioned or explained, leaving half the inputs semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Record') and resource ('candidate-bound visual review') and identifies the source of truth ('an existing evidence JSON file'). The qualifier 'real' hints the review must be genuine rather than fabricated, which is meaningful, though 'candidate-bound' is domain jargon an unfamiliar agent may not decode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of how this relates to siblings like pipeline_run, diagnose_stage, or view_artifact. The agent is left to infer that recording a review is a distinct step from running the pipeline or viewing artifacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display an existing PNG/JPEG inside a model workspace; maximum 10 MiB.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| workspace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose two useful traits — the accepted formats (PNG/JPEG) and a size ceiling (10 MiB) — but says nothing about what 'display' returns, whether the workspace must pre-exist, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the constraint is stated immediately after the purpose. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations mean the description should be more self-sufficient. Format and size limits are covered, but the relationship between path and workspace, and the return/rendering behavior, are left unaddressed for a two-required-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and neither parameter has a title description, so the description is the only source of meaning. It does not explain what 'path' is relative to, nor what form 'workspace' takes, leaving both required parameters effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Display) and resource (existing PNG/JPEG inside a model workspace), which is concrete and actionable. It does not, however, name or differentiate itself from any sibling (e.g. blender_script or record_review), so the agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no alternatives. It only states a resource constraint (PNG/JPEG, 10 MiB), which narrows what can be passed but not when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1blender_scriptdiagnose_stageenvironment_infojob_statuspipeline_initpipeline_runpipeline_statusrecord_reviewview_artifactScored across 9 tools
Tools are mostly distinct, but pipeline_status and job_status both report status at different scopes, and blender_script vs pipeline_run may be confused by an agent deciding between custom scripting and managed stages. Descriptions clarify the intended separation, but the overlap prevents perfect clarity.
All names use snake_case consistently, with readable prefixes such as pipeline_* and job_*. However the set mixes noun-first names (environment_info, pipeline_status) with verb-first names (record_review, diagnose_stage, view_artifact), so the pattern is not fully uniform.
Nine tools is well-scoped for an animation pipeline: setup, execution, monitoring, review, diagnosis, and artifact viewing each have a clear place. The count avoids both thinness and bloat.
The core pipeline lifecycle is covered, but pipeline_status references pending calibration while no tool records or resolves calibration. There is also no explicit stop/cancel for background jobs or cleanup/reset operation, creating potential dead ends.
3D avatar/asset foundry: text/image -> rigged, validated, engine-ready GLB via x402.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.
Blender-as-a-service for agents: search 3D assets, run Blender Python, or brief the studio agent.
Cloud Blender for AI agents: build, inspect, render and animate 3D scenes over remote MCP. Keep editable .blend projects and export GLB or STL. Make your first 3D asset free—30 compute minutes per UTC month, no credit card. First 100 eligible Free account owners to use all 30 minutes in one UTC month by December 31, 2026 UTC receive one calendar month of beta free: 4 compute hours per UTC month, 2 concurrent workers per deployment, 2 deployments, 2048×2048 renders at up to 256 samples, and 10 GiB storage. Existing usage counts toward the 4-hour allowance. Limited to 100 rewards; expires January 1, 2027 00:00 UTC. Free resumes afterward without an automatic charge. Examples, eligibility and terms: https://sceneplane.online/launch?utm_source=glama&utm_medium=directory&utm_campaign=first100
