mcp-for-maya

Overview Schema Source Related Servers Discussions Admin

Write Module

write_module

Destructive

Create a virtual Python module inside an Autodesk Maya session from supplied source code. Support dotted paths, automatic parent packages, and optional overwrite of existing modules.

Instructions

Create a virtual Python module in a Maya session.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	Python source code for the module.
`name`	Yes	Module name. Can be a dotted path (e.g., 'mypackage.utils') in which case parent packages are created automatically.
`overwrite`	No	If True, replace existing module. If False, raise error if module already exists.
`session_key`	No	Session key (optional if only one session exists)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 30, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the useful 'virtual' qualifier, implying the module does not persist to disk, which is genuine context not in the annotations. It does not state what overwrite destroys or how the module interacts with the session lifecycle.

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?

A single, front-loaded sentence with no filler or redundancy. It is efficient, though arguably too terse for a destructive write tool.

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?

An output schema exists, so return values need not be described, and annotations plus full schema coverage carry the mechanics. However, the description omits the execute_code boundary and any session prerequisite, which are the gaps an agent actually needs filled for this 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 description coverage is 100%, so name, code, overwrite, and session_key are fully documented in the schema including the dotted-path behavior and overwrite semantics. The description adds nothing beyond that, so the baseline 3 is correct.

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?

States a clear verb+resource: 'Create a virtual Python module in a Maya session.' An agent understands it defines in-memory Python code inside a session. It does not differentiate itself from the nearby execute_code sibling, which is the most likely point of confusion.

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 when-to-use guidance, no prerequisites, and no comparison to execute_code, which is the obvious alternative for injecting Python into a session. The agent must infer the distinction from the name alone.

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