Loading ToolBench
Model Context Protocol server for AOM (App Observation & Manipulation) - provides tools for launching, attaching to, and analyzing Electron applications with UI inspection, capability invocation, and context window management
AOM MCP server defines 15 tools with explicit schemas and descriptions. Naming follows verb_noun convention (launch_for_handoff, attach_existing, invoke_capability). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool, which is excellent for LLM selection. However, parameter descriptions are verbose and sometimes redundant (e.g., 'Active AOM session id' repeated 12 times). Input schemas are present but lack explicit type constraints (enums, min/max bounds). Output schemas are not documented, LLMs cannot predict return structure. Error handling is absent: no guidance on retryability, recovery steps, or actionable error messages. Security: sessionId is passed as a parameter (should be server-side injected or managed via context). Tool composition is strong, tools chain well (route_context → context_windows → invoke_capability), but some tools overlap in purpose (context_pack vs context_windows, context_window vs context_windows).
Debug/explanation tool: return the full current AOM graph from AnalysisService. Prefer route_context/context_windows for normal operation. Use analysis_graph for subgraph debugging, evidence tracing, or validator failures. Do not choose executable targets from graph text alone; use invoke_capability or graph-backed invoke_view.
Attach to an already-running debuggable app by CDP URL without owning or closing it. Returns compact readiness/analysis summary only; call aom.call_chain or aom.route_context for planning. After attach, use aom.context_windows to inspect the UI/data-flow/capability regions the agent chooses. Do not relaunch or close a user-owned app through AOM.
Return only AOM's current dynamic tool-call chain recommendation. This tool does not execute anything and does not hide other AOM tools; it only proposes the next small sequence. Call it after every meaningful tool result before continuing autonomous work, because every invoke/route/window call can change the best chain. If the chain starts with invoke_* and that call verifies an effect, regenerate the chain instead of repeating prior actions. Use this when the agent is looping, unsure whether to inspect context_windows or invoke a capability/view, or choosing the next tool.
List current executable capabilities and risk metadata. Prefer invoking by stable capability name when possible, because LLM-generated ids may include current view ids and can become stale after UI changes. If a capability disappears or becomes unknown, call route_context and inspect current targets with context_windows before retrying.
Output schemas not documented. LLMs cannot predict return structure (fields, types, pagination). Tools like context_windows, route_context, and invoke_capability return complex nested objects but provide no schema documentation.
No error handling guidance. Tools lack recovery hints, retryability classification, or actionable error messages. E.g., if invoke_capability fails, LLM has no guidance on whether to retry, inspect context_windows, or call call_chain.
sessionId passed as parameter instead of server-side injected. Credentials/session tokens should never appear in tool parameters, they leak into logs and traces. sessionId should be managed by the MCP server context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Return the latest semantic context diff for a session. Use this after invoke_capability/invoke_view when the action result was too large or when you need to know what changed. The delta preserves causal evidence: changed UI nodes, network endpoints, data-flow edges, capability changes, outcome status, and recommended next actions. For search tasks, if outcome.status is verified and nextStepHint says results loaded, stop repeating search and invoke one recommendedTargets entry.
Legacy/debug context: return the full AnalysisService context pack, capabilities, data flows, and graph summary. This may be large and can distract planning agents. Prefer aom.route_context for a window directory and aom.context_windows for focused inspection. Use this when context_windows/context_delta are insufficient or when auditing full context.
Compatibility fallback: expand one sliding window by windowId/offset/limit. Prefer aom.context_windows for normal work, because it maintains session cursors and prevents same-window collisions. Use this only when you intentionally need a single explicit slice.
Preferred detailed context tool: open multiple agent-selected sliding windows in one call while maintaining session-level cursors. Use this after route_context/call_chain whenever you need to inspect page structure, candidate controls, results, capabilities, or data flow. Choose the windows yourself; common sets are ui:primary_actions + dataflow:all, or ui:header + ui:main + dataflow:all. Each request may provide cursorId/windowId/offset/limit/direction. Reuse cursorId with direction=next/previous/current/reset to move that cursor. AOM prevents same-window collisions by shifting overlapping ranges when avoidCollisions is true, so context budget is not wasted on duplicate slices. This is agent-directed: route_context can reveal available window ids, but the agent chooses which windows and how many cursors to open.
Detach from the current AOM session without closing the app. Use this when you are done analyzing or before attaching to a different app.
Invoke a current AOM executable capability using its graph-backed action plan. Use this before low-level invoke_view when a matching capability exists. Pass capabilityId as a stable name like search_content when available, or a full capability id from the latest route_context/context_pack/capabilities.
Low-level UI action: click, type, or select on a specific view element. Use invoke_capability first when a matching capability exists. Provide viewId (from context_windows) or label/rawId for fallback matching.
Launch a debuggable app and attach AOM without closing it later. Returns compact readiness/analysis summary only; do not expect full context here. After this succeeds, call aom.call_chain or aom.route_context, then use aom.context_windows for agent-selected multi-area inspection. The returned readiness only means AOM can observe/analyze; still verify action effects after execution.
Compact window directory and starting overview after launch/attach and after meaningful actions. Use this to discover available window ids, current screen summary, lastContextDelta, and initial suggested windows. Do not rely on route_context alone for detailed exploration; use aom.context_windows to open the exact regions and cursor count you need. If the previous action returned contextDelta, combine that delta outcome with this current-state view before planning. If lastContextDelta.outcome is verified, follow its recommendedTargets/recommendedNext before retrying the same action. For search/navigation tasks, normally follow with aom.context_windows over ui:primary_actions, ui:header or ui:main, and dataflow:all.
Return the status of all active AOM sessions.
Debug tool: collect the raw runtime snapshot for an active AOM session. This can be large and low-level. Prefer aom.call_chain plus aom.context_windows for normal task planning. Use snapshot only when you need raw node values/attributes that are not present in context windows.
Parameter descriptions lack format/constraint details. E.g., 'timeoutMs' has no min/max bounds; 'limit' in context_windows has no range; 'action' in invoke_view has no enum of valid actions (click, type, select, etc.).
Tool overlap and unclear composition. context_pack, context_window, and context_windows serve similar purposes; descriptions say 'prefer context_windows' but do not clearly explain when context_pack or context_window are necessary. Agents may waste calls choosing between them.