ReMCP

Find UI elements

ui_find

Read-onlyIdempotent

Use this when you need a small set of native UI elements by role/name/label/AutomationId after ui_snapshot. It requires an element criterion; use ui_snapshot, not an empty ui_find, to enumerate UI. Prefer returned id or compact label for subsequent ui_action; refresh only when the UI has changed.

Input Schema

Name	Required	Description
`id`	No	Element id returned by ui_snapshot or ui_find. Linux ids are stable per-process accessibility paths and legacy linux:<index> ids remain accepted.
`app`	No	Limit matching to an application/process name substring when available.
`pid`	No	Limit matching to one owning process id when available.
`name`	No	Accessible name/title substring.
`role`	No	Accessible role such as Button, Edit, textbox or AXButton.
`label`	No	Compact numeric label from the most recent ui_snapshot/ui_find; useful for repeated actions without repeating names or coordinates.
`limit`	No	Maximum matches; default 20.
`device`	Yes	ReMCP device id returned by list_devices. Required for every device operation.
`refresh`	No	Force a fresh accessibility capture instead of the short-lived snapshot cache.
`max_depth`	No	Maximum accessibility tree depth to traverse.
`max_nodes`	No	Maximum accessibility nodes to inspect or return; keep this bounded and raise it only when the target is missing.
`window_title`	No	Limit matching to a top-level accessibility window/frame title substring when available.
`automation_id`	No	Windows AutomationId when available.

Output Schema

Name	Required	Description	Default
`data`	No	Find UI elements structured result for ui_find. Stable fields are declared explicitly; platform-specific fields may be added. Large results may return truncated/bytes/preview instead of the full payload.
`text`	Yes	Concise human-readable result of the tool call.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 19, 2026
RemovedSep 21, 2026
First observedSep 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: ui_find requires an element criterion, operates over a snapshot cache, and should only be refreshed when the UI has changed, which goes beyond what the annotations state.

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, front-loaded with the primary use case, and every sentence earns its place by either stating scope, giving an exclusion, or providing downstream guidance. No filler.

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 the rich schema, output schema, and safety annotations, the description is complete enough for an agent to select and invoke the tool correctly. It covers scope, required criterion, relationship to sibling tools, and refresh behavior.

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 the baseline is 3. The description adds cross-tool guidance about preferring returned ids/labels for ui_action, but it does not meaningfully explain individual parameter semantics beyond the already-rich schema.

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: finding a small set of native UI elements by role/name/label/AutomationId. It also clearly differentiates this from ui_snapshot by emphasizing targeted lookup rather than enumeration.

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?

It gives explicit when-to-use guidance ('when you need a small set... after ui_snapshot'), an explicit exclusion ('use ui_snapshot, not an empty ui_find'), and cross-tool guidance for the next step ('prefer returned id or compact label for subsequent ui_action').

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

All ReMCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?