OpenMCP: a VS Code plugin for MCP server debugging and agent deployment

What OpenMCP actually solves for MCP server authors

Writing an MCP server is only half the job. The other half is confirming that the tools, prompts and resources you exposed behave the way a model will use them, and that means having a client that can call each primitive directly, show you the raw result, and then replay the same call through a model. OpenMCP is an attempt to put both halves in one editor window. The README describes it as "An all-in-one vscode/trae/cursor plugin for MCP server debugging", so the target user is someone who already has a server process and needs to interrogate it.

The plugin ships an inspector for tools, prompts and resources, a project-level management panel for MCP projects at both project and global scope, and a chat module where tools you have already tested are moved into what the README calls "Interactive Testing" for large model interaction. The chat side lists DeepSeek, OpenAI, Qwen, Gemini, Grok, Mistral, MiniMax, Groq, Perplexity, Kimi, Ollama and OpenRouter, plus custom OpenAI-compatible endpoints. That list matters more than it looks: if your only credential is for a provider that is not on it, the chat half of the plugin is dead weight and you are left with the inspector.

The second audience is people who have finished debugging and now want to ship. The repository contains an sdk/ directory and a separate npm package, openmcp-sdk, whose README example shows an OmAgent class loading an mcpconfig.json file that the client can generate during debugging. That is the real pitch: the artifact you produce while testing is the artifact you deploy.

The layered renderer and service split behind the plugin

The README's architecture diagram is the clearest statement of how the project is built. It defines two core components, a Renderer and an OpenMCPService, and then assembles them into four targets: OpenMCP Web behind Nginx, the OpenMCP Plugin with VS Code plugin code, an OpenMCP App with Electron code, and an OpenMCP-based QQ Bot that pairs Lagrange.OneBot with the service. The service layer is the part that talks to MCP servers and to model providers; the renderer is the UI that gets swapped per platform.

That split explains several things about the repository layout. There are separate top-level directories for renderer/, service/, gateway/, sdk/, cli/, servers/ and software/, and the build is driven by turbo.json with esbuild.config.js and a rollup.tesseract.js alongside it. The presence of rollup.tesseract.js lines up with the roadmap entry marking built-in OCR as 100% done, so character recognition is bundled into the extension rather than fetched at runtime.

The practical consequence for an adopter is that the VS Code extension is not the only consumer of the service code. If you find a bug in how a tool call is dispatched, it may live in code shared with the web and Electron builds, and a fix there has to survive all three. The upside is that the same debugging session model is intended to work outside VS Code. The README's roadmap table confirms the project tracks modules by name (all, render, ext, service) with priority labels like Full Version, Iteration and MVP, and several service entries sit at 0%.

Installing OpenMCP and running a first tool call

The README does not give an install command for the extension itself; it points to the official documentation site at openmcp.kirigaya.cn and to a full video walkthrough. What the repository does tell you is the host requirement: package.json declares engines.vscode as ^1.95.0, so the extension will not activate on an older VS Code, and the README claims Trae and Cursor as supported hosts. The extension's main entry is ./dist/extension.cjs.js and its commands are namespaced under openmcp, for example openmcp.showOpenMCP and openmcp.sidebar.workspace-connection.addConnection.

Once the extension is installed, the repository's own screenshots show the sequence: before-click.png, after-click-connect.png, after-refresh.png, before-build.png and after-build.png. The management panel is where you register a server, and the inspector is where you exercise it. The README states that tested tools can then be placed in the "Interactive Testing" module for large model interaction testing.

The deployment half is documented with a concrete npm install and a short TypeScript program. The README gives this example, and the import path is worth reading carefully because it points at a service subpath rather than the package root:

npm install openmcp-sdk

import { OmAgent } from 'openmcp-sdk/service/sdk';

// create Agent
const agent = new OmAgent();

// Load configuration, which can be automatically generated after debugging with openmcp client
agent.loadMcpConfig('./mcpconfig.json');

// Read the debugged prompt
const prompt = await agent.getPrompt('hacknews', { topn: '5' });

// Execute the task
const res = await agent.ainvoke({ messages: prompt });

console.log('⚙️ Agent Response', res);

