MCP Inspector

Inspect, debug and interact with Model Context Protocol servers without leaving Visual Studio Code. MCP Inspector connects to a server, lists the tools it exposes, and lets you run them with your own arguments — no separate inspector process required.

Features

• Connect to a local server over STDIO, or to a remote URL with automatic Streamable HTTP → SSE detection
• Reach servers behind a private CA or mutual TLS with built-in certificate pickers (desktop)
• Sign in to OAuth-protected servers in the desktop app or VS Code for the Web, with tokens kept in VS Code SecretStorage
• Add custom headers per server, including Authorization: Bearer … tokens
• Pick a server script with the native file dialog, or type a command such as npx
• Browse every tool a server exposes, including its input schema
• Execute tools with typed schema fields (text, number, boolean, enum, JSON), a raw-JSON mode, live progress, elapsed time, pretty-printed JSON results, and one-click copy
• Launch from the activity-bar view or the Command Palette, and inspect in a full panel
• Run in the desktop app and in VS Code for the Web, with a relay fallback when a server blocks the browser origin

Installation

Install MCP Inspector from the Visual Studio Marketplace, or download the latest .vsix from GitHub Releases and run:

code --install-extension mcp-inspector-<version>.vsix

See CHANGELOG.md for release notes.

Usage

1. Select the MCP Inspector icon in the activity bar.
2. Run the Create New MCP Request command from the Command Palette.
3. Choose the server type:
   • Local (STDIO) — pick the server script with Browse…, or type a command such as npx, then add arguments
   • Remote (URL) — enter the endpoint, for example https://example.com/mcp
4. Choose how to authenticate:
   • Automatic (browser sign-in) — if the server answers 401, the inspector opens its sign-in page
   • Static header / token — add an Authorization header below; no sign-in flow starts
5. Remote, desktop only: if the server uses a private CA or mutual TLS, open the TLS section under Headers and use Browse… for the CA bundle, client certificate, and key. The paths are saved automatically.
6. Connect, choose a tool, fill in the fields, and run it.

Remote endpoints are tried as Streamable HTTP first, then SSE. A URL ending in /sse is tried as SSE first. The status line names the transport that worked.

Header values are kept in memory for the session and are not written to workspace storage, so header values do not end up on disk.

OAuth sign-in

Some remote servers answer 401 and require OAuth. Connect as usual: the inspector opens the server's sign-in page, waits for the redirect, and retries the connection when you finish. To skip sign-in, select Authentication → Static header / token and add an Authorization: Bearer … header.

Client registrations, PKCE verifiers, and tokens are kept in VS Code SecretStorage, scoped to the server's origin and path. They are never written to workspace files or webview state.

In VS Code for the Web, the server's OAuth endpoints must allow the editor's origin via CORS. If they do not, the built-in relay can proxy them; while proxying it can see the authorization code and token response but does not store or log them. See WEB.md for the relay flow, required CORS headers, and the static-token alternative.

Private CAs and client certificates

Remote servers that use a certificate from a private CA, or that require mutual TLS (mTLS), work in the desktop app. Open the TLS section under Headers and use Browse… for each file. The chosen paths are saved to settings, so they persist across sessions and stay visible in the Settings UI.

Example in settings.json:

{
  "mcp--inspector.tls.caFile": "/home/me/certs/internal-ca.pem",
  "mcp--inspector.tls.clientCertFile": "/home/me/certs/client.pem",
  "mcp--inspector.tls.clientKeyFile": "/home/me/certs/client-key.pem"
}

Only paths are stored. Certificate and key contents are read from disk when a connection starts and are never written to settings, workspace files, or SecretStorage. Server verification is never disabled: a private CA widens what is trusted, and an unconfigured server still fails.

The client certificate and key must be set together. TLS settings apply to Streamable HTTP, SSE, and the OAuth discovery and token requests those transports make.

These settings are desktop-only. In VS Code for the Web, the browser owns the TLS handshake: it trusts the operating system's certificate store and can offer a client certificate already installed there, but a web extension cannot supply a CA bundle or key file. See WEB.md.

Commands

Requirements

• Visual Studio Code 1.98.0 or newer

VS Code for the Web

MCP Inspector works in vscode.dev and github.dev for remote servers, using the same automatic Streamable HTTP / SSE detection. OAuth sign-in works there too; STDIO requires the desktop app or Codespaces.

If a server does not allow the browser origin, the inspector offers the open-source relay at https://mcp-relay.dhananjaay.dev. See WEB.md for CORS requirements, relay usage, localhost notes, and troubleshooting.

Contributing

Contributions are welcome. Read CONTRIBUTING.md for local setup, commit conventions, and the pull request process.

Known limitations

• TLS settings are desktop-only. In VS Code for the Web the browser owns the TLS handshake, so a private CA or client certificate cannot be supplied.
• STDIO servers require the desktop app or Codespaces.
• OAuth-protected servers in VS Code for the Web must allow the editor origin, or be used through the relay.
• Tool forms map top-level properties. Nested objects and arrays are edited as JSON, and oneOf/anyOf schemas fall back to a text field.
• One server connection at a time; multi-server workspaces are not supported yet.
• Tools are listed and called; prompts and resources are not exposed yet.

Report bugs and feature requests on the GitHub issue tracker.

License

MIT

Author

Dhananjay Senday

• Website: https://dhananjaay.dev
• Email: hello@dhananjaay.dev

Enjoy!