Skip to main content
Glama
Sign In
mcp-for-maya

mcp-for-maya

by Xxx91n
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Maya Setup Guide

maya_setup_guide
Destructive

Diagnose and repair Maya MCP connection problems, auto-install userSetup.py, and provide step-by-step setup guidance for first-time setup or empty session lists.

Instructions

Maya connection setup guide and diagnostics.

Boundary: Disambiguated from list_sessions (read the current session set) and add_session (attach a host:port you already know) — maya_setup_guide diagnoses and repairs the connection itself.

Use this tool when list_sessions returns empty or when setting up Maya MCP for the first time. Provides platform-aware diagnostics, auto-installation of userSetup.py, and step-by-step fallback instructions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "maya_setup_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNoMaya command port number (default: 7001)
actionNoWhat to do: - "diagnose": Run connection diagnostics and return status - "install": Merge the managed marker block into userSetup.py. Existing files without the block require a second call with confirm=True (the first call returns the proposed block). - "guide": Get full step-by-step connection guide - "uninstall": Remove the managed marker block from userSetup.pydiagnose
confirmNoRequired to write into an existing userSetup.py that has no mcp-for-maya marker block (first install call is dry-run).
dry_runNoPreview the install: return the proposed block without writing anything.
target_versionNoSpecific Maya version (e.g., "2024"). If None, targets all detected versions.
remove_empty_fileNoOn uninstall, delete the file when it only contained the marker block.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety bar is lower. The description adds that the tool auto-installs userSetup.py and that it 'repairs' the connection, which signals mutation beyond the annotations. However, it never states that files are written to the user's Maya scripts directory, that uninstall can remove blocks, or what a failed repair leaves behind — leaving the destructive surface only partly explained.

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?

Front-loaded with the core purpose, then a boundary paragraph, then usage triggers — good ordering with no filler. Slightly redundant phrasing ('diagnoses and repairs the connection itself' restates the first line) keeps it from a 5.

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?

An output schema exists, so return values need not be described, and the six parameters are fully documented in the schema. What remains thin is behavioral risk: for a destructive, file-writing tool, it does not say where files are modified or how to recover, which an agent may want before calling action='uninstall'.

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 description coverage is 100%, so per-parameter meaning (action modes, confirm dry-run semantics, dry_run preview, target_version scoping) is fully documented in the schema. The description adds no parameter-level detail beyond what the schema already provides, so baseline 3 applies.

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?

States a specific resource (Maya connection setup) and specific capabilities (diagnostics, userSetup.py installation, step-by-step guide). The boundary paragraph explicitly names list_sessions and add_session and explains the distinction, so an agent can route correctly without opening other schemas.

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?

Gives concrete triggers — 'when list_sessions returns empty' or 'setting up Maya MCP for the first time' — and names the alternative tools with the condition that selects them (list_sessions to read sessions, add_session when host:port is already known).

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

Deploy Server

Other Tools