Loading ToolBench
msw-mcp provides 5 tools for managing Mock Service Worker handlers at runtime. Tool naming follows the verb_noun pattern (msw_add_handlers, msw_reset_handlers, etc.), which is good for clarity. However, definitions have significant gaps: descriptions are present but lack clear guidance on when to use each tool vs. alternatives; parameter descriptions exist but lack constraints (enums, ranges, patterns); output schemas are not documented at all; and error handling is absent from the tool definitions. The tools accept arbitrary JavaScript code strings as input, which presents a security/validation concern. Tool 1 (msw_add_handlers) and Tool 5 (msw_get_status) have acceptable descriptions (150-200 chars), but Tools 2-4 have longer, somewhat repetitive descriptions that could be tightened. No tools declare their output structure, making it impossible for LLMs to plan chained calls or extract specific fields. Overall, the server is functional but lacks the rigor expected of production-grade agent tools.
Add MSW request handlers to the browser service worker at runtime. Accepts JavaScript handler code strings that will be executed in the browser.
Get the current status of MSW handlers in the browser service worker, including the list of active handlers.
Remove specific MSW request handlers from the browser service worker by URL patterns and optional HTTP methods.
Reset MSW request handlers in the browser service worker. If no handlers provided, removes all runtime handlers and keeps only initial ones. If handlers provided, replaces all handlers with the new ones.
Update existing MSW request handlers by replacing handlers that match specified URL patterns with new handler code. This is an atomic operation that removes old handlers and adds new ones in a single transaction.
No output schemas documented for any tool. Tool descriptions do not specify what fields are returned, what types they are, or how to reference results in downstream calls. This violates the pattern:tool-description and pattern:response-shaper patterns.
Input parameters lack type constraints, enums, and format specifications. The 'handlers' parameter accepts arbitrary JavaScript code strings with no validation hints. The 'patterns' and 'methods' parameters do not specify valid values, ranges, or formats. This violates pattern:constrained-input and pattern:tool-description.
No error handling guidance. Tool descriptions do not specify what errors can occur, when they are retryable, or what the LLM should do to recover. This violates pattern:recovery-guide and pattern:error-classification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No distinction between tools that modify state and those that only read. Tool descriptions do not explicitly state which operations are idempotent, destructive, or have side effects. LLMs cannot distinguish retry-safe calls from irreversible ones, violating pattern:command-tool.
Tool descriptions do not explain when to use one tool vs. another. For example, msw_reset_handlers and msw_add_handlers both add handlers, what is the semantic difference? When should an LLM pick msw_update_handlers vs. msw_reset_handlers? No disambiguation provided, violating pattern:tool-description.
Security concern: handlers parameter accepts arbitrary JavaScript code strings. No validation, sanitization, or execution sandbox mentioned. LLMs could be tricked into passing malicious code. Violates pattern:tool-gateway and pattern:secret-injection best practices.