UnityMCP

Overview Schema Source Related Servers Discussions Admin

simulate_click

Clicks a Unity UI node by panel UID plus ref key or path, using raycast hit-testing to confirm the target is topmost, or force mode to fire the handler directly when hit-testing fails.

Instructions

simulate_click tool. Write op. Clicks a UI node via PROJECT_UI's own simulate API.

Main path (no real input device, no screen coordinate): resolves the node by panel uid + refKey (panel PROJECT_NODE_REFERENCE key) OR path (transform path under the panel root), then calls:

mode='raycast' (default): PROJECT_CLICKABLE:PROJECT_CLICK_WITH_HIT_TEST(false) — raycasts at the node's screen point and only fires if it's the topmost/visible hit; returns whether it actually clicked (self-validating occlusion check).
mode='force': PROJECT_CLICKABLE:PROJECT_CLICK_DIRECT(false) — fires the handler with no hit-test (use when the node is known-good but raycast fails, e.g. off-screen).

PlayMode-only. Device-pixel clicking (screenXY via InputSystem.QueueStateEvent) is deferred to a later phase.

FINAL-VERIFICATION ROLE: when the user described repro steps, drive the same clicks here during final verification instead of calling internal handlers that bypass the input path; then capture_screenshot to evidence the result.

Input Schema

Name	Required	Default
`mode`	No	raycast
`path`	No
`ref_key`	No
`panel_uid`	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.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that this is a write operation, PlayMode-only, that raycast mode performs an occlusion/hit-test and self-validates whether a click occurred, and that force mode bypasses hit-testing; it also notes device-pixel clicking is deferred.

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?

The description is front-loaded with the operation and main path, then organized by mode and final-verification role. It is dense rather than padded, though some placeholder-style wording and long clauses make it slightly heavier than necessary.

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?

Given the complexity, lack of annotations, and presence of an output schema, the description provides enough operational context to call the tool correctly. It does not fully clarify whether ref_key or path must be supplied alongside panel_uid, but the core execution model and constraints are covered.

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?

Schema coverage is 0%, so the description must compensate, and it explains ref_key as the panel PROJECT_NODE_REFERENCE key, path as a transform path under the panel root, and mode as raycast vs force with behavior differences. The required panel_uid parameter is used but not explicitly defined, which keeps this below a perfect score.

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?

The description states a specific verb and resource: it clicks a UI node through PROJECT_UI's own simulate API. It also distinguishes the two execution paths, raycast and force, so an agent can tell exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage conditions: raycast is default, force is for known-good nodes where raycast fails such as off-screen nodes, and it should be used during final verification instead of internal handlers. It does not explicitly compare against nearby siblings like simulate_key or escalate_via_click, leaving some alternative-selection guidance implicit.

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