MCP Linker: a desktop manager for MCP server configs across Claude Code, Cursor and other clients

The problem: the same MCP server, declared four different ways

Model Context Protocol servers are configured per client. The README describes MCP as "like USB-C for AI", a standard way to connect models to data sources and tools, but the standard covers the wire protocol, not the file where each client expects to find the server list. Claude Desktop, Claude Code, Cursor, VS Code, Cline, Windsurf, Codex and Roo Code are all listed as supported clients, and each keeps its own configuration. Adding one server by hand means repeating the same JSON or TOML snippet in several places, then repeating it again when the server's command or environment changes.

MCP Linker targets that duplication directly. It is a desktop application, not a CLI or a library, so the person it is for is an individual developer who runs a graphical environment and wants to add a server once. The README's own workflow is four steps: browse the marketplace, click Get to see the configuration, click Add to install it into the selected client, then use the client. Nothing in that flow requires an LLM call, which the README states explicitly as a selling point.

How the sync works: a registry browser plus per-client config writers

The architecture visible in the repository is a Tauri shell around a React front end. The package description in package.json calls it "A cross-platform desktop manager for MCP servers and client using Tauri + React", and the dependency list is dominated by Radix UI primitives, TanStack Query and TanStack Table, with the Tauri plugins for clipboard, deep link, dialog, log, opener, OS and process forming the native side. The front end is built with Vite; src-tauri holds the Rust side.

The data flow implied by that layout is: the React UI queries a registry for server metadata, renders it in a table, and the Tauri layer performs the local file operations and environment detection. The registry endpoint is configurable. The .env.example file defines a single variable, VITE_REGISTRY_BASE_URL, defaulting to https://registry.modelcontextprotocol.io, and the README names that same host as the Official MCP Registry. So the discovery half of the app is not a curated list owned by the project; it is a client for a registry you can point elsewhere.

The second half is client-specific. The README says the app supports Claude Desktop and Claude Code, Cursor, VS Code, Cline, Windsurf, Codex and Roo Code, and points to docs/clients.md for the detail. That document is where the per-client file paths and formats would live, and it is the file to read before trusting the sync to write into the right place. The README also mentions smart detection of Python, Node.js and uv environments, which matters because MCP servers are commonly launched as local processes whose interpreter or runtime must already exist on the machine.

Installing MCP Linker and adding your first server

The README gives three installation routes. On Arch Linux the package is in the AUR:

yay -S mcp-linker-bin

On macOS there is a Homebrew cask:

brew install --cask milisp/mcp-linker/mcp-linker

For Windows, Linux and macOS without a package manager, the README points to the Releases page on GitHub for a direct download. Note the README's own caveat: if you have subscribed, relaunch the app after logging in for the first time.

Once the app is open, the documented flow is: browse the marketplace, click Get on a server to reveal its configuration, click Add to install it into the client you selected, then start the client. There is no command to run for this part; it is all in the GUI. What you should see after clicking Add is the server appearing in the target client's configuration, and the README's screenshots show a Discover view and an Add server view as the two main surfaces.

If you want to point the marketplace at a different registry, the .env.example file is the place:

VITE_REGISTRY_BASE_URL=https://registry.modelcontextprotocol.io

That variable is read at build time because of the VITE_ prefix, so changing it means rebuilding the front end rather than editing a runtime setting. That is a real constraint for anyone hoping to switch registries on an installed binary.

For development, package.json exposes the standard Vite and Tauri scripts:

bun install
bun run tauri dev

The README defers development commands and contribution guidance to CONTRIBUTING.md, so treat that file as the authority rather than the scripts listed above.

Where MCP Linker is the wrong tool

The clearest limitation is that this is a desktop GUI. The README's entire getting-started path runs through clicking buttons in a window. There is no documented headless mode, no documented CLI, and no documented configuration file that would let you provision MCP servers on a build machine, in CI, or on a remote host. If your team wants server configuration to be part of a repository, reviewed in a pull request and applied by a script, this app does not appear to offer that path.

