noracu

Overview Schema Source Related Servers Discussions Admin

mac_get

Read-onlyIdempotent

Reads a single accessibility element by element_index to return its role, title, value, states, and actions, so you can inspect long text or verify state before and after acting.

Instructions

Read one element live by element_index: role, title, description, value (up to max_chars, default 4000), frame, states (checked, selected, focused, disabled, expanded…), actions, settable attributes, help. Use it to read long text or to check a state before or after acting.

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>"
    },
    "name": "mac_get"
  }
}

Input Schema

Name	Required	Description	Default
`max_chars`	No
`snapshot_id`	No
`element_index`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.6Nov 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: the read is "live" rather than cached, and value text is truncated at max_chars with a 4000 default, which matters for callers retrieving 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with zero filler: the first front-loads the lookup key and the returned fields, the second front-loads the use cases. Nothing repeats the tool name or annotations.

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?

There is no output schema, so the enumeration of returned attributes does necessary work. The only meaningful gap is the undocumented snapshot_id, which interacts with the stated "live read" behavior and leaves an agent unable to reason about consistency.

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 carries the burden. It adequately explains element_index and gives real meaning for max_chars (truncation limit, default 4000), but snapshot_id is never mentioned, leaving unclear whether passing it changes the "live" read into a pinned-snapshot read.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource pair ("Read one element live by element_index") and then enumerates exactly what is returned: role, title, description, value, frame, states, actions, settable attributes, help. That is far more precise than its siblings' names imply, though it never explicitly contrasts itself with mac_find or mac_ax_state.

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

Usage Guidelines3/5

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

It offers two usage conditions: read long text, or check a state before/after acting. That is real when-to-use guidance, but no exclusion or explicit routing is given — an agent still cannot tell from this text why it should pick mac_get over mac_find or mac_ax_state.

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