ReMCP

Ui Toggle

ui_toggle

Destructive

Use this to activate an identified native checkbox or switch using its accessibility semantics. Check the present state before toggling; this can change saved settings.

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.
`device`	Yes	ReMCP device id returned by list_devices. Required for every device operation.
`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	Act on UI element structured result for ui_action. 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

TDQS

A3.6/5.0

Behavior3/5

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

It adds valuable context that this action 'can change saved settings.' While the annotation confirms it is not read-only, this description adds the crucial behavioral detail that the action is persistent and meaningful beyond just the immediate UI 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?

The definition is extremely brief and highly efficient, front-loading the core functionality and the most critical warning about state change in a single, focused statement.

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 rich input schema and annotations, the description is quite complete. It covers the core function, the 'why' (native/accessibility), and the consequence of the action (saved settings), leaving no major gaps.

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?

With 100% schema description coverage, the baseline for this dimension is 3. The description does not add significant semantic value to the 9 parameters, relying on the input schema for detailed definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It clearly states the tool's purpose: activating a native checkbox or switch using its accessibility semantics. The use of 'native' and 'accessibility semantics' distinguishes it from more generic interaction tools like ui_click.

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 description includes a helpful guideline to 'check the present state before toggling,' which informs the user workflow. However, it does not explicitly state when to use this tool over alternatives like ui_set_value or ui_click.

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?