The registry dependency is the second constraint. Discovery comes from registry.modelcontextprotocol.io by default. If a server you need is not in that registry, the marketplace will not surface it, and the README does not document a manual entry flow for arbitrary servers outside the registry. The README also does not document rollback: adding a server writes into a client's configuration, and there is no described undo, backup or diff step before the write. That is the failure mode to think about, because a bad write into a client config can leave that client unable to start until you repair the file by hand.

Finally, the licensing is a genuine gate rather than a footnote. The README states the project is dual-licensed under AGPL-3.0 and a Commercial License, with the commercial licence "required for closed-source, proprietary, hosted, or SaaS use". Anyone evaluating this as a component of a product rather than as a personal tool needs to read that sentence twice.

Alternatives and how they differ in approach

The README lists two sibling projects by the same author. milisp/codexia is described as "The missing GUI for the OpenAI Codex CLI" with a file tree, notepad, git diff and plan mode, in a lightweight Tauri desktop app. That is a different product with a different job: it wraps one client rather than synchronising configuration across many. MCP Linker also advertises a GUI for the OpenAI Codex CLI based on Codexia, so the two overlap in that one corner and diverge everywhere else.

The other listed project, claw-army/claude-node, is a Python subprocess bridge for the Claude Code CLI that gives Python code access to Claude Code native capabilities via stream-json. That is a programmatic integration, not a configuration manager, and it solves a different problem: calling into a client from code rather than deciding which servers that client should load.

Against the broader category, the meaningful difference is the built-in marketplace. A hand-maintained dotfile repository can sync MCP configs across machines, and it is fully scriptable, but it does not know what servers exist or how to configure them; you write every entry yourself. MCP Linker inverts that: it knows about servers through the registry and writes the client files for you, at the cost of being interactive and GUI-bound. The project's own framing, "No LLM calls needed", is a positioning choice against tools that route server selection through a model, and it means the app's behaviour is deterministic given the registry contents.

Maintenance, releases and what the licence costs you

The repository is not archived, and the last push was on 2026-09-09, which is recent. The release cadence visible in the repository is uneven: v2.2.0 on 2026-05-01, v2.2.2 on 2026-05-17, then v2.2.3 on 2026-08-17, a three-month gap. package.json carries version 2.2.3, matching the newest release. The repository ships a CHANGELOG.md, so upgrade impact is at least documented somewhere, though the README does not describe an in-app update mechanism or an auto-update channel. On macOS the Homebrew cask gives you the usual upgrade path; on Arch the AUR package does; on Windows and Linux direct downloads you are replacing a binary yourself.

The upgrade cost that actually bites is not the app, it is the client configs it writes. Each supported client can change its configuration format independently, and docs/clients.md is where the project would track that. If a client changes format and the app has not caught up, the sync writes something the client rejects.

On licensing: AGPL-3.0 applies to open-source use, and the README states a Commercial License is required for closed-source, proprietary, hosted or SaaS use. package.json records the licence field as "AGPL-3.0, Commercial". The practical consequence is that bundling this app into a proprietary product, or hosting it as a service, is the case the commercial licence exists for. That is a statement about what the project requires, not legal advice; the terms themselves and any obligations they create are for you and your counsel to read.

Editorial conclusion

Adopt MCP Linker if you run two or more MCP-capable clients on the same machine and are tired of hand-editing each client's config file, and if AGPL-3.0 or a commercial licence is acceptable for how you use it. Do not adopt it if you need a headless or server-side configuration pipeline, or if you cannot take the AGPL-3.0 terms and do not want to buy the commercial licence. Before committing, verify three things on your own machine: that the clients you actually use appear in docs/clients.md, that your Python, Node.js and uv environments are detected correctly by the smart detection step, and that a single test server added through the app lands in the config file of each client you expect.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. milisp/mcp-linker on GitHub
3. Project website
4. README
5. Releases