Skip to main content
Glama

Execute Python

execute_python

Run arbitrary Python code inside Autodesk Maya when built-in tools fall short. Supports timeouts, undo chunks, and persistent namespaces for later calls.

Instructions

Run arbitrary Python inside Maya (escape hatch).

WARNING: this is NOT a security sandbox. It can read/write files and run system commands. Destructive patterns require allow_dangerous=True.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesPython source to run inside Maya. End with a bare expression to return a value.
undoNoWrap execution in a single undo chunk (default True).
timeout_sNoTimeout in seconds (1-3600).
persistentNoKeep variables in a session-scoped namespace for later calls.
session_keyNoTarget Maya session; omit if only one is connected.
namespace_keyNoNamespace name used when persistent is True.default
allow_dangerousNoAllow patterns like os.system/subprocess/file deletion. NOT a sandbox.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does meaningful work: it explicitly warns there is no security sandbox, that files and system commands are reachable, and that destructive patterns are gated behind allow_dangerous=True. It does not cover the default undo wrapping or timeout behavior, but the safety profile is unusually well disclosed.

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 short sentences, zero filler, and the critical safety warning is front-loaded immediately after the one-line purpose. Nothing here could be cut without losing necessary 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?

An output schema exists, so return-value explanation is unnecessary, and the schema covers session/namespace/timeout mechanics. The remaining gap is the absence of any statement about when this tool should be chosen over its typed siblings, but for a dangerous escape-hatch tool the safety disclosure is complete.

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 coverage is 100%, so all seven parameters are already documented, including code, undo, timeout_s, persistent, namespace_key, and allow_dangerous. The description only reinforces the meaning of allow_dangerous; the baseline 3 applies when the schema does the heavy lifting.

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 and resource (run arbitrary Python inside Maya) and labels itself an 'escape hatch', which implicitly separates it from the typed siblings like rename_object, set_attributes, or execute_mel. An agent can immediately tell this is the fallback for operations no dedicated tool covers.

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 'escape hatch' framing implies this is the last resort rather than the first choice, but it never says when to prefer it over execute_mel or the typed tools, nor when not to reach for it. Usage is implied rather than stated.

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