Loading ToolBench
MCP server for human-in-the-loop browser automation with persistent browser sessions and CDP handoff
SessionBridge has 6 tools with basic descriptions and parameter schemas, but significant gaps prevent higher scores. All tools have descriptions (10-150 chars, within range) and input schemas with types. However, parameter descriptions are minimal or absent, most params lack context for LLM selection. Output schemas are not documented. Error handling is absent: no guidance on retryability, recovery steps, or actionable error messages. Tool composition is reasonable (each does one thing), but the server lacks idempotency guarantees, permission gates, and audit trails. STDIO transport caps protocol readiness at 50, further limiting overall score.
Disconnects the automation session from Chrome.
Re-checks the page state to confirm that the manual verification has passed and automation can safely proceed.
Checks the current browser status. Returns connection state, active URL, page title, and whether manual interaction is required.
Extracts the current page URL, title, and readable text content for the AI agent to analyze.
Opens the Chrome browser via CDP and navigates to the given URL. Returns the initial state and indicates if manual interaction (Cloudflare, CAPTCHA, login) is needed.
Waits actively for the human user to resolve a verification challenge (Cloudflare, CAPTCHA, login). Polls the page state until the challenge clears or timeout occurs.
Output schemas not documented. LLMs cannot infer what fields to expect from tool responses (e.g., does open_browser return {url, title, manual_interaction_required, error}?). This forces agents to guess and wastes tokens on exploratory calls.
Parameter descriptions missing or trivial. 'timeout_seconds' in wait_for_human lacks context (what happens on timeout? Does it return partial state or error?). 'max_length' in get_current_page has no guidance on typical values or impact. LLMs cannot reason about parameter selection without explicit descriptions.
No error handling or recovery guidance. Tools return dicts but no documentation of error fields, error codes, or what the LLM should do on failure. E.g., if open_browser fails due to Chrome not running, should the agent retry, launch Chrome, or ask the user?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No idempotency guarantees or state management documentation. If open_browser is called twice with the same URL, does it reuse the existing session or create a new one? Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects.
No permission gates or audit trails. Tools lack scope declarations (e.g., 'requires: browser_control'). No logging of who called what tool, when, and with what parameters. This violates compliance and debugging requirements for agent-initiated actions.