Runs a Unity Editor menu item by its path, letting AI clients trigger editor actions such as exporting profiler capture stats without manual menu navigation.
Execute a Unity Editor menu item by path, e.g. 'Tools/Profiler/Export Capture Stats'.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and largely drops it: it says nothing about side effects, whether the menu action can be destructive or save files, whether execution is synchronous, what happens on an invalid path, or how failures surface. Only the example path implies the shape of a valid argument.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a concrete example; no filler, no repetition of structured fields. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers what the parameter is but not the operational contract: return values, error behavior on bad paths, and side-effect risk. Given the tool can trigger arbitrary editor actions, that gap matters more than it would for a read-only sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single `path` string, so the description must compensate. It does partially — the example 'Tools/Profiler/Export Capture Stats' shows the slash-delimited format — but says nothing about case sensitivity, how to discover valid paths, or whether the string is the literal Editor menu label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Execute a Unity Editor menu item by path') and supplies a concrete example path, so the agent knows exactly what invocation looks like. It does not, however, distinguish this tool from the siblings (unity_status, unity_console, unity_refresh), which are all read-style tools — the description never says this one mutates editor state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is given; the only hint is the example menu path. An agent must infer that this is for triggering editor commands that no other tool exposes, and gets no warning about preferring unity_status or unity_console for status/log reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.