Provides tools for inspecting and editing a running Autodesk Maya scene, including scene context, naming, hierarchy, connections, viewport capture, and executing native Maya commands.
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., "@Maya MCP Show the scene hierarchy under my character root joint"
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.
A compact MCP server for inspecting and editing a running Autodesk Maya scene. The integration has two local processes:
MCP client --stdio--> maya_mcp.mcp_server --ZMQ REQ/REP--> Maya bridgeThe MCP adapter currently exposes six tools for the scene-project experiment:
scene_context
scene_naming
scene_hierarchy
scene_connections
viewport_capture
maya_command
The bridge still contains the earlier query, inspect, graph, patch, and verify handlers, but they are intentionally not registered as MCP tools while the new workflow is being tested.
Heavy geometry values such as mesh points, topology arrays, skin weights, and blend-shape deltas are deliberately omitted.
viewport_capture returns a PNG from the active model panel or a specified
camera directly as MCP image content. It does not keep the temporary image on
disk. Width and height must be divisible by four and between 64 and 2048.
scene_naming provides a cheap first pass over prefixes, suffixes, likely
families, and NURBS control candidates. scene_hierarchy returns a compact
text DAG tree without shapes by default, so node identity metadata is not
repeated for every line. It shows transforms, joints, and IK handles by
default; pass include_types: ["*"] to include constraints and every DAG type.
scene_connections follows inputs, outputs, or both from focused nodes and
plugs. Connections are split by direction and keep exact plugs while placing
the node type directly beside each endpoint:
inputs:
- source (joint): M_spine_5_joint.worldMatrix
destination (parentConstraint): L_arm_options_control_parentConstraint1.targetParentMatrixStart with depth: 1; expand only when the next part of the graph is unclear.
Use include_types or exclude_types to focus the result without requesting a
flat dump of the entire DG.
maya_command calls one native maya.cmds command with JSON positional and
keyword arguments, or accepts a commands list for a batch. The complete call
or batch runs in one undo chunk and is rolled back when Maya raises an error.
Create a normal virtual environment outside Maya:
cd D:\github\maya_mcp
py -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[test]"Configure the IDE to run:
D:\github\maya_mcp\.venv\Scripts\python.exewith arguments:
-m maya_mcp.mcp_serverThe MCP process communicates only through stdout/stdin. Diagnostic output must therefore go to stderr or a log file.
Related MCP server: maya-mcp
The Maya Python environment needs access to pyzmq. Then run this in Maya's
Python Script Editor:
import sys
project_path = r"D:\github\maya_mcp"
if project_path not in sys.path:
sys.path.insert(0, project_path)
import maya_mcp
maya_mcp.start()The default endpoint is tcp://127.0.0.1:51608. Override it in both processes
with MAYA_MCP_ENDPOINT. An optional matching MAYA_MCP_TOKEN can protect the
local endpoint.
Stop the bridge with:
maya_mcp.stop().\.venv\Scripts\python.exe -m pytest -qThese tests cover the external transport and Maya-independent helpers. The Maya scene operations require an integration test in a running Maya process.
Execute one native maya.cmds command or a batch in a single undo chunk.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| kwargs | No | ||
| command | No | ||
| commands | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it discloses only that batches are grouped into one undo chunk. It says nothing about whether commands mutate the scene, what permissions or context (main thread, open scene) are required, what happens when one command in a batch fails (partial application vs. rollback), or how errors are surfaced.
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, and the key scope statement comes first. It is efficient, though its brevity is arguably under-specification rather than disciplined concision given the tool's risk profile.
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?
An output schema exists, so return values need not be explained, and the undo-chunk note covers the most surprising side effect. But for an arbitrary execution escape hatch with four undocumented parameters and no annotations, the description leaves too much for the agent to infer before calling.
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 four parameters, so the description must compensate and does not. It hints at a single-vs-batch distinction ('one command or a batch') but never maps that to 'command'+'args'+'kwargs' vs. 'commands', nor says whether the two forms are mutually exclusive or what shape a batch entry takes.
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 ('Execute') and resource ('one native maya.cmds command or a batch'), which clearly distinguishes it from the read-only scene_* siblings. The scope is understandable without opening the schema, though 'native maya.cmds' assumes the agent knows what that surface covers.
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 guidance on when to use this versus the structured siblings (scene_context, scene_hierarchy, etc.) or when a batch should replace two single calls. The only implicit cue is 'batch ... single undo chunk', which is a behavior, not a selection rule, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow compact input/output plug connections from nodes or plugs.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| targets | No | ||
| direction | No | both | |
| exclude_types | No | ||
| include_types | No | ||
| max_connections | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Follow' implies a read-only traversal, but the description does not explain traversal limits, truncation behavior, depth handling, or side effects, which are important for an agent invoking a graph-connection 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?
The description is a single front-loaded sentence with no filler. It is concise, though its brevity contributes to the missing parameter and usage details assessed elsewhere.
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?
The tool has six parameters, no annotations, and only one short description sentence. Although an output schema exists and need not be repeated, the description is not complete enough to tell an agent how to scope the traversal or what the parameters mean.
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 schema has six parameters with 0% description coverage, and the description does not name or explain any of them. At best, 'input/output' hints at the direction enum and 'nodes or plugs' hints at targets, but depth, include_types, exclude_types, and max_connections are entirely 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, 'Follow,' and a specific resource, 'input/output plug connections from nodes or plugs.' It is clear enough to distinguish this as a connection-traversal tool rather than a scene context or hierarchy tool, but it does not explicitly differentiate itself from the sibling 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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only says what the tool does, leaving an agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scene metadata, selection, roots, units, time, and node counts.
| Name | Required | Description | Default |
|---|---|---|---|
| root_limit | No | ||
| count_types | No | ||
| include_plugins | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. 'Get' implies a read, but nothing is said about cost, whether the call traverses the whole scene, whether root listing is truncated (the root_limit default of 100 hints at truncation but this is never stated), or plugin-inclusion side effects.
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 listing the returned facets with no filler. It is efficient, though the bare enumeration leaves room for a short clarifying clause about truncation or scope.
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?
An output schema exists, so return values needn't be spelled out, which lowers the bar. However, for a three-parameter introspection tool with zero schema coverage and no annotations, the description should at minimum explain root_limit truncation and include_plugins.
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 all three parameters (root_limit, count_types, include_plugins) are undocumented everywhere. The description's mention of 'roots' and 'node counts' loosely maps to the first two, but include_plugins is never explained and no format, units, or valid values are given.
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 ('Get') and enumerates concrete contents (metadata, selection, roots, units, time, node counts), so an agent knows exactly what comes back. It doesn't explicitly contrast with siblings like scene_hierarchy or scene_naming, leaving some overlap to inference.
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 guidance on when to call this versus scene_hierarchy, scene_naming, or scene_connections, and no preconditions or exclusions. The agent must infer from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a compact text DAG hierarchy from roots or the current selection.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| roots | No | ||
| max_nodes | No | ||
| include_types | No | ||
| include_shapes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation and mentions compact text output, but it does not explain permissions, selection impact, output limits, truncation behavior, or how depth and max_nodes affect the result.
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 filler and the core action is immediately clear. Its brevity becomes under-specification for a five-parameter tool, but the sentence itself is efficient.
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?
The tool has five optional parameters and no annotations, so the description should provide more behavioral and parameter context. Although an output schema exists and return values need not be explained, the input parameter meaning and usage guidance remain largely absent.
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 the description only loosely explains 'roots' as an entry point. It provides no meaning for depth, max_nodes, include_types, or include_shapes, leaving most parameters undocumented in both the schema and the description.
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: 'Read a compact text DAG hierarchy' from roots or the current selection. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools such as scene_context or scene_connections.
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 phrase 'from roots or the current selection' hints at source selection, but there is no explicit guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize common prefixes, suffixes, families, and NURBS control candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| family_limit | No | ||
| max_examples | No | ||
| prefix_limit | No | ||
| suffix_limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only says 'Summarize' — it never states whether this is read-only, what scope of scene it inspects, or whether it requires a loaded scene. For a four-parameter analysis 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with no padding, and the enumerated result types are front-loaded. It is efficient, though its brevity comes at the cost of the substance missing above.
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?
An output schema exists, so return values need not be described, but the definition still leaves the input parameters undocumented and the operation's scope and safety profile unstated. For a tool with four unexplained integer controls, the description does not provide enough to invoke 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%, so the description must compensate; it partially does by naming prefixes, suffixes, and families, which map to prefix_limit, suffix_limit, and family_limit. However, max_examples and the truncation/limit semantics of all four integers remain completely unexplained in both the schema and the description.
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 a concrete output ('common prefixes, suffixes, families, and NURBS control candidates') but never states the resource being analyzed — presumably object names in the current scene — so the verb 'Summarize' hangs on an unstated object. It also does nothing to separate it from siblings like scene_context or scene_hierarchy, which could plausibly also report name information.
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 indication of when to call this versus scene_context, scene_hierarchy, or scene_connections, and no exclusions or prerequisites are given. An agent has to guess that this is the naming-convention analysis tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the active Maya viewport or a specified camera and return it as a PNG image.
| Name | Required | Description | Default |
|---|---|---|---|
| panel | No | ||
| width | No | ||
| camera | No | ||
| height | No | ||
| off_screen | No | ||
| show_ornaments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it only discloses the output format (PNG). It says nothing about what 'off_screen' capture means behaviorally, whether capturing disturbs scene state, whether ornaments/grids are included by default, or whether a render is required — all of which materially change the result.
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 single sentence is front-loaded, efficient, and contains no filler. Its brevity is a virtue structurally, though it leaves the definition under-specified for a six-parameter tool.
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 with six optional parameters, zero schema descriptions, no annotations, and no output schema, one sentence is not sufficient. The agent knows it gets a PNG but not how the resolution, camera selection, or ornament toggles interact, so it cannot call this confidently without guessing.
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 six parameters, so the description must compensate and it largely does not. Only the camera/panel targeting is implied by the prose; width, height, off_screen, and show_ornaments are wholly undocumented in meaning beyond their names and defaults.
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 ('Capture the active Maya viewport or a specified camera') and names the return artifact ('PNG image'), so the agent knows exactly what the tool produces. It does not distinguish itself from siblings like scene_context or maya_command, which is the only thing keeping it from a 5.
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 guidance on when to use this versus alternatives such as scene_context or maya_command, nor any mention of prerequisites like a Maya session being open or a viewport being visible. The agent is left to infer the entire selection context.
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.0maya_commandscene_connectionsscene_contextscene_hierarchyscene_namingviewport_captureScored across 6 tools
The four scene_* inspection tools have distinct targets: metadata, naming patterns, hierarchy, and connections. The only ambiguity comes from maya_command, a generic escape hatch that can overlap with every specialized tool, though its intended use as a native-command executor is clear.
All names use consistent two-word snake_case with clear domain prefixes such as scene_ and viewport_. The convention is predictable and readable even though it is noun-oriented rather than verb_noun.
Six tools is a well-scoped set for Maya scene inspection plus command execution. Each tool has a focused role, and there is no bloat or missing obvious specialization.
The set covers key read operations, viewport capture, and arbitrary command execution, so agents are not blocked. It lacks dedicated structured tools for common write or attribute-editing workflows, but maya_command provides a workaround.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Search, inspect, organize, annotate, share, and automate creative assets in Shade.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Connect your AI assistant to Blender for 3D modeling, Geometry Nodes, materials, lighting, animation, rendering and export. Inspect real scenes and viewport images, refine the result and restore checkpoints. OAuth connects your chat to Blender Bridge Desktop on an online Windows 10/11 x64 computer running Blender 4.2+. The chat can run on another device. Requires an active Blender Bridge account; 7-day trial available. AI model access is separate.
