MCP Workbench

Discover, validate, and test every MCP server across Cursor, VS Code, and Claude — in one place.

MCP server definitions end up scattered across half a dozen files with different root keys and transport conventions, and a single typo silently drops a server with no warning. MCP Workbench scans every known location, normalizes the results into one tree, and flags the misconfigurations that usually cost you an hour of debugging.

Features

• Unified discovery — one tree of every MCP server found across Cursor, VS Code, Claude Code, and Claude Desktop, grouped by source.
• Transport normalization — stdio, http, and sse servers shown with a consistent shape regardless of which editor's field conventions the file used.
• Configuration validation — surfaces the silent failures: wrong root key, unparseable JSON, npx without -y, environment variables that aren't set, and variable syntax the editor leaves as written.
• Security & correctness checks — flags hardcoded API keys, credentials in URLs, plaintext http:// remotes, unpinned npx/bunx launchers, curl | sh bootstrap chains, encoded PowerShell, code-loading or registry-redirecting environment variables like NODE_OPTIONS=--require, and cloud-metadata endpoints, all from the config you already have.
• Safe with untrusted repos — servers defined by a workspace never launch without showing you the program, each argument, the environment, the headers, and which of your environment variables they read. Approvals are pinned to that exact configuration, and in Restricted Mode nothing that runs from the workspace launches at all while validation keeps working.
• Problems-panel diagnostics — every issue is published as a native VS Code diagnostic anchored to the exact key in the config file, so it shows up as a squiggle and in the Problems panel with click-to-jump.
• Connection testing — launch any server over the MCP SDK, run the initialize handshake, and list its capabilities, tools, resources, and prompts (with input schemas) — or see the exact reason it failed to connect.
• Per-server health — a fast Test Connection records each server's handshake latency and tool count, shown inline in the tree, with a status-bar rollup of how many servers and issues were found across every source.
• Live tool calls, resource reads, and prompt fetches — call any tool through a form generated from its input schema, with required-field validation and a Form/JSON toggle for advanced edits; read any resource (or fill in a template URI); and fetch a prompt's messages with its arguments — all against the live server, rendered inline.
• Provenance at a glance — every server shows which file and editor it came from, with the absolute config path one click away.
• Live refresh — re-scans automatically when any known MCP config changes in your workspace.

Screenshots

Hover any server to see its source, the exact config file it came from, and every validation issue:

Per-server health

Run a fast Test Connection on any server to record its handshake latency and tool count, shown inline in the tree — with a status-bar rollup of every server and issue found:

Status-bar rollup

An always-visible MCP item in the status bar rolls up every source at a glance — the total server count, plus a running tally of configuration and security issues. Hover for the full N servers, X errors, Y warnings breakdown, click to jump straight to the Servers view, and watch it turn yellow or red the moment a warning or error appears:

Tool, resource & prompt tester

Open a server to call its tools through a form generated from each tool's input schema (or switch to raw JSON), read resources, and fetch prompts — live, with results rendered inline:

Where it looks

Servers recorded per project under projects["<path>"].mcpServers in ~/.claude.json are scoped to the open workspace folder by default. Set mcpWorkbench.showAllClaudeProjects to list every recorded project. Edits to the global config files above refresh the tree automatically.

When MCP Workbench runs inside VS Code, VS Code Insiders, or VSCodium, the VS Code (user) entry is the default profile's mcp.json for that install, including portable installs. In other editors it falls back to the default VS Code location above.

Validation checks

Every issue below is also published to the Problems panel, anchored to the exact key it concerns.

Configuration

Security

Turn the whole security lens off with mcpWorkbench.security.enabled: false, or retune individual rules with mcpWorkbench.security.ruleSeverity — e.g. { "unpinned-launcher": "off", "hardcoded-secret": "error" } (values: off, info, warning, error). Both settings are read from your user settings only, so a repository's workspace settings can't switch the checks off.

Install

• VS Code — open the Extensions view and search "MCP Workbench: Discover & Test", or install from the Marketplace.
• Cursor — open Extensions and search "MCP Workbench" (Cursor installs from Open VSX), or install from Open VSX.

Then click the MCP Workbench icon in the activity bar to open the Servers view.

Build from source

git clone https://github.com/wheelbarrel00/mcpworkbench.git
cd mcpworkbench
npm install
npm run compile

Press F5 to launch an Extension Development Host with MCP Workbench loaded, or run npm run package to build a .vsix you can install with --install-extension.

Usage

• Refresh — re-scan all locations from the view's title bar.

• Open Config File — right-click a server to jump to the exact file it came from.

• Test Connection — click the plug button on a server (or right-click → Test Connection) for a fast health check: it connects, times the handshake, and counts the tools without opening the full panel. The latency and tool count are cached and shown inline in the tree, and a rollup of every server and issue stays in the status bar.

  

• Test Server — click the ▶ button on a server (or right-click → Test Server) to connect over the MCP SDK and open a panel with the server's initialize info, capabilities, tools, resources, and prompts — or the exact connection error. The panel stays connected while open: call a tool through a form generated from its schema (or switch to raw JSON), Read a resource (filling in any template variables), or Get prompt with its arguments to run against the live server, then close the panel to disconnect.

• Launching like your editor — the tester starts each server the way the editor that owns its config would. It expands only that editor's variable syntax, and after the launch prompt it asks for any VS Code ${input:...} values. Stdio servers get your full environment, except Claude Desktop servers, which get only Claude Desktop's small default set. A command that still contains ${...} after filling in is never run. An http server that refuses Streamable HTTP is retried over SSE, and tools, resources, and prompts are loaded across pages, up to 50 pages or 2,000 items each.

• Launching workspace servers — servers from .mcp.json, .vscode/mcp.json, or .cursor/mcp.json come from the repo, so you're asked before the first test runs. The prompt shows the command, environment, headers, which of your environment variables will be filled in or are not set, and that a local program also inherits your environment. Always allow this configuration remembers that exact entry, and if the repo later changes it, you're asked again. Run MCP Workbench: Reset Launch Trust to forget every approval in this workspace. In Restricted Mode, nothing that runs from the workspace launches until you trust it, including your own servers set up to run in that folder. On Windows, a bare command like npx is resolved from your PATH before the project folder, so a same-named file committed to the repo can't stand in for it. If the program is only found through the workspace folder, the prompt says so.

License

MIT