Computer Use

Overview Schema Source Related Servers Discussions Admin

Set field value

set_value

DestructiveIdempotent

Replace a text field's full contents via the accessibility API in one step, without keystrokes. Use for long values or fields that already contain text.

Instructions

Replace a text field's entire contents in one step through the accessibility API, without keystrokes. Prefer it over type_text for long values or when the field already holds text; fall back to click plus type_text if the field rejects it, which the result reports. The previous value is discarded.

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": {
      "element_id": "<element_id>",
      "value": "<value>"
    },
    "name": "set_value"
  }
}

Input Schema

Name	Required	Description
`value`	Yes	New complete value for the field
`element_id`	Yes	Text field to set, from get_app_state
`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
- addedInput schema / properties / element_id / description
```
Added value: +"Text field to set, from get_app_state"
```
- addedInput schema / properties / value / description
```
Added value: +"New complete value for the field"
```
First observedv0.3.0Sep 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description reinforces this by stating the previous value is discarded and that failures surface in the result, adding useful context beyond the annotation flags.

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 dense sentences with zero waste: purpose, routing rule, and the destructive caveat. Front-loaded and well ordered.

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 4-param mutation tool with full schema coverage and no output schema, the description covers purpose, alternatives, fallback behavior, and the destructive consequence. Nothing an agent needs to invoke it correctly is missing.

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 in the schema. The description adds no parameter-level detail beyond what the schema provides; baseline 3 is appropriate.

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?

States a specific verb+resource ('Replace a text field's entire contents') plus the mechanism ('through the accessibility API, without keystrokes'), which cleanly distinguishes it from the sibling type_text.

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?

Explicit routing: prefer over type_text for long values or pre-filled fields; fall back to click plus type_text if rejected, and it names where the rejection is reported ('which the result reports').

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