noracu

Overview Schema Source Related Servers Discussions Admin

mac_set_value

Idempotent

Set an accessibility element's value by index for text fields, checkboxes, tabs, menus, and sliders—no pointer input, with read-back verification.

Instructions

Set an element's value by element_index, by role: text fields (whole value; AXSecureTextField never echoes the value), checkboxes / switches / radio buttons (true|false, idempotent: nothing sent when already so; a mixed checkbox is pressed up to twice until it reaches the requested state), disclosure triangles and expandable rows (true|false), rows / cells / tabs (true selects), pop-up buttons, menu buttons and combo boxes (an option's title: opens the menu, picks the one matching option, closes it again if none or several match), sliders / steppers (a number within min-max). Semantic only (no pointer). delivered_verified only when the value read back changed to the one asked for (text: line endings and outer white space aside); a field already at that value gets nothing sent (not_delivered, already).

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_index": "<element_index>",
      "value": "<value>"
    },
    "name": "mac_set_value"
  }
}

Input Schema

Name	Required	Description	Default
`value`	Yes
`timeout_ms`	No
`snapshot_id`	No
`element_index`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.6Nov 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare idempotent/non-destructive/open-world, but the description goes much further: nothing is sent when the value is already correct, a mixed checkbox may be pressed up to twice, menu buttons open/pick/close and may pick nothing when zero or several options match, and AXSecureTextField never echoes values. It also defines the delivery outcome vocabulary (delivered_verified, not_delivered, already) and the read-back verification rule, which is behavior no structured field carries.

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 key caveat (semantic only, no pointer) are front-loaded, and nearly every clause carries distinct operational information. The trade-off is density: it reads as one long string of nested parentheticals, which makes the delivery/verification semantics easy to miss on a first pass.

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 four-parameter mutation tool with no output schema and no schema descriptions, the definition covers the risky parts well: value coercion per role, idempotency, partial-delivery semantics and read-back verification. The remaining gap is provenance of element_index/snapshot_id and timeout behavior, which an agent needs to call the tool successfully.

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 description coverage is 0%, so the description must carry parameter meaning, and it does so thoroughly for `value` (per-role formats: true|false, option title, number within min-max). However, `element_index`, `snapshot_id` and `timeout_ms` are never explained — notably there is no hint that the index comes from a snapshot or find call, leaving half the parameters undocumented everywhere.

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 precise verb+resource ('Set an element's value by element_index') and then enumerates the role-specific meaning of that operation for text fields, checkboxes, disclosure triangles, rows/cells/tabs, pop-up buttons and sliders. This clearly separates it from typing tools like mac_type/mac_key and from pointer siblings like mac_click, since it explicitly says 'Semantic only (no pointer)'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The role enumeration effectively tells the agent which widget types this tool covers and implicitly which it does not, and 'Semantic only (no pointer)' excludes it from click/drag scenarios. There is no explicit 'use X instead' routing to mac_type, mac_click or mac_find, and no mention of how to obtain a valid element_index, so it stops short of full when/when-not guidance.

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