Loading ToolBench
Native messaging host providing PTY (pseudo-terminal) and browser-control MCP (Model Context Protocol) server. Enables CLI agents to control the active browser tab through MCP tools while maintaining a real local terminal.
Strong schema definitions with detailed parameter constraints and enums. Tool names follow verb_noun pattern (omeety_browser_*). Descriptions are comprehensive (100-300 chars) and explain WHEN to use each tool. However, parameter descriptions are sparse or missing in several tools (omeety_browser_wait, omeety_fetch_with_cookie have empty input schemas). Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels in metadata.
Perform one Browser Core action with target pinning and verification. completionLevel is dispatched, applied, or committed; committed requires expect.persistAfterReload:true and a post-reload match. For rich-text chat, query and click an explicit send control (including icon semantics such as SendColorful) instead of guessing Enter; verify the editor valueEquals:'' and the sent message text appears.
Browser Core observation. Defaults to a compact snapshot without duplicated CSS paths. Use profile:'standard' for full locator paths or deep:true for CDP DOMSnapshot, Accessibility and frame/target summaries.
Find and rank interactive elements by text, accessible name, role or CSS selector. Returns stable uid locators that survive common SPA rerenders.
Return Browser Core health, policy, target/frame registry, reliability metrics and optionally recent redacted audit/events.
List, open, switch or close browser tabs through one Browser Core entry point.
Three tools have empty or near-empty input schemas (omeety_browser_wait, omeety_get_selected_context, omeety_fetch_with_cookie). These tools lack parameter documentation entirely, forcing LLMs to guess valid inputs.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., what does omeety_browser_query return? Is it an array of objects with uid, role, text, bbox?). Rubric requires 100% of A+ tools to have documented return types.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Run 1-20 pinned browser steps as an auditable transaction. Stops at the first semantic failure by default and returns exact per-step timing and recovery information.
Wait across reloads, navigations and BFCache for page, URL, text, target value, selected state, aria-current, class or target-text postconditions.
Fetch a same-origin URL with the page's cookies. Non-GET methods require user consent unless confirmed:true.
Build a compact multimodal Context Bundle around uid/selector, the sidebar pick, current text selection, or focused element. Returns accessibility-like identity, safe attributes/value preview, computed styles, ancestors, nearby interactive elements, iframe/Shadow DOM paths, page overview/topology, diagnostics, performance metrics, and by default a cropped element screenshot as a real MCP image content block. This is the preferred 'understand this element' tool.
Capture a snapshot of the current page: url/title/visibleText/overview/topology + interactive[] (stable uid, role, text, bbox, selector, frame/shadow path) + viewport and build metrics. Traverses open Shadow DOM and same-origin iframes. Pass sinceSnapshotId from a previous response to receive an unchanged marker or light-mode delta instead of another full snapshot. Pass uid to click/fill/type/select. Snapshot bbox is in CSS pixels; screenshot pixels may differ by DPR.
Return the user's current text selection plus its enclosing element.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite metadata clearly marking risk levels (READ_ONLY vs WRITE). Current MCP spec (2026-07-28) rewards tool annotations for agent safety. This is a spec alignment gap.
Error handling is absent. No recovery guidance, error classification, or actionable messages. E.g., if omeety_browser_act fails, what should the LLM do? Retry? Call a different tool? This violates pattern:recovery-guide.
Parameter descriptions are inconsistent. omeety_browser_act has detailed descriptions for expect, modifiers, inputMode; but omeety_browser_wait has NO properties defined. Rubric baseline: 100% of A+ tool params have descriptions.