Computer Use

Overview Schema Source Related Servers Discussions Admin

Type text

type_text

Destructive

Types literal characters as keystrokes into the focused field, optionally focusing a target element first. Use for short entries or fields that reject value setting; inserts at the caret.

Instructions

Type literal text as keystrokes into the field that currently has focus, optionally focusing element_id first. Use it for short entries and for fields that reject set_value; use set_value to replace a long value in one step, and press_key for shortcuts or keys such as return and tab. Never use it for a Chrome tab the agent works in (it goes to whichever Chrome window is in front, which can be the user's); use browser_type or browser_fill there. Text is inserted at the caret without clearing what is already there. It does not take over the user's keyboard: on macOS and Windows the text goes to the app you are working in, not the window the user is typing in, so do not call activate_app first. Typing into password fields is refused by default (see COMPUTER_USE_ALLOW_SECURE_FIELD_INPUT).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "type_text"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Exact text to type, character by character
`element_id`	No	Element to focus before typing, from get_app_state. Omit to type into whatever currently has focus.
`state_query`	No	With return_state, list only elements whose role, label or value contains this text, like get_app_state's query
`return_state`	No	After acting, wait for the app to finish reacting (up to 2 s) and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.1Oct 15, 2026

changedInput schema / properties / return_state / description

Previous value: -"After acting, wait briefly for the UI to settle and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id."New value: +"After acting, wait for the app to finish reacting (up to 2 s) and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id."

Changed2 schema fields changedv0.5.2Sep 30, 2026

addedInput schema / properties / return_state

Added value: +{
+  "description": "After acting, wait briefly for the UI to settle and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id.",
+  "type": "boolean"
+}

addedInput schema / properties / state_query

Added value: +{
+  "description": "With return_state, list only elements whose role, label or value contains this text, like get_app_state's query",
+  "type": "string"
+}

Changed2 schema fields changedv0.3.1Sep 16, 2026

changedInput schema / properties / element_id / description

Previous value: -"Focus this element before typing"New value: +"Element to focus before typing, from get_app_state. Omit to type into whatever currently has focus."

addedInput schema / properties / text / description

Added value: +"Exact text to type, character by character"

First observedv0.3.0Sep 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the annotations (non-readonly, destructive, non-idempotent), it discloses that text is inserted at the caret without clearing existing content, that input is routed to the app being worked in rather than the user's foreground window, and that password fields are refused unless COMPUTER_USE_ALLOW_SECURE_FIELD_INPUT is set. These are genuinely useful behavioral facts not derivable from annotations; it stops short of covering pacing or partial-failure behavior during long strings.

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 core action is front-loaded in the first clause and subsequent sentences are routing and constraint information rather than filler. It is somewhat dense with three alternative-tool mentions in one sentence, but each clause carries distinct decision value.

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?

For a four-parameter input mutation tool with no output schema, the description covers scope, alternatives, side effects on existing text, focus routing, and the secure-field policy. An agent has everything needed to call it correctly on the first attempt.

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 coverage is 100%, so all four parameters are already documented. The description only restates the element_id focusing behavior and says nothing about state_query or return_state, so it adds little beyond the schema — the baseline 3 applies.

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 gives a precise verb and target: 'Type literal text as keystrokes into the field that currently has focus', plus the optional element_id focusing step. It clearly separates the tool from set_value (bulk replacement), press_key (shortcuts), and browser_type/browser_fill (Chrome automation), so an agent can identify it without consulting sibling schemas.

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 specifies exactly when to use it (short entries, fields that reject set_value) and when not to (Chrome tabs the agent works in) with named alternatives for each case. It also states the prerequisite behavior around activate_app and the secure-field refusal, leaving nothing to inference.

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