Skip to main content
Glama
bigduu

Nova

by bigduu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

read_ui

Read numbered UI controls and text from macOS windows or web pages via the accessibility tree, returning elements you can click by mark.

Instructions

Compatibility alias for ax_read, backed by the exact same semantic traversal, renderer, snapshot generation, and action cache. Prefer the canonical ax_read name in new prompts and integrations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxNoCap on the number of elements returned (default 200, max 400).
modeNo`interactive` returns actionable controls, `content` returns readable labels/text, and `all` combines both in deterministic tree order. Defaults to `all`.
filterNoShow only elements whose role, label, or value contains this case-insensitive substring (e.g. "button", "search", "submit"). Omit to list everything. Filtering only narrows the DISPLAY — the hidden elements keep their numbers and stay clickable by click_mark(N).
targetNo`native` (default) reads AX/UIA. `paired_page` reads only the already consented Chrome document; mutually exclusive with `window`.
windowNoTarget a single on-screen window: a case-insensitive substring of its title or app name (e.g. "Safari", "Settings"). Omit to read the current target app — the last window-captured or read_ui'd app, otherwise the frontmost. Web-page content is included either way (as long as the app has a window); a window= just narrows and sharpens the listing to that window.
max_charsNoUnicode-character output budget (default 30000, max 100000). If hit, `truncated=true` and `partial_reason=character_limit` are returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden, and it does add real value by guaranteeing behavioral equivalence to ax_read including the shared action cache. It does not mention safety profile (read-only vs mutating), side effects such as resetting the 'current target app' state implied by the window/target params, or output shape, leaving meaningful behavioral gaps.

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 tight sentences, zero padding, and the most important information (it is an alias for ax_read) is front-loaded before the migration advice.

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 pure alias whose behavior is fully delegated to a named sibling and whose parameters are 100% documented in-schema, the description covers what an agent needs to select and call it. The absence of any return-value or side-effect note is a minor gap with no output schema present to compensate.

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 100% across all six parameters, with detailed inline docs for max, mode, filter, target, window, and max_chars. The description adds no parameter meaning beyond that, so the baseline 3 is appropriate.

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 identifies the tool as a compatibility alias of ax_read and lists what it shares (semantic traversal, renderer, snapshot generation, action cache), which lets an agent equate it with a sibling it likely already knows. However, it never plainly states the verb+resource itself (reading the accessibility/UI tree), so an agent unfamiliar with ax_read gets no direct statement of the action.

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?

It explicitly directs the agent to prefer the canonical ax_read name in new prompts and integrations, which functions as a clear when-to-use-this-vs-alternative rule. It stops short of stating the inverse condition (when this alias is actually required, e.g. legacy integrations), but the routing decision is unmistakable.

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