Loading ToolBench
Ship quality products with AI-powered E2E acceptance testing that validates your web app like a real user — from Claude Code and Cursor to PR.
This MCP server demonstrates good foundational quality with comprehensive tool coverage (17 tools) and structured schemas. Most tools have clear descriptions and well-defined input parameters with type constraints. However, there are notable gaps in output schema documentation, error handling guidance, and some parameter descriptions lack sufficient depth. The server uses proper JSON Schema syntax and follows verb_noun naming conventions consistently. Tool composition is generally sound with clear chains between discovery/create/update/read operations. The main weaknesses are: (1) Output schemas are not explicitly documented for any tool, LLMs must infer response structure; (2) Error handling lacks recovery guidance and classification; (3) Some parameter descriptions are generic or incomplete; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences in operations (e.g., destructive deletes, read-only lists).
Check the status of Muggle Test Local. This verifies the connection to web-service and shows current session information.
List all stored testing sessions. Shows session IDs, status, and metadata for each session.
Get detailed information about a run result including screenshots and action script output.
List run results (test generation and replay history), optionally filtered by cloud test case ID.
Create an E2E acceptance testing project to organize browser tests for a web app. A project groups test scenarios (use cases), specific test steps (test cases), and replayable browser scripts (test scripts) for one application. Create a project first before generating or running any E2E tests.
Delete a project and all associated entities. This is a soft delete.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences
Some parameter descriptions are generic or incomplete, limiting LLM disambiguation
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | <=2025-11-25 | v2 |
Get details of a specific project by ID.
List projects accessible to the authenticated user. Returns up to 10 items per page by default (max 100). Response includes pagination metadata (totalCount, totalPages, hasMore) — check `hasMore` to decide whether to fetch additional pages.
Update an existing project's details.
Approve (graduate) selected use case candidates into actual use cases.
Create one or more use cases from natural language instructions.
Get the use case discovery memory for a project, including all discovered use case candidates.
Get details of a specific use case by ID.
List use cases for a project. Returns up to 10 items per page by default (max 100). Response includes pagination metadata (totalCount, totalPages, hasMore) — check `hasMore` to decide whether to fetch additional pages.
Preview a use case generated from a natural language instruction without saving.
Directly update an existing use case's fields without invoking the LLM. Pass only the fields you want to change — others are left untouched. Use this for cheap, deterministic edits (rename, flip status DRAFT→APPROVED, change priority, edit acceptance criteria). For LLM regeneration from a new instruction, use muggle-remote-use-case-update-from-prompt instead. Note: changing title, description, or url triggers background regeneration of dependent test cases on the server.
Update an existing use case by regenerating its fields from a new instruction.
Destructive tool (delete) lacks confirmation/dry-run pattern and minimal error guidance
Pagination guidance inconsistent and some tools lack clear batching semantics