Skip to main content
Glama
Sign In
OpenCU

OpenCU

by Daily-AC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_value

Sets a value on an explicitly settable accessibility element, then returns updated app state so agents can verify the result before further input.

Instructions

Set a value only on an element explicitly marked settable in the current tree, then return app state. Use click for buttons and checkboxes. In a locked-parent Windows agent desktop this requires ValuePattern; RangeValue is not available there. Verify the resulting value; web application input handlers may behave differently from typing or pasting. Returns the updated accessibility state after the action; a separate text-only get_app_state is normally unnecessary. Request a new screenshot before later coordinate 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": {
      "app": "<app>",
      "element_index": "<element_index>",
      "value": "<value>"
    },
    "name": "set_value"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesApp name or full app path; macOS bundle ID; macOS and Windows pid:<pid>; Windows process name, window title fragment, or Start-menu shortcut name; Linux desktop entry name, executable name or window title fragment
scopeNomacOS and Windows: element index from the latest returned state. Read only its retained subtree, renumbered from [1], including after actions. If it disappears, return the whole window with a notice. Linux returns INVALID_ARGUMENT.
valueYes
element_indexYesElement index from the latest returned app state

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint=false / openWorldHint=true annotations, it discloses platform-specific mechanics (locked-parent Windows desktops require ValuePattern; RangeValue is unavailable), a verification duty, and a caveat that web input handlers may behave differently than typing or pasting. That is meaningful behavioral context the annotations cannot express.

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?

Purpose and the settable-element constraint are front-loaded, and every clause carries operational information. It is dense rather than bloated, though six sentences of caveats could be compressed slightly for faster scanning.

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?

For a mutating tool with no output schema, it explains the return (updated accessibility state), prerequisites, and verification. The main residual gap is that the nature of the value being set (plain text? formatted?) is never characterized, which matters for a write operation.

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 75%, so app and scope are already documented at the schema level. The description adds only an implicit constraint on element_index (it must reference a settable element) and says nothing about value's expected format or about scope's retained-subtree behavior, leaving the schema to carry the load.

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 opening sentence states a specific verb (set) plus resource (a value on an element) and adds a decisive scope constraint: only elements explicitly marked settable in the current tree. It also returns the app state, and it distinguishes itself immediately from click/paste/type_text by pointing at buttons and checkboxes as a different route.

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 routes the agent elsewhere ("Use click for buttons and checkboxes") and rules out a redundant follow-up ("a separate text-only get_app_state is normally unnecessary"). It also gives a sequencing rule ("Request a new screenshot before later coordinate input"), so both when-to-use and when-not-to-use are covered.

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

Deploy Server

Other Tools