Loading ToolBench
A Cloudflare Workers-based MCP server that manages browser connections and proxies API calls through a WebSocket bridge. Implements the Model Context Protocol (MCP) JSON-RPC 2.0 specification for tool listing and execution.
Broxy Worker exposes 4 tools but with severe quality gaps. Two tools (tools/list, tools/call) are legitimate MCP tools; two others (initialize, ping) are protocol handlers mischaracterized as tools. Tool descriptions are present but extremely brief (13-47 chars). The tools/call schema is minimal and missing critical field descriptions. No error handling guidance, no output schemas documented, and protocol-level concerns conflate message handlers with callable tools. The server acts as a bridge to a browser instance but fails to provide clear, LLM-optimized definitions for the two actual domain tools.
Initializes the MCP server and exchanges protocol version and capability information with the client.
Simple ping command to verify server connectivity and responsiveness.
Executes a tool in the connected browser instance. Calls the specified tool with provided arguments and returns the result.
Retrieves the list of available tools from the connected browser instance. Returns tool definitions including name, description, and input schema.
tools/list has no output schema documented. LLMs cannot plan downstream tool calls without knowing what fields the response contains (tool names, descriptions, input schemas, etc.). Critical for tool discovery.
tools/call schema lacks descriptions for the 'arguments' parameter. LLMs cannot infer what structure is expected.
Per guidelines: 'If descriptions are under 20 characters: description score CANNOT exceed 40.' Additionally, descriptions must be 10 - 1024 chars per pattern spec, these are too brief to guide LLM selection.
initialize and ping are protocol handlers, not domain tools. initialize is an MCP message handler for the handshake; ping is a keep-alive mechanism. Per MCP spec, these should NOT be exposed as callable tools in the tools/list response. They should be handled internally by the MCP transport layer.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | 2025-03-26+ | v1 |
No error handling guidance in tool descriptions. tools/call could fail for many reasons (tool not found, invalid arguments, timeout, browser disconnected). Per pattern:recovery-guide, error responses must tell the LLM what to do next. Currently: silent failures risk.
tools/list description does not explain WHEN or WHY to call it. Current text ('Retrieves the list...') is transactional but not decision-guiding for the LLM.
No output schema for tools/call. What does the result look like? Is it the raw browser tool result, a wrapped response with status/data, or error details? LLMs need this to parse and chain subsequent calls.