Loading ToolBench
MCP server for Testplane browser-automation tools
Testplane MCP exposes 24 browser automation and test result inspection tools via STDIO. Most tools have names and descriptions, but critical gaps exist: (1) No visible input schemas for 16 of 24 tools (navigate, click-on-element, hover-element, type-into-element, select-option, wait-for-element, take-page-snapshot, take-viewport-screenshot, browser-console, list-tabs, switch-to-tab, open-new-tab, close-tab, launch-browser, attach-to-browser, attach-repl, close-browser, save-state, restore-state, run-code); (2) Descriptions are very brief (10-40 chars for most browser tools), lacking detail on WHEN to use, prerequisites, or what data is returned; (3) Tool names use verb-noun structure (good), but lack clarity on parameters, e.g., 'click-on-element' doesn't indicate what identifier is expected (CSS selector? XPath? testid?); (4) No parameter descriptions visible in source for most tools; (5) Complex tools like 'test-results' and 'inspect-result' have detailed schemas with good descriptions, but are outliers. The server reads like a direct passthrough from CLI tooling without LLM-optimized refinement. Average tool score ~42 due to missing schemas and descriptions for 66% of tools.
Attach a REPL to the browser for interactive commands
Attach to an existing browser session
Execute JavaScript code in the browser console
Click on an element in the browser
Close the browser session
Close a browser tab
Hover over an element in the browser
Read a Testplane HTML report and inspect test result attempt details as JSON
16 of 24 tools (67%) have NO visible input schemas in source code. Affects: navigate, click-on-element, hover-element, type-into-element, select-option, wait-for-element, take-page-snapshot, take-viewport-screenshot, browser-console, list-tabs, switch-to-tab, open-new-tab, close-tab, launch-browser, attach-to-browser, attach-repl, close-browser, save-state, restore-state, run-code, time-travel-export-html. LLMs cannot infer parameter names, types, or constraints without explicit schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Launch a browser session
List all open browser tabs
Navigate to a URL in the browser
Open a new browser tab
Restore a previously saved browser state
Run code in the browser or testplane context
Save the current browser state
Select an option from a dropdown or select element
Switch to a specific browser tab
Take a full page snapshot of the current browser tab
Take a viewport screenshot of the current browser tab
Read a Testplane HTML report and list test results with optional filtering and pagination
Export Testplane Time Travel rrweb snapshot as interactive HTML
Inspect Testplane Time Travel rrweb snapshot at a selected time and return a DOM snapshot of the replayed page, optionally with a diff from a previous time
Type text into an element in the browser
Wait for an element to appear in the browser
Most tool descriptions are extremely brief (10 - 40 characters). Examples: 'Navigate to a URL in the browser' (33 chars, minimal detail); 'Click on an element in the browser' (34 chars). Descriptions lack WHEN to use, prerequisites, expected return values, error cases, or dependency hints. Baseline is 194 chars; these are 6 - 17% of that. LLMs cannot determine when/why to select tools without richer context.
Parameter ambiguity in browser tools. E.g., 'click-on-element' and 'hover-element' do not specify whether the element selector is CSS, XPath, testid, data attribute, or element ID. No parameter descriptions are visible. This forces LLMs to guess, leading to wrong selectors and cascading failures. Baseline: 100% of A+ tool params have descriptions.
No visible error handling or recovery guidance in descriptions. Browser automation tools can fail in many ways (element not found, timeout, stale reference), but descriptions do not explain what errors might occur or how to recover. Baseline pattern: every error should tell the LLM what to do next.
Destructive tools (close-browser, close-tab) lack confirmation or dry-run patterns. 'close-browser' is irreversible, the description does not warn the LLM of this or suggest a confirmation step. Baseline pattern: irreversible operations should support dry-run or require explicit confirmation.
Stateful tool sequences poorly documented. Tools like 'launch-browser' → 'navigate' → 'click-on-element' form an implicit chain, but no tool description or parameter indicates dependencies (e.g., 'Requires: active browser session from launch-browser or attach-to-browser'). LLMs must infer the sequence without guidance.
'run-code' tool accepts arbitrary code with minimal description. No visible parameter descriptions or constraints. This is a high-risk operation, LLMs could execute destructive code. Baseline: tools that execute code should warn of side effects and require explicit permissions or safeguards.