UnityMCP

Overview Schema Source Related Servers Discussions Admin

simulate_key

Triggers a Unity input action by its action path, replaying key or gamepad presses even when the Game view is not focused; use it to verify input-driven features in Play Mode.

Instructions

simulate_key tool. Write op. Triggers an input ACTION by its action path.

Calls PROJECT_RUNTIME.global.PROJECT_INPUT_SERVICE:PROJECT_TRIGGER_ACTION(actionPath, 'Performed') then 'Canceled' — this routes through the game's InnerHandleInputInfo funnel exactly like real input, but bypasses the focus / inputEnabled gate, so it works even when the Editor Game view isn't focused. Use for "press the key bound to feature X" (e.g. "Hud/OpenMap", "Player/Jump").

IMPORTANT — only REAL InputActionAsset actions can be triggered this way. Virtual PROJECT_HOTKEY_SYSTEM bindings (isVirtual=true, driven by PROJECT_HOTKEY_CALLBACK — most panel hotkeys like "Common/ClosePanelCommon") are NOT in playerInput.actions, so this returns triggered=false with a note. For those, use simulate_click on the bound button, or lua_eval the panel method.

Device-level raw keystrokes (InputSystem.QueueStateEvent on Keyboard) are deferred to a later phase. PlayMode-only.

FINAL-VERIFICATION ROLE: when the user gave repro steps involving key/gamepad presses, replay them here during final verification, then capture_screenshot to evidence the outcome. (Reaches only real InputActionAsset actions — for virtual PROJECT_HOTKEY_SYSTEM hotkeys use simulate_click on the bound button.)

Input Schema

Name	Required	Description	Default
`action_path`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Oct 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does: it declares this is a write op, discloses that it bypasses the focus/inputEnabled gate so it works when the Game view isn't focused, notes that virtual hotkey bindings silently return triggered=false with a note rather than firing, and flags PlayMode-only and deferred raw keystroke support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical facts are front-loaded and the structure is logical, but the virtual-hotkey caveat is repeated three times (main body, the IMPORTANT paragraph, and again in FINAL-VERIFICATION ROLE). The final paragraph is largely redundant with earlier content.

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?

Given a mutation-style tool with no annotations and a single opaque parameter, the description covers the mechanism, preconditions, failure mode (triggered=false for virtual actions), and how it fits a verification workflow with capture_screenshot. An output schema exists, so return-value detail is unnecessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single action_path parameter has 0% schema description coverage, so the description must compensate. It does partially: it explains that the path refers to a real InputActionAsset action and gives two example path strings ('Hud/OpenMap', 'Player/Jump'), but never spells out the path format or where valid paths can be discovered.

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: 'Triggers an input ACTION by its action path', and explains the mechanism (PROJECT_TRIGGER_ACTION with 'Performed' then 'Canceled' through InnerHandleInputInfo). It is clearly distinguished from sibling simulate_click, lua_eval, and set_input_text by naming the exact action kinds it handles.

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 ('press the key bound to feature X', with concrete paths like 'Hud/OpenMap', 'Player/Jump') and explicit when-not-to-use with named alternatives: virtual PROJECT_HOTKEY_SYSTEM bindings require simulate_click on the bound button or lua_eval of the panel method. It also states the PlayMode-only precondition.

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