OpenMCP: a VS Code plugin that pairs an MCP inspector with a client SDK

The gap OpenMCP targets: inspecting an MCP server and then talking to it

An MCP server exposes tools, prompts and resources over a protocol, and the usual way to check one is to wire it into a host application and watch what the host does with it. That loop is slow when the thing you are debugging is the server itself. OpenMCP's stated purpose is to close it: the README calls the project an all-in-one VS Code, Trae and Cursor plugin for MCP server debugging, and the openmcpent module is described as an integrated inspector plus MCP client basic functions, combining development and testing into one. The intended user is the person writing the MCP server, not the person consuming one. If you only need to call someone else's MCP server from an agent you are shipping, the inspector half of this project is weight you will not use.

How the plugin is put together: renderer, service, host

The project concept section gives a layered diagram with two core components, a Renderer and an OpenMCPService, reused across four targets: OpenMCP Web behind Nginx, the OpenMCP Plugin inside VS Code plugin code, an Electron-based OpenMCP App, and an OpenMCP-based QQ bot built on Lagrange.OneBot. The same service layer is meant to sit under each host, with only the outer shell changing. That explains why the repository is TypeScript and why the extension is not the only consumer of the code. It also sets an expectation you should test for yourself: features described for the plugin may be implemented in the service layer and surfaced differently in the web or Electron builds. The roadmap table names modules explicitly (`render`, `ext`, `service`, `all`), which is a more useful map of where a feature lives than the marketing copy.

Testing tools, prompts and resources before you let a model near them

The inspector is the part with the clearest workflow. The README shows screens for testing MCP tools, prompts and resources, and states that tools verified there can be moved into an interactive testing module for large model interaction testing. Project and global management panels handle MCP project configuration at both scopes, and the roadmap marks support for debugging multiple MCP servers simultaneously as complete. The client side supports DeepSeek, OpenAI, Qwen, Gemini, Grok, Mistral, MiniMax, Groq, Perplexity, Kimi, Ollama, OpenRouter and more, with an XML mode and customised options for tool selection. Custom OpenAI-compatible endpoints are marked done in the roadmap; a custom protocol integration is listed at 0%. If your model provider is not on that list and does not speak the OpenAI-compatible shape, the chat half of the plugin is not for you yet.

From debugged config to a running agent with openmcp-sdk

The second half is a separate npm package. The README gives this command: `npm install openmcp-sdk`. The example imports `OmAgent` from `openmcp-sdk/service/sdk`, constructs it, loads a config with `agent.loadMcpConfig('./mcpconfig.json')`, reads a prompt with `agent.getPrompt('hacknews', { topn: '5' })`, and runs `agent.ainvoke({ messages: prompt })`. The README states that the config can be generated automatically after debugging with the openmcp client, which is the real link between the two halves: the inspector produces the file the SDK consumes, so the prompt you tuned by hand is the prompt that ships. The sample output in the README shows a crawl4ai-mcp server connecting, the agent choosing `get_web_markdown` several times in a row, and a formatted response. Treat that transcript as documentation, not as a benchmark.

What the roadmap admits is missing

The feature roadmap is the most honest part of the repository, and it is where the adoption decision gets made. Three items sit at 0%: high-risk operation permission confirmation, MCP security checks to prevent prompt injection, and hot update for connected MCP servers. The first two matter because the plugin's whole job is to let a model call tools you are still writing, and an inspector that executes tool calls without a confirmation gate is a tool you point at servers you trust. The third matters for iteration speed: if connected servers cannot be hot-updated, expect to restart the connection each time you change server code. Tool-wise logging is also at 0%, so when a call goes wrong the plugin gives you less diagnostic detail than you would want. None of these are surprising for a project at v0.1.x, but they are the difference between a demo and a daily driver.

The alternative: MCP Inspector and a separate agent framework

The obvious comparison is the official MCP Inspector, which the Model Context Protocol project ships for the same purpose. The difference in approach is scope. Inspector is a debugging surface for a server: you point it at a server and exercise its tools, prompts and resources. OpenMCP adds the client half, so the same panel that tested a tool also runs it against one of the listed LLM providers and then exports a config for `openmcp-sdk`. That is convenient if you intend to ship an agent, and irrelevant if you only want to confirm a server behaves. The other alternative is to skip the plugin and wire the server into a general agent framework directly, keeping the debugging surface separate. You get a mature toolchain for the agent side and lose the single-panel loop where a prompt tuned in the inspector becomes the prompt in production.

Licence, releases and what maintenance looks like

The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires you to preserve notices and state changes. That is a permissive licence, but it is not legal advice and you should read the LICENSE file in the version you pin. The release history is short and the cadence is uneven: v0.1.11 in July 2025, v0.1.12 in August, v0.1.13 in October, with the default branch receiving commits into 2026. A three-release, v0.1.x line means APIs in `openmcp-sdk` can move between versions, so pin the SDK version in your `package.json` rather than tracking latest, and re-read the changelog before bumping. The plugin and the SDK version independently, which is a second pin to track. There is no published support commitment in the material; the README points to a QQ group, a Discord channel and an email address for contact.

Editorial conclusion

Adopt OpenMCP if you are building or debugging MCP servers in VS Code, Trae or Cursor and want the inspector and the chat client in the same panel, then plan to move the verified config into openmcp-sdk. Do not adopt it if you need prompt-injection guards, high-risk tool confirmation or hot reload of connected servers today: the roadmap lists all three at 0%. Before installing, verify the extension against your editor version, check what the client does with your API keys for the LLM providers you select, and confirm the Apache-2.0 terms of the version you pin.

Official sources

1. License: Apache-2.0
2. LSTM-Kirigaya/openmcp-client on GitHub
3. Project website
4. README
5. Releases