testing-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TESTING_MCP | No | When set to true, enables the WebSocket bridge to the MCP server. Leave unset to disable. | |
| TESTING_MCP_PORT | No | Overrides the WebSocket port for test clients. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_test_stateA | Get the current state of a connected test, including DOM, snapshot, console logs, and available context APIs. The response includes 'availableContext' field which lists all APIs/variables that can be used in execute_test_step. |
| finalize_testB | Finalize the test by removing connect() call and optionally cleaning up markers |
| list_active_testsA | List all currently connected test processes |
| get_generated_codeB | Get all generated code blocks from a test file |
| execute_test_stepA | Execute code directly in the connected test client and get back the updated DOM state and console logs. IMPORTANT: Before using this tool, call get_current_test_state first to check the 'availableContext' field, which lists all available APIs/variables you can use in your code. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a clearly distinct action: inspecting state, executing a step, finalizing a test, listing active tests, and retrieving generated code. The only related tools are get_current_test_state and execute_test_step, but one is read-only while the other executes code, so there is no ambiguity.
All tool names follow a consistent verb_noun pattern: get_current_test_state, finalize_test, list_active_tests, get_generated_code, execute_test_step. The verbs and nouns are uniformly formatted with underscores.
With 5 tools, the server is well-scoped for its testing purpose. Each tool is necessary and there is no bloat or overly sparse set.
The tool set covers the full testing workflow: listing active tests, inspecting state, executing steps, retrieving generated code, and finalizing. No obvious missing operations for the stated purpose.