Running One MCP Server Across Several Editors
The server itself is portable, because every compatible client speaks the same protocol and launches it the same way. What is not portable is the configuration file location, the default scope, and whether the client asks before calling a tool. Those three differences cause almost all cross-client surprises.
What travels and what does not
Teams rarely end up on one agent client. Someone prefers a terminal agent, someone else an editor integration, and a third person uses a desktop application for non-code work. That is fine, and it is exactly the situation the protocol was designed for.
The server travels. It is a program that speaks a defined protocol over standard input and output. Any compatible client can launch it. You do not install a per-client build, and there is no adapter to write.
The configuration does not. Each client keeps its own file, in its own location, with its own key names. The shape is consistent enough that entries look nearly identical, which is precisely why they drift: you fix a path in one place and forget the other two.
The scope defaults do not. One client may hand a server the current workspace root by default, another may pass nothing and expect an explicit argument. The same entry copied between them can end up granting a different boundary, which is the surprise worth watching for.
The approval behaviour does not. Some clients prompt before a tool call, some prompt only for tools marked as destructive, some do not prompt at all. This is a per-client policy and it is not part of the server.
The consequences worth planning for
Each client launches its own instance. If two clients are open, two copies of the server are running, each with its own memory and its own connections. For a stateless wrapper around an API this is invisible. For a server holding a cache, a session or a file lock, it is a genuine concurrency problem that nobody designed for, because the server was written imagining one caller.
Credentials get copied. The same key ends up in two or three configuration files. That multiplies where a secret lives and makes rotation something you have to remember to do everywhere. Referencing an environment variable rather than embedding the value keeps one copy.
Scope diverges quietly. A server pointed at one repository in one client and at a parent directory in another is a real difference in what an agent can reach, and nothing in either interface makes the discrepancy visible.
A server that assumes approval is unsafe in the client that does not prompt. If an operation is destructive, the safety has to live in the server as an explicit parameter the caller must set, not in the expectation that a human will see a dialog.
Do not rely on the prompt
This is the failure with the worst consequences and the least visibility. A server tested in a client that confirms every call feels safe. Installed in a client that does not, the same server executes the same operations unattended. Design destructive tools to require an explicit confirmation argument, which travels with the protocol, rather than a dialog, which does not.
Keeping several clients in step
A short practice that removes most of the drift.
Keep one canonical definition. A single file in the repository or in your dotfiles holding the servers, their arguments and the environment variables they need. Client configuration then points at it or is generated from it, rather than being maintained three times by hand.
Reference secrets, never embed them. Environment variables in the configuration and values in one place outside it. One rotation, not three.
Make scope explicit everywhere. Do not rely on any client's default root. Pass the directory argument in every entry so the boundary is the same regardless of which client launched it.
Test in the least protective client. If it behaves acceptably where nothing prompts, it is acceptable everywhere. Testing only in the client that confirms every call tells you very little.
Review when you add a client. A new agent is a new set of configuration entries, and the moment of adding it is when scope and secrets should be checked rather than copied.
One thing that genuinely is shared, and worth setting up once: the knowledge layer. Servers give each client access to systems, and each client separately has to work out what those systems mean. An index queried by all of them is grounding written once and used everywhere, which is the same argument the protocol makes about capability, applied to context.
Frequently asked questions
- Do you need a separate MCP server for each editor?
- No. The server is a program speaking a defined protocol over standard input and output, so any compatible client can launch the same one. There is no per-client build and no adapter to write. What differs is the configuration file, not the server.
- What actually differs between clients?
- Three things: where the configuration file lives and what its keys are called, what scope the client passes by default, and whether it prompts before a tool call. The third has the worst consequences, because a server tested where every call is confirmed behaves very differently where nothing is.
- What happens if two clients are open at once?
- Each launches its own instance of the server, so two independent copies run with their own memory and connections. For a stateless wrapper this is invisible. For a server holding a cache, a session or a file lock it is a concurrency problem nobody designed for.
- How do you stop configurations drifting apart?
- Keep one canonical definition of the servers, their arguments and their environment variables, and have client configuration reference or be generated from it. Reference secrets rather than embedding them, and pass scope arguments explicitly instead of relying on any client's default root.