Loading ToolBench
MCP server for MCPMonkey browser extension that enables browser tab management and WebSocket communication between a Firefox extension and MCP clients
MCPMonkey server has 4 tools with mixed quality. Tool naming follows verb-noun conventions (debug, sendWebSocketMessage, getServerInfo, browserAction), which is good. However, descriptions are inconsistent: 'debug' and 'getServerInfo' have minimal descriptions (8-10 chars), while 'browserAction' has an extensive multi-line description that embeds implementation details. Critical gaps: (1) Most tools lack parameter descriptions, 'debug' and 'getServerInfo' have empty input objects with no documented constraints; (2) 'sendWebSocketMessage' has a single 'message' param with a basic description but no type validation guidance; (3) 'browserAction' uses a complex nested schema with an 'action' enum and 'data' object containing conditional properties, but the schema lacks clarity on which properties are required for each action, and parameter descriptions for nested fields are missing entirely; (4) No output schemas are documented, tools do not declare what LLMs should expect in responses; (5) No error handling guidance, tools do not explain what happens on failure or how to recover. The server is transport-locked to STDIO, which is a hard architectural limitation.
Execute browser-related actions for tab management. Available actions and their responses: 1. getTabs: Returns an array of all open tabs Response: TabSchema[] Example: [{ id: 1, windowId: 1, url: "https://example.com", title: "Example", active: true, pinned: false, index: 0 }, ...] 2. createTab: Creates a new tab Parameters: { url?: string, active?: boolean, windowId?: number } Response: TabSchema Example: { id: 2, windowId: 1, url: "https://example.com", title: "Example", active: true, pinned: false, index: 1 } 3. closeTabs: Closes specified tabs Parameters: { tabIds: number[] } Response: void (success) or throws error 4. activateTab: Activates (focuses) a specific tab Parameters: { tabId: number, windowId?: number } Response: TabSchema Example: { id: 1, windowId: 1, url: "https://example.com", title: "Example", active: true, pinned: false, index: 0 } 5. duplicateTab: Duplicates a specific tab Parameters: { tabId: number } Response: TabSchema Example: { id: 3, windowId: 1, url: "https://example.com", title: "Example", active: true, pinned: false, index: 2 }
Test if the MCP server is receiving messages
Get information about the current server state
Send a message to all connected WebSocket clients
Critical: Most tools lack descriptions under 20 characters. 'debug' (8 chars: 'Test if the MCP server is receiving messages') and 'getServerInfo' (10 chars) provide minimal context.
Critical: 'debug' and 'getServerInfo' have empty input schemas ({}). No parameters documented. These tools lack even basic parameter documentation.
High: 'browserAction' uses a complex conditional parameter structure (action enum determines which properties of 'data' are valid), but nested parameter descriptions are missing. LLMs cannot determine which fields are required for each action. Undocumented parameter dependencies violate composition patterns.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
High: No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. 'browserAction' returns TabSchema[] or TabSchema depending on action, but the response structure is never defined.
High: No error handling guidance. Tools do not explain failure modes (e.g., what if WebSocket message fails to send? What if a tab ID is invalid?). Per pattern: error responses must tell the LLM what to do next. Current implementation provides no recovery guidance.
Medium: 'browserAction' embeds implementation details and examples in the description ('Example: { id: 1, windowId: 1, ...}'). Use formal constraints (enums, schemas) instead.
Medium: 'browserAction' parameter descriptions lack actionable constraints. E.g., 'url' for createTab has no guidance on format (http vs https, relative vs absolute). 'tabId' has no explanation of valid ranges or where to find valid tab IDs.
Medium: 'browserAction' is a single tool handling 5 sub-actions (getTabs, createTab, closeTabs, activateTab, duplicateTab). This violates single-responsibility principle. Each action should be a separate tool (get_tabs, create_tab, close_tabs, activate_tab, duplicate_tab) so agents can compose them independently and the LLM can select precisely.