maya-mcp

by abrahamADSK

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.23.0
Disambiguation4/5
Most tools have clearly distinct purposes, e.g., creating primitives, cameras, lights. Minor overlap exists between maya_viewport_capture and maya_session's review_turntable, but descriptions clarify differences. Overall, agents can reliably distinguish tools.
Naming Consistency3/5
Most tools follow a `maya_<verb>_<noun>` pattern, but several tools like `learn_pattern`, `reset_session_stats`, `search_maya_docs`, and `session_stats` break the pattern by lacking the `maya_` prefix. The internal consistency is decent, but the mix is notable.
Tool Count4/5
16 tools cover a broad range of Maya functionality including modeling, animation, lighting, and AI integration. While slightly on the heavier side, each tool serves a specific purpose and the set feels well-scoped for a comprehensive Maya assistant.
Completeness3/5
The tool set covers core workflows like scene creation, import, transforms, and rendering. However, gaps exist—no tools for rigging, deformers, or advanced animation curves. The inclusion of `search_maya_docs` and `learn_pattern` partially mitigates gaps, but notable operations are missing.
Average 3.8/5 across 16 of 16 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 80 commits in the last 12 weeks
- Last stable release on August 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention whether operations modify the original object, create new ones, require selection, or have undo capabilities. For a mutating tool with multiple operations, this omission is critical.
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?
Single sentence with no filler. Front-loaded with 'Execute mesh operations' and lists operations efficiently. Could include more context without sacrificing conciseness.
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?
For a tool with multiple operation types (some requiring multiple objects), the description lacks behavioral context such as side effects, required object states, or parameter dependencies. Despite an output schema existing, the minimal description is insufficient for complex use cases.
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?
The input schema provides detailed descriptions for each parameter (e.g., faces, offset, divisions). The description adds a high-level list of operations but does not explain parameter relationships or usage beyond the schema. Schema coverage is high, so baseline 3 is appropriate.
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?
The description clearly states the tool executes mesh operations and lists specific types (extrude, bevel, boolean, etc.). It distinguishes from sibling tools like maya_create_primitive (creation) and maya_transform (transformations), but does not explicitly name the resource (e.g., 'on a mesh object').
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?
No guidance on when to use this tool versus alternatives. Does not specify prerequisites (e.g., object must exist) or provide when-not-to-use scenarios. Sibling tools like maya_create_primitive are for creation, but no explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'create a camera', which implies a mutating operation, but does not disclose side effects (e.g., new node added to scene, selection changes, or what happens to existing cameras). For a creation tool, this is insufficient.
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?
A single, well-structured sentence that is front-loaded with the action and key configurable attributes. No extraneous information, earning its place.
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?
Given the tool has an output schema, the description need not explain return values. It adequately conveys the basic operation but lacks completeness in terms of behavioral context and parameter details. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions three of four parameters (position, look-at, focal length) but adds no detailed meaning beyond the schema's own descriptions. The name parameter is omitted. With schema description coverage reported as 0%, the description does not compensate by providing additional context.
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?
The description clearly states the action 'create a camera' and specifies configurable attributes (position, look-at, focal length). This distinguishes it from sibling tools like maya_create_light or maya_create_primitive. However, it could explicitly state that it creates a camera node in the Maya scene.
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?
No guidance is provided on when to use this tool versus alternatives, such as maya_import_file or maya_create_primitive. There is no mention of prerequisites like an open Maya scene or any context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full burden for behavioral disclosure. It only states 'create' without specifying side effects, required permissions, or whether the operation is reversible. This is insufficient for a mutation tool.
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?
The description is a single efficient sentence that front-loads the core purpose. However, it could be slightly more structured by listing the configurable attributes more explicitly.
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?
The tool has an output schema (not shown) which may document return values, so the description need not explain them. However, it omits mention of position and name parameters, which are configurable. Overall adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the tool description does not detail any parameter). Although the schema includes descriptions for each parameter, the tool description only generically mentions 'intensity and color' without adding meaning. It misses position and name, and does not compensate for the low coverage.
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 description clearly states the action (create), the resource (a light in Maya), and specifies the supported light types (directional, point, spot, area, ambient). This distinguishes it from sibling tools like maya_create_camera or maya_create_primitive.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The agent lacks context to choose correctly among creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It does not mention whether transforms are absolute or relative (though 'relative' parameter exists), or any side effects like history changes. Only states the action types.
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?
Single sentence, no wasted words, but overly sparse. Could include more context without losing conciseness.
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?
Despite output schema existing, the description fails to cover the tool's complexity (3 operations, 5 parameters). No mention of parameters or how to use them, making it incomplete for a transform tool.
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 descriptions cover parameters fully (e.g., 'New scale [x, y, z]'), so baseline is 3. The tool description adds no additional meaning beyond what the schema provides.
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?
Description uses specific verbs (move, rotate, scale) and identifies the resource (object in Maya scene), clearly distinguishing from sibling tools like maya_create_primitive or maya_assign_material.
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?
No guidance on when to use this tool vs alternatives, nor any conditions for move vs rotate vs scale. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden but only states basic action. Does not disclose side effects (e.g., naming conflicts, undo behavior), or behavior when position/scale/rotation are omitted.
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?
Single sentence with verb and object front-loaded. Concise, but could include a brief usage note (e.g., naming defaults).
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?
Output schema exists (not shown), so return value explanation unnecessary. Lacks guidance on integration with other tools or error handling, but sufficient for basic use.
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?
Input schema has descriptions for each parameter (0% coverage context likely refers to top-level, not nested). Description adds no extra meaning beyond summarizing optional parameters. Baseline 3 as schema already provides meaning.
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?
Description clearly states verb 'Create', resource '3D primitive', and lists all supported types (cube, sphere, etc.). This distinguishes it from sibling tools like maya_create_camera and maya_create_light.
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?
No guidance on when to use this tool versus alternatives (e.g., maya_mesh_operation for modifications). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It omits behavior like whether existing keyframes are overwritten, animation curve effects, or prerequisites (e.g., object must exist).
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?
The description is a single, focused sentence. It is front-loaded and efficient, with no redundant words.
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?
Adequate for a simple keyframe tool but incomplete: does not mention return value (output schema exists), error handling, or interpolation behavior. Could add context on attribute default or tangents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the schema's property descriptions exist. The tool description does not add meaning beyond listing parameters; it does not explain relationships or usage order.
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 description is specific: 'Create an animation keyframe on an object' and lists animatable properties (translate, rotate, scale, visibility), clearly distinguishing it from siblings like maya_transform.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., maya_transform for non-keyframe transformations). The description provides no when-not or context-of-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary actions (create material, assign to object) but omits behavioral details such as whether existing materials are overwritten, if new nodes are always created, or any side effects. No annotations are present to supplement.
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?
The description is a single, front-loaded sentence with no wasted words, effectively conveying the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's rich parameter descriptions and the presence of an output schema, the description covers the essential purpose and actions. However, it could briefly mention behavior for name generation or handling duplicates.
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?
The input schema already provides detailed descriptions for all parameters (e.g., color range, material type list). The description adds minimal extra meaning beyond restating the available types and color attribute.
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 description clearly states the tool creates a material (listing four specific types) with RGB color and assigns it to an object, distinguishing it from sibling tools like maya_create_light or maya_create_primitive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for material creation and assignment but lacks differentiation or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details fallback behavior for GLB/GLTF, special handling for BVH (pure-Python parser, HumanIK retarget), and explains namespace/scale_factor forwarding. It doesn't cover error conditions or undo behavior, but it provides substantial behavioral context.
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?
The description is front-loaded with the main purpose and options, then dives into technical details for specific formats. It is relatively concise given the complexity, though some redundancy exists (e.g., repeated mention of namespace/scale_factor in BVH section). Structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple file types with special import logic), the description covers key behaviors. It mentions output implicitly (e.g., BVH leads to HumanIK retarget) but does not discuss return values; however, an output schema exists. It could mention error handling or prerequisites, but overall it is sufficient.
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?
The description mentions namespace, parent group, and scale factor, adding some context (e.g., group_under created if not exists, BVH skeleton under bvh_grp). However, it does not thoroughly describe each parameter beyond what the input schema provides. The schema itself includes descriptions, so no major gaps.
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 description clearly states 'Import 3D files into Maya' and lists supported formats (OBJ, FBX, GLB/GLTF, Alembic ABC, Maya MA/MB, BVH mocap). This distinctively identifies the tool's action and resource, setting it apart from sibling tools like maya_create_primitive or maya_assign_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to import external 3D files) but does not explicitly state when not to use it or compare it to alternatives. It provides context for specific formats but lacks general usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the non-destructive nature (viewport grab, no Arnold render), instant execution, and return of an image. This provides adequate behavioral context for safe usage.
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?
The description is two sentences, front-loading the primary action and output. Every sentence adds value: first states what it does, second clarifies scope and use case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple capture tool with no output schema, the description covers purpose, speed, and usage scenarios. It could mention more about output characteristics or limitations, but overall it is sufficient given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers no parameter-specific guidance. While the input schema includes descriptions, the context indicates 0% schema description coverage, so the description should compensate. It does not mention any parameter constraints or usage tips.
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 description clearly states the verb 'capture' and the resource 'Maya viewport' with output format 'PNG/JPG image'. It distinguishes from sibling tools like Arnold render by noting it is an instant viewport grab, differentiating it from other Maya 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 provides clear usage context: 'verifying scene state, checking lighting, framing, and detecting issues'. It explicitly states what the tool does not do ('Does not do Arnold render') and gives a speed hint ('<1s'), guiding when to use it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the RAG technique, HyDE query expansion, and that results include relevance scores. It does not discuss side effects or rate limits, but such details are less critical for a search tool.
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?
The description is concise (four sentences), front-loaded with the core purpose, and each sentence adds distinct value (what, when, what covers, how). No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich input schema, the description covers the tool's overall role, supported content, and advanced technique. Minor gaps (e.g., parameter details) are mitigated by the schema, so completeness is high for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the tool description does not mention parameters. Although the input schema itself provides detailed parameter descriptions, the low coverage means the description must compensate; it fails to do so, leaving the agent without higher-level parameter semantics from the free text.
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 description clearly states 'Search Maya API documentation using hybrid RAG (semantic + BM25)' and lists covered domains (maya.cmds, PyMEL, etc.). It distinguishes from sibling tools that perform specific Maya actions by positioning itself as a preliminary research step.
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?
Explicit usage guidance is provided: 'Call this BEFORE writing complex Maya commands, using unfamiliar flags, or when unsure...' This helps the agent decide when to use it, though it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes full burden and discloses key behaviors: credit spending only with confirm=true, resumability via sidecar, that build runs in Maya, and draw_mode options. It could be improved by mentioning whether operations are destructive or reversible, but overall it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but verbose, containing several paragraphs and very detailed parameter lists. It is front-loaded with the purpose, but the length could be trimmed without losing essential information, making it less efficient for quick parsing.
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 dispatch tool with 7 actions and no annotations, the description is mostly complete for inputs but lacks details on outputs per action (e.g., poll returns). The presence of an output schema (not shown) may mitigate this, but the description does not reference it, leaving a gap for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic (only action and params as any), providing 0% coverage. The description fully compensates by listing all parameters for each action with types, examples, and optional flags, adding essential meaning beyond the schema.
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 description clearly states the tool's purpose: generating a World Labs Gaussian-splat environment from an image and loading it into Maya for Arnold. It distinguishes the tool from siblings by its specific pipeline of actions, and the name itself signals the domain.
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 provides a clear pipeline order (generate → poll → download → convert → build) and gives explicit guidance on credit spending and resuming interrupted runs via status. However, it does not compare directly to sibling tools or state when not to use it, though the specialized nature makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses model trust gates (only Opus/Fable write directly, others stage) and that patterns are available in future sessions. However, it does not mention any destructive effects or authentication requirements.
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?
Three sentences, front-loaded with purpose, then usage guidelines, then trust gates. No wasted words; each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool saves to a knowledge base and an output schema exists (though not shown in input), the description covers purpose, usage, and trust model. It could mention what happens after staging or if patterns can be overwritten, but overall sufficient for an AI agent.
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?
The input schema already provides clear descriptions for each parameter (api, code, description), so the tool description does not need to add parameter details. The description adds contextual usage info but no new parameter semantics.
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 description clearly states the tool saves a validated working pattern to the RAG knowledge base. It uses specific verbs ('Save', 'call') and identifies the resource, distinguishing it from sibling tools like search_maya_docs or Maya operation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use: after successful operation when search_maya_docs returned low relevance (< 60%). Also specifies alternatives (search_maya_docs) and trust gates for different model tiers, giving clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, describing output details like RAG savings compared to full documentation, implying a read-only statistics tool.
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?
Three concise sentences with front-loaded purpose, usage guidance, and output detail; no wasted words.
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?
Given zero parameters and presence of output schema, description fully covers when to use and what information is provided, including specific RAG comparison.
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?
No parameters, baseline 4. Description adds context about what statistics are displayed, compensating for lack of param info.
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 description clearly states the tool shows session efficiency statistics (token usage, RAG savings, patterns learned), distinguishing it from siblings like reset_session_stats and learn_pattern.
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?
Explicitly says to call at the end of multi-step tasks or when asked about efficiency, providing clear usage context, though it doesn't specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: read-only vs modifying, long-running ops, error conditions, and environment requirements (e.g., operation_history needs MAYA_AUDIT_LOG=1). It does not detail all failure modes but covers the key traits.
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?
The description is well-organized with a clear purpose statement followed by a bullet list of actions. Each action is described in 1-2 concise sentences, front-loading the overall task and avoiding unnecessary verbosity.
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?
Given the complexity (12 actions with varied parameters) and the presence of an output schema, the description covers all necessary details: action behaviors, parameter specs, constraints, and prerequisites. It is self-contained and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one generic parameter (params), with 0% description coverage. The tool description compensates by exhaustively documenting required and optional parameters for every action, including types, defaults, constraints, and specific usage instructions (e.g., out_path template).
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 description clearly states the tool manages Maya session, queries scene state, and runs utility commands. It lists 12 specific actions with detailed explanations, distinguishing itself from sibling tools that focus on specific operations like transforms or materials.
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 provides explicit guidance for each action, including when to use them and conditions (e.g., new_scene refuses unsaved changes). It does not explicitly compare to sibling tools, but the scope is clear: session-level and utility actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key traits: GPU requirement, no persistence (URL only in memory), non-blocking jobs. Missing details on error handling, whether it modifies the Maya scene, or output cleanup, but still highly informative.
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?
Well-structured with bullet points for each action and a clear workflow. Slightly verbose (multiple paragraphs) but earns its length by covering all necessary details.
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?
Covers the entire pipeline from server selection to download, including async behavior. No gaps in understanding how to use this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage (schema only defines dispatch structure), the description fully documents each action's parameters with examples (e.g., 'Required params: {"image_path": ...}'). Compensates completely for lack of schema detail.
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 description clearly identifies it as 'AI-powered 3D asset generation via Vision3D server' and lists all sub-actions (select_server, health, generate_image, etc.). Distinct from sibling Maya tools (e.g., maya_create_primitive) which focus on direct scene manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow: first select_server (ask user for URL), then start generation, poll, download. States 'jobs are non-blocking: start → poll → download' and provides required/optional params for each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses immediate zeroing, reset of counters, and return of confirmation timestamp. Missing explicit statement that it is destructive (clears data irreversibly), but 'Zero' sufficiently implies mutation.
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?
Three precise sentences front-loaded with the action. Every sentence earns its place: action, usage context, return value. No wasted words.
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?
Given zero parameters and output schema existence, description fully captures behavior: immediate reset, use case, and return value. Complements schema and context signals.
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?
No parameters; baseline 4 applies. Description adds no parameter info, but none is needed as the schema is empty and coverage is 100%.
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?
Description clearly states the action: 'Zero the session stats counters immediately.' It uses specific verb 'Zero' and resource 'session stats counters', distinguishing it from the sibling 'session_stats' which presumably reads stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'at the start of a new Claude session (or a fresh debugging run) when the idle-based auto-reset has not fired'. Provides a concrete example (back-to-back sessions) and contrasts with alternative behavior (auto-reset).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![maya-mcp MCP server](https://glama.ai/mcp/servers/abrahamADSK/maya-mcp/badges/card.svg)](https://glama.ai/mcp/servers/abrahamADSK/maya-mcp)

Score Badge

Copy to your README.md:

[![maya-mcp MCP server](https://glama.ai/mcp/servers/abrahamADSK/maya-mcp/badges/score.svg)](https://glama.ai/mcp/servers/abrahamADSK/maya-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/abrahamADSK/maya-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server