ReMCP

Type text

type_text

Destructive

Use this when the task calls for reliable Unicode text entry into a native semantic target or focused native control. Prefer method=auto so Accessibility is used when the target supports verified semantic editing. For Chromium page DOM, use browser_action instead of forcing desktop accessibility text input; auto fails safely when a semantic element rejects the write rather than claiming an unverified paste. Use method=keys only for deliberate physical key-by-key input, and keyboard for shortcuts/navigation/control keys.

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.
`text`	Yes	Text to enter.
`clear`	No	Replace existing text for semantic/window-scoped accessibility input, or clear it before keyboard/paste fallback.
`label`	No	Compact numeric label from the most recent ui_snapshot/ui_find; useful for repeated actions without repeating names or coordinates.
`title`	No	Optional target window title substring. With auto/accessibility + clear=true, a unique editable control may be updated semantically without compositor focus.
`device`	Yes	ReMCP device id returned by list_devices. Required for every device operation.
`method`	No	Default auto prefers verified accessibility editing and falls back to clipboard paste. keys sends physical key events and therefore follows the active keyboard layout.
`backend`	No	Input backend preference. auto uses proven local backends and already-authorized portal input; portal explicitly requests XDG RemoteDesktop consent on Wayland; x11 forces XWayland/xdotool only for operations where read-back testing shows it is reliable. GNOME Wayland keyboard/text deliberately reject x11.
`delay_ms`	No	Per-key delay for method=keys.
`window_id`	No	Optional target window id. With auto/accessibility + clear=true, a unique editable control may be updated semantically without focus; keyboard/clipboard fallbacks verify focus before dispatch.
`press_enter`	No	Press Enter after typing; physical Enter delivery requires verified window focus.
`window_title`	No	Limit matching to a top-level accessibility window/frame title substring when available.
`automation_id`	No	Windows AutomationId when available.
`caret_position`	No	Where text insertion should occur when the semantic editor supports caret placement.

Output Schema

Name	Required	Description	Default
`data`	No	Type text structured result for type_text. 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

Changed4 schema fields changedSep 21, 2026

changedInput schema / properties / clear / description

Previous value: -"Clear existing text before input when keyboard/paste fallback is used."New value: +"Replace existing text for semantic/window-scoped accessibility input, or clear it before keyboard/paste fallback."

changedInput schema / properties / press_enter / description

Previous value: -"Press Enter after typing."New value: +"Press Enter after typing; physical Enter delivery requires verified window focus."

changedInput schema / properties / title / description

Previous value: -"Optional target window title substring; focused before input when no semantic element target is supplied."New value: +"Optional target window title substring. With auto/accessibility + clear=true, a unique editable control may be updated semantically without compositor focus."

changedInput schema / properties / window_id / description

Previous value: -"Optional target window id; the window is focused before auto/accessibility/clipboard/keys input and Wayland verifies focus before dispatch."New value: +"Optional target window id. With auto/accessibility + clear=true, a unique editable control may be updated semantically without focus; keyboard/clipboard fallbacks verify focus before dispatch."

Changed3 schema fields changedSep 21, 2026

changedInput schema / properties / method / description

Previous value: -"Text-entry strategy. auto is recommended; accessibility is semantic, clipboard preserves Unicode, and keys emits physical key events whose printable characters follow the computer current keyboard layout."New value: +"Default auto prefers verified accessibility editing and falls back to clipboard paste. keys sends physical key events and therefore follows the active keyboard layout."

changedInput schema / properties / title / description

Previous value: -"Optional target window title substring for clipboard/keys methods."New value: +"Optional target window title substring; focused before input when no semantic element target is supplied."

changedInput schema / properties / window_id / description

Previous value: -"Optional XWayland target window id for clipboard/keys methods."New value: +"Optional target window id; the window is focused before auto/accessibility/clipboard/keys input and Wayland verifies focus before dispatch."

First observedSep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses fallback behavior (accessibility → clipboard), failure semantics (auto fails safely instead of claiming an unverified paste), and the physical-key implication of method=keys. This goes beyond the annotations, which already mark the operation as destructive, without contradicting them.

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?

Four dense, purposeful sentences front-load the main use case and then method and sibling routing. There is no filler or repetition of schema content.

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?

With 18 parameters, an existing output schema, and a fully described input schema, the description covers the critical route/branch decisions and failure modes. It does not walk through every parameter, but the schema and annotations fill those gaps; the only minor omission is not explicitly calling out the destructive clear behavior.

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 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining method selection rationale and when method=keys is appropriate, which helps an agent pick values correctly.

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 names a specific verb and resource ('reliable Unicode text entry into a native semantic target or focused native control') and distinguishes itself from browser_action and keyboard. This makes the tool's scope clear without opening the schema.

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 explicitly states when to use the tool, when to prefer method=auto, when to use browser_action for Chromium DOM instead, and when to fall back to method=keys or the keyboard sibling. This is concrete routing guidance rather than vague context.

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?