Skip to main content
Glama
Sign In
noracu

noracu

by sgInnora
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

mac_wait

Read-onlyIdempotent

Wait for a macOS accessibility condition instead of sleeping by polling windows, text, elements, menus, sheets, app state, or notifications; returns the last observed state on timeout.

Instructions

Wait (instead of sleeping) until a condition holds, polling accessibility: window / window_gone (title substring, app), text / text_gone (in app's window), element (element_index + predicate exists|gone|enabled|focused|value_equals|value_contains, value), menu / menu_closed, sheet / sheet_gone (sheet, alert or dialog), app_running / app_gone, notification (a new one, optional app / text; refused under NORACU_READ_ONLY=1). For window_gone, text_gone, menu_closed and sheet_gone the app must be running when the wait starts (a misspelled or non-running app fails immediately with app_not_found). timeout_ms default 10000, max 30000; on timeout returns what it last saw.

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": {
      "condition": "<condition>"
    },
    "name": "mac_wait"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNo
textNo
exactNo
titleNo
valueNo
windowNo
conditionYes
predicateNo
timeout_msNo
snapshot_idNo
element_indexNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.6

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses timeout_ms default 10000 and max 30000, that a timeout returns the last observed state, that *_gone conditions fail immediately with app_not_found if the app is misspelled or not running, and that notification waits are refused under NORACU_READ_ONLY=1. These are exactly the failure modes and limits an agent needs before calling a blocking tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

No wasted words, and the core purpose is front-loaded, but the body is a single dense run-on of nested parentheses that makes it hard to scan for a specific condition. A short bulleted or sentence-per-condition layout would preserve the same information with far better structure.

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 an 11-parameter, no-output-schema tool, the description covers conditions, required companions, timeout bounds, and failure behavior. The weak spot is the return value: 'returns what it last saw' is the only clue about the response shape, and with no output schema that deserves one more concrete sentence, along with coverage of `exact` and `snapshot_id`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across 11 parameters, the description carries almost all semantic load and does so effectively: it maps each condition value to the parameters it requires (title/app for window, element_index + predicate + value for element, app/text for notification) and even enumerates predicate values exists|gone|enabled|focused|value_equals|value_contains that the schema leaves unconstrained. Gaps remain: `exact` and `snapshot_id` are never mentioned.

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?

States a specific verb and mechanism: 'Wait (instead of sleeping) until a condition holds, polling accessibility', then enumerates every supported condition type (window, text, element, menu, sheet, app_running, notification). An agent immediately knows this is a blocking poller and not a state reader. It never names a sibling such as mac_ax_state for a one-shot check, so sibling differentiation is left implicit.

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?

'instead of sleeping' is a real when-to-use hint, and 'refused under NORACU_READ_ONLY=1' is an explicit exclusion for the notification condition. However, there is no guidance on when to prefer a single mac_ax_state/mac_get read over waiting, nor on when a wait is likely to be flaky. Usage is strongly implied by the condition list rather than stated.

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