mcp-for-maya

Overview Schema Source Related Servers Discussions Admin

Write Module

write_module

Destructive

Create reusable Python modules in an active Maya session by injecting in-memory functions into sys.modules, enabling agents to define helper libraries that persist during the session.

Instructions

Create a virtual in-memory Python module in an active Maya session.

Injects reusable Python functions into the target Maya session's sys.modules. Modules are virtual and in-memory: they do not persist across Maya restarts, and existing modules are protected unless overwrite=True is explicitly set. Requires an active Maya session.

Boundary: Use write_module to define reusable libraries and helper functions; use execute_code for one-shot imperative execution or expression evaluation.

Input 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, overwrite and replace existing module. If False, raise error if module already exists.
`session_key`	No	Maya session key (optional if only one active session exists).

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Oct 1, 2026

changedInput schema / properties / overwrite / description

Previous value: -"If True, replace existing module. If False, raise error\n       if module already exists."New value: +"If True, overwrite and replace existing module. If False,\n       raise error if module already exists."

changedInput schema / properties / session_key / description

Previous value: -"Session key (optional if only one session exists)"New value: +"Maya session key (optional if only one active session exists)."

First observedv0.4.1Sep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive=true and idempotent=false, but the description adds substantial context beyond them: modules are in-memory and do not persist across restarts, existing modules are protected unless overwrite=True, and injection targets sys.modules. This is exactly the kind of non-obvious behavior an agent needs before a destructive write.

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 front-loaded with the core action first, then constraints, then a boundary statement. Slight redundancy between 'in-memory' in the opening sentence and 'virtual and in-memory' in the third, but overall tight and scannable.

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?

For a destructive session-scoped write tool, the description covers persistence, overwrite protection, auth/session requirement, and sibling routing, and an output schema exists so return values need not be explained. Nothing essential is missing.

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 all four parameters (including overwrite semantics and dotted-path names) are already documented. The description restates overwrite behavior but adds no new syntax or format detail beyond the schema, which is the correct baseline-3 case.

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 verb+resource: 'Create a virtual in-memory Python module' and clarifies it injects functions into sys.modules. The boundary paragraph explicitly distinguishes it from execute_code, so an agent can route without opening 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?

Explicit when-to-use ('define reusable libraries and helper functions') vs alternative ('execute_code for one-shot imperative execution or expression evaluation'). Also states the prerequisite of an active Maya session.

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