Loading ToolBench
A macOS UI automation server that provides tools to interact with application UIs through the Accessibility API. Automatically opens applications, retrieves UI element trees, clicks elements, and sets text in fields.
The Nudge Navigation Server defines 5 tools with explicit schemas and descriptions, but suffers from significant quality gaps. Tool naming is adequate but not verb-driven for all tools. Descriptions range from 82 - 189 chars (within baseline 10 - 1024 range) but lack critical operational detail, particularly what each tool returns, when to use it, and error recovery paths. Input schemas are present for all tools but lack output schema documentation. Parameters are minimally described. The server lacks per-parameter type information in descriptions (e.g., what format bundle_identifier expects, what element_id looks like after get_ui_elements returns it). No error handling guidance is provided. The 'agent_thought' parameter is non-standard and wastes schema real estate without adding agent value. Overall, this server is functional but falls well short of production-grade tool patterns.
Use this tool to ask user incase more context is required or there is confusion or the agent requires some confirmation etc.
Click a UI element by its ID using direct AXUIElement reference for maximum performance and reliability. Returns a struct that includes the status of the operation and a new ui tree with the original element at its root to help find any other specific elements if required.
Get UI elements for an application in a tree structure with limited depth (2-3 levels). Automatically opens the application if not running, brings it to focus, and fills ui_state_tree with elements from focused window and menu bar. Returns tree with only 3 fields: element_id, description, children. Use this function to get an overview of the application state and its UI elements
Use this tool to save any information that is required for later use by agent
Use this tool to write text into text boxes, url location, mail area, code editor etc. It returns the updated UI tree after writing the text
No output schemas documented for any tool. Tools return complex structures (UI trees, status structs, clipboard state) but clients have no schema to understand returned fields, types, or nesting. This forces LLMs to infer structure from examples or trial-and-error.
The 'agent_thought' parameter appears in all 5 tools. It is non-standard, serves no protocol function (it is purely for agent logging), and wastes schema space. This parameter should be removed from tool schemas, agent introspection is handled via system prompts or out-of-band logging, not as a required tool parameter.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 42 | <=2025-11-25 | v2 |
Parameter descriptions lack format, type, and constraint detail. E.g., 'bundle_identifier' is described as 'Bundle identifier of application (e.g., com.apple.safari for Safari)' but doesn't specify: Is it always reverse-DNS? Max length? Case sensitivity? What if the app is not installed? These details force LLMs to guess and agents to fail on malformed input.
Tool descriptions lack error recovery guidance. E.g., 'click_element_by_id' says what it does but not what happens on failure: Is element_id stale? Was the app backgrounded? Should the agent retry or call get_ui_elements again? Without explicit error guidance, LLMs retry blindly or give up.
'save_to_clipboard' and 'ask_user' lack operational semantics. save_to_clipboard doesn't explain retrieval mechanism (via clipboard tool? Via response field?). ask_user doesn't specify response format or timeout behavior. These ambiguities break agent planning, tools must communicate contract clearly so agents can compose them reliably.
Tool naming is inconsistent in verb-driven clarity. 'get_ui_elements', 'click_element_by_id', 'set_text_in_element' follow verb_noun. But 'save_to_clipboard' is verb_prep_noun (less standard), and 'ask_user' is vague (ask for what?). This inconsistency forces LLMs to reason harder about tool intent. Rename 'save_to_clipboard' → 'save_clipboard' or 'set_clipboard' and 'ask_user' → 'request_user_input' or 'prompt_user'.
No documentation of state mutations or idempotency. Is 'click_element_by_id' idempotent if called twice with the same element_id? Does 'set_text_in_element' replace or append text? Agents need to know which operations are safe to retry and which have side effects. This is missing from all write-category tools.