Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Workbench MCP Server generate a test spec for my local sqlite mcp server"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 한국어
Agent-facing MCP adapter for MCP Workbench — lets AI agents inspect, test, and validate MCP servers through structured tool calls.
@mcp-workbench/mcp-server wraps the MCP Workbench CLI as an MCP server, exposing its inspect, generate, run, and explain capabilities as structured tools that AI agents can call directly. It spawns the CLI as a subprocess and parses the output into typed responses.
Entry points:
@mcp-workbench/cliis the human-facing runner.@mcp-workbench/mcp-serveris the agent-facing MCP adapter. Both use the same core engine.
Related MCP server: Des MCP Server Testing MCP Server
Node.js >= 20
MCP Workbench CLI must be installed and available on your PATH:
# Primary — scoped package
npm install -g @mcp-workbench/cli
# Alternative — convenience wrapper
npm install -g mcp-workbench-cliOr set the MCP_WORKBENCH_CLI environment variable to point to the binary.
npm install -g @mcp-workbench/mcp-serverOr clone and build from source:
git clone https://github.com/raeseoklee/mcp-workbench-mcp-server.git
cd mcp-workbench-mcp-server
npm install
npm run buildclaude mcp add mcp-workbench -- npx -y @mcp-workbench/mcp-servercodex mcp add mcp-workbench -- npx -y @mcp-workbench/mcp-serverOr add to ~/.codex/config.toml:
[mcp_servers.mcp-workbench]
command = "npx"
args = ["-y", "@mcp-workbench/mcp-server"]
enabled = trueAdd to your claude_desktop_config.json:
{
"mcpServers": {
"mcp-workbench": {
"command": "npx",
"args": ["-y", "@mcp-workbench/mcp-server"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"mcp-workbench": {
"command": "npx",
"args": ["-y", "@mcp-workbench/mcp-server"]
}
}
}inspect_serverConnect to an MCP server and inspect its capabilities, version, and supported features.
Inputs:
Field | Type | Required | Description |
|
| Yes | Transport type |
|
| No | Server URL (required for streamable-http) |
|
| No | Command to launch server (required for stdio) |
|
| No | Arguments for the server command |
|
| No | HTTP headers (e.g. Authorization) |
|
| No | Timeout in ms (default: 30000) |
Output: Human-readable summary + structured JSON:
{
"serverName": "my-server",
"serverVersion": "1.0.0",
"protocolVersion": "2025-11-25",
"capabilities": {
"tools": true,
"resources": true,
"prompts": false,
"completions": false,
"logging": false
}
}generate_specAuto-generate a YAML test spec by discovering server capabilities. Partial discovery is supported automatically by the underlying CLI.
Inputs:
Field | Type | Required | Description |
|
| Yes | Transport type |
|
| No | Server URL |
|
| No | Server command |
|
| No | Server arguments |
|
| No | HTTP headers |
|
| No | Only include these types |
|
| No | Exclude these types |
|
| No | Discovery depth (shallow = list only, deep = call each) |
|
| No | Timeout in ms |
Output: Human-readable summary + structured JSON:
{
"yaml": "apiVersion: mcp-workbench.dev/v0alpha1\n...",
"testCount": 9,
"warnings": ["city: TODO_CITY_NAME # TODO: replace with actual value"]
}run_specRun a YAML test spec against an MCP server. Provide either specText (inline YAML) or specPath (path to a file). At least one is required.
Inputs:
Field | Type | Required | Description |
|
| No* | Inline YAML spec content |
|
| No* | Path to a YAML spec file |
|
| No | Timeout in ms |
*At least one of specText or specPath must be provided.
Output: Human-readable summary + structured JSON:
{
"total": 3,
"passed": 3,
"failed": 0,
"skipped": 0,
"errors": 0,
"durationMs": 4,
"failures": []
}explain_failureAnalyze test run results and explain failures with heuristic classification and actionable recommendations.
Inputs:
Field | Type | Required | Description |
|
| Yes | The structured result from |
Output: Human-readable summary + structured JSON:
{
"summary": "All tests passed",
"causes": [],
"recommendations": []
}Tool text summaries support multiple languages. Structured JSON outputs are always language-neutral.
Locale | Language |
| English (default) |
| Korean |
Set language via environment variable:
MCP_WORKBENCH_LANG=ko node dist/index.jsOnly user-facing text summaries are translated. Tool names, schema fields, and JSON output keys are always in English.
"Inspect this server and tell me what capabilities it has"
"Generate a YAML test spec for this server"
"Run this spec and explain any failures"
Authentication headers are passed per-call and not persisted
No tokens or credentials are stored by this server
Tokens are not echoed back in tool outputs
The server spawns mcp-workbench CLI as a subprocess with the current environment
Spec files written to temp directories are cleaned up after use
specText in run_spec uses a temporary file internally
Headers in run_spec are not forwarded to the underlying server — headers must be embedded in the spec YAML itself
explain_failure is heuristic-based, not AI-powered
generate_spec test count detection is regex-based
Only stdio transport is supported for connecting to this MCP server itself
No streaming of test results (waits for full completion)
No caching of inspection or generation results between calls
npm install
npm run build
npm testv0.1 (current):
inspect_server, generate_spec, run_spec, explain_failure
Claude Code integration demo
v0.2:
Structured outputs via outputSchema (when SDK support lands)
Spec diff support
v0.3:
AI-assisted assertions
Merge/update existing spec
Apache-2.0
Analyze test run results and explain failures with heuristic classification and actionable recommendations. Pass the structured result from run_spec.
| Name | Required | Description | Default |
|---|---|---|---|
| runResult | Yes | The RunReport object from a run_spec call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It mentions heuristic classification and recommendations but does not describe any side effects, authorization needs, rate limits, or what happens with invalid input. The brief description leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the purpose and input requirement without redundancy. Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the input schema is fully described, the tool has no output schema, and the description lacks details about the output format or structure. The mention of 'heuristic classification and actionable recommendations' is vague, leaving the agent uncertain about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, detailing all nested properties. The description adds meaning by specifying that the runResult parameter should be the structured result from run_spec, which contextualizes the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes test run results to explain failures with heuristic classification and actionable recommendations. It specifies the input source as 'the structured result from run_spec,' which differentiates it from sibling tools like generate_spec, inspect_server, and run_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by requiring the structured result from run_spec, indicating it should be used after a run_spec call. However, it does not explicitly state when not to use it or provide alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a YAML test spec by discovering the capabilities of an MCP server. Returns a ready-to-run spec.
| Name | Required | Description | Default |
|---|---|---|---|
| transport | Yes | Transport type to use for connecting to the server | |
| url | No | Server URL (required for streamable-http transport) | |
| command | No | Command to launch the server (required for stdio transport) | |
| args | No | Arguments to pass to the server command | |
| headers | No | HTTP headers to send (e.g. Authorization) | |
| include | No | Only include these capability types in the spec | |
| exclude | No | Exclude these capability types from the spec | |
| depth | No | Discovery depth: shallow (list only) or deep (call each tool/resource/prompt) | |
| timeoutMs | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions discovering capabilities but omits critical details: that it will connect to the server, potentially execute calls (especially with depth='deep'), and that it returns a YAML spec. The actual behavior of initiating network connections and running discovery actions is not transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The action and result are front-loaded. Every word adds value, and the structure is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description is too terse. It does not explain the discovery mechanism, how transport selection affects required parameters, or how the output spec is structured. An agent lacks the operational context needed to invoke the tool correctly, especially for complex scenarios like specifying headers or depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides. It does not elaborate on how parameters like depth or include/exclude affect the generated spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool generates a YAML test spec by discovering MCP server capabilities and returns a ready-to-run spec. The verb 'generate' is specific, and the resource is clearly a test spec. It distinguishes from sibling tools (explain_failure, inspect_server, run_spec) which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or how it compares to siblings like inspect_server or run_spec. Agents must infer usage context from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to an MCP server and inspect its capabilities, version, and supported features.
| Name | Required | Description | Default |
|---|---|---|---|
| transport | Yes | Transport type to use for connecting to the server | |
| url | No | Server URL (required for streamable-http transport) | |
| command | No | Command to launch the server (required for stdio transport) | |
| args | No | Arguments to pass to the server command | |
| headers | No | HTTP headers to send (e.g. Authorization) | |
| timeoutMs | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only inspection but does not disclose connection failure behaviors, timeouts, or side effects. For a tool that connects to an external server, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part serves to define the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values (no output schema) and does not cover what happens after connection (e.g., what 'inspect' returns). For a tool with 6 parameters and no annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameter meanings. The description adds no extra context beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and nouns: 'connect to an MCP server and inspect its capabilities, version, and supported features.' It clearly distinguishes from siblings like explain_failure (explain), generate_spec (generate), and run_spec (run), making the tool's purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only states its function, leaving the agent to infer from sibling names. No 'when to use' or 'when not to use' conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a YAML test spec against an MCP server and return results. Provide either specText (inline YAML) or specPath (path to a file). At least one is required.
| Name | Required | Description | Default |
|---|---|---|---|
| specText | No | Inline YAML spec content to run | |
| specPath | No | Path to a YAML spec file to run | |
| timeoutMs | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'return results' but does not specify output format, side effects, or safety profile. Important behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second clarifies parameter usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is minimal but covers the core purpose and parameter constraints. It lacks broader context like expected output, error handling, or integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying mutual exclusivity ('either specText...or specPath') and the requirement ('At least one is required'), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a YAML test spec against an MCP server and return results,' providing a specific verb and resource. It distinguishes from sibling tools (explain_failure, generate_spec, inspect_server) by focusing on execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that at least one of specText or specPath is required, but lacks explicit guidance on when to use this tool versus siblings or when not to use it. The context is implied by the tool's name and sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
run_spec1 field changedInput schema / properties / headersRemoved value: -{
- "additionalProperties": {
- "type": "string"
- },
- "description": "HTTP headers (for future use — headers typically come from the spec itself)",
- "type": "object"
-}v0.1.0explain_failuregenerate_specinspect_serverrun_specScored across 4 tools
Each tool has a distinct purpose: inspect_server discovers server capabilities, generate_spec creates test specs, run_spec executes them, and explain_failure analyzes results. No overlap, clear boundaries.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., inspect_server, generate_spec). No mixing of conventions.
With 4 tools, the set is well-scoped for a test workbench: inspect, generate, run, explain. Each tool is essential and the count is neither too few nor too many.
The tool surface covers the core workflow (inspect, generate spec, run spec, explain failures) with no critical gaps. Minor missing features like spec validation or listing are acceptable.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