The README shows the expected console output: a connection line for a crawl4ai-mcp server at version 1.9.1, then repeated lines reporting that the agent wants to use get_web_markdown, that the tool is being used, and that the tool call succeeded, followed by the agent's response. If you run this and see no connection line, the mcpconfig.json path or the server command inside it is the first thing to check, because loadMcpConfig is what establishes the connection.

Where OpenMCP is the wrong tool

The roadmap is unusually honest about what is missing, and two entries should stop some readers immediately. High-risk operation permission confirmation is listed at 0% with MVP priority, and MCP security checks to prevent prompt injection are also at 0%. If your MCP server can write files, spend money, or call an internal API, OpenMCP as it stands gives you no documented gate between a model's decision and that side effect. The inspector will happily call the tool; the chat module will let a model choose it.

Hot update for connected MCP servers is also at 0%. The README does not document rollback either, so once a server is connected and a session is underway, the documented path is to work with the configuration you loaded. For a server you are actively editing, that means reconnecting by hand rather than expecting the plugin to pick up a rebuilt binary.

There is a second, quieter limitation. The project is a plugin, not a library you embed. If your team does not use VS Code, Trae or Cursor, the inspector and chat panel are unavailable, and you are left with openmcp-sdk, which is a separate package with its own documentation. The README's own framing, "once everything is tested and verified in openmcpent, you can deploy your mcp as an agent app with openmcp-sdk", makes the dependency explicit: the SDK is downstream of the editor experience, not a replacement for it.

OpenMCP against a plain inspector such as FastMCP

The most common alternative for this job is a Python-side MCP framework with its own inspector, and FastMCP is the name that comes up in search alongside this project. The difference is where the work happens. FastMCP is a server framework first: you define tools in Python, and the inspector is a window onto the server you just wrote. OpenMCP is a client first: it assumes a server exists, whether you wrote it in TypeScript, Python or anything else, and gives you a host to call it from.

That distinction changes what you get. With a server-side framework you get decorators, type-driven schema generation and a test harness that understands your own code. With OpenMCP you get a provider-agnostic chat panel, a project-level management panel for multiple MCP servers, and an export path into a TypeScript agent through openmcp-sdk. The README's roadmap lists simultaneous debugging of multiple MCP Servers at 100%, which is the capability a server-side inspector usually does not emphasize.

The trade-off is language gravity. OpenMCP's SDK is TypeScript, published as openmcp-sdk, and the deployment example is TypeScript. If your agent runtime is Python, the debugging half of OpenMCP still works because it speaks MCP, but the deployment half does not match your stack, and you will be reimplementing the agent loop in your own language.

Licence, maintenance and what an upgrade costs

The repository is licensed Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. Apache-2.0 also requires that you preserve copyright and licence notices and state significant changes when you redistribute. The repository carries a SECURITY.md, so there is a documented channel for reporting problems, though the README does not describe a response commitment. None of this is legal advice; if you are redistributing a modified build, read the licence text itself.

The last push to the default branch was on 2026-06-04, and the repository is not archived. The most recent release listed is v0.1.13 from 2025-10-21, while package.json declares version 0.1.14, so the manifest is ahead of the published release list. That gap is worth knowing before you file a bug: the behaviour you see in a marketplace build may not match the source tree.

Upgrade cost is mostly configuration, not code. The extension contributes a small command surface under the openmcp namespace and declares an empty configuration.properties object, so there are no documented settings keys to migrate. The real coupling is the mcpconfig.json that openmcp-sdk loads and the prompt names your agent calls through getPrompt. If a server rename changes a prompt name, the agent breaks at runtime, and nothing in the README describes a validation step for that. The project also ships localisation files for English, Simplified Chinese and Japanese (package.nls.json, package.nls.zh-cn.json, package.nls.ja.json), so command titles will follow your editor locale.

Editorial conclusion

Adopt OpenMCP if you are writing MCP servers in TypeScript and want the inspector, the chat panel and the generated mcpconfig.json in one place. Do not adopt it if you need a hardened runtime: the roadmap lists high-risk operation permission confirmation and MCP security checks as 0% done, and the README does not document rollback for connected servers. Before committing, verify that your VS Code is at 1.95.0 or newer, that the model you intend to use is reachable through the plugin's provider list, and that openmcp-sdk's OmAgent fits how your agent loads configuration.

Frequently asked questions

Official sources

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