Loading ToolBench
MCP server for parallel browser automation with isolated Playwright sessions
Three session management tools with basic descriptions and schemas, but significant gaps in parameter documentation, error guidance, and composition patterns. The dynamic tool registration mechanism is clever but opaque, wrapped tools inherit only sessionId prefix with minimal schema translation. Descriptions meet minimum length but lack WHEN/WHY context and error recovery guidance. Parameters lack validation constraints and format specifications. No output schema documentation. Error handling is present but returns raw error messages rather than actionable recovery paths.
Close a browser session and terminate its backend process
Create a new isolated browser session. Each session runs an independent MCP backend process.
List all active browser sessions
Parameter descriptions lack format/constraint specification. 'backend' param in create_session states 'Options: playwright, chrome-devtools or any npm package name' but no validation of package name format, no length bounds, no examples of valid values. LLM will hallucinate invalid package names.
Output schemas are not documented. create_session returns {sessionId, backend, createdAt, message} as JSON text, structure is only visible in the code, not declared as part of the tool contract. list_sessions returns {count, sessions:[{sessionId, backend, createdAt, lastUsedAt}]}, again, inferred from implementation, not specified. LLMs cannot plan downstream tool calls without knowing the exact structure and field names.
Error messages do not provide recovery guidance. Errors like 'Error creating session: <raw error>' or 'Error calling tool: <error message>' do not tell the LLM what to do next. Should guide: 'Failed to create session: backend "invalid-pkg" not found. Call list_sessions to see available backends.' or 'Session not found. Create a new session with create_session().'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | 2024-11-05+ | v1 |
create_session description lacks WHEN/WHY context and prerequisites. States WHAT ('Create a new isolated browser session') but not WHEN to call it (before first tool use?) or why isolation matters. No mention that multiple concurrent sessions are supported or how they interact with wrapped backend tools.
list_sessions description is perfunctory ('List all active browser sessions'), under 35 chars, lacks context for discovery. Does not explain when to call it (to get available sessionIds before calling wrapped tools?) or what to do with the result.
Wrapped backend tools inherit only sessionId parameter injection with minimal schema translation. The registerBackendTool function converts JSON Schema properties to Zod on the fly, but loses semantic information: enum constraints are converted to z.enum() only if type is 'string', but complex object schemas or nested arrays become z.record(z.unknown()) or z.array(z.unknown()). Downstream LLM gets no type safety or field-level documentation for wrapped tool inputs.
sessionId parameter in wrapped tools has a generic description ('The session ID to use for this operation') that does not distinguish which session backend is active or whether the session is still valid. Should hint at calling list_sessions first or warning that invalid sessionIds will fail with specific error guidance.