Skip to content

CONCEPT Cited by 1 source

MCP client-config fragmentation

Definition

MCP client-config fragmentation is the observation that every MCP-aware client (Claude Desktop, Cursor, Zed, VS Code, Windsurf, Neovim, …) stores its list of connected MCP servers in a different file, under a different config key, at a different path that often varies per-OS. An operator wiring one MCP server into N clients ends up editing N different JSON files by hand, which is the ergonomics tax Fly.io's fly mcp launch exists to eliminate.

Canonical wiki statement

From Fly.io's 2025-05-19 MCP launch post (Source: sources/2025-05-19-flyio-launching-mcp-servers-on-flyio):

"Next there is the configuration. Asking users to manually edit JSON seems so early 21th century. With Claude, this goes into ~/Library/Application Support/Claude/claude_desktop_config.json, and is found under a MCPServer key. With Zed, this file is in ~/.config/zed/settings.json and is found under a context_servers key. And some tools put these files in a different place depending on whether you are running on MacOS, Linux, or Windows."

The three axes of fragmentation

  1. Path fragmentation — each client has its own file. Claude Desktop uses ~/Library/Application Support/Claude/claude_desktop_config.json (macOS-specific); Zed uses ~/.config/zed/settings.json; Cursor / VS Code / Windsurf / Neovim each have their own again. There is no standard well-known location. No analog of ~/.ssh/config or ~/.aws/config has emerged.
  2. Schema fragmentation — the config key for the MCP server list is client-specific (MCPServer in Claude Desktop, context_servers in Zed, …). Even if the operator wrote a script to edit one file, the JSON structure to splice in differs per client.
  3. OS fragmentation — "some tools put these files in a different place depending on whether you are running on MacOS, Linux, or Windows." A cross-platform operator has to handle each permutation.

Why it matters

Fragmentation isn't a minor ergonomic complaint — it's a feature-adoption friction on MCP itself. An operator trying a new MCP server has to:

  1. read the server's README,
  2. find the right JSON config file for their editor,
  3. discover the right config key,
  4. write JSON into it (easy to get syntactically wrong),
  5. restart the client to pick it up,
  6. repeat (2)–(5) for each other editor / agent they also use.

This is exactly the friction that systems/fly-mcp-launch's --claude / --cursor / --zed / --vscode / --windsurf / --neovim selector flags paper over: one command, multi-client targeting supported, JSON rewrite handled by the tool.

Why there's no standard (yet)

MCP was "days away from turning six months old" at the time of the Fly.io post (2024-11 launch + 2025-05-19 post date). Client-config standardisation typically lags protocol standardisation; the fragmentation reflects early-ecosystem reality, not an intrinsic design failing. Draft proposals for MCP standardised discovery / config surfaces do exist — see the 2026-04 MCP Server Card /.well-known/mcp/server-card.json proposal — but those solve server-side discovery, not client-side config storage.

Relation to the local-vs-remote MCP server split

Local MCP servers require the client to launch a subprocess, so the config file needs command-line args + env vars; remote MCP servers (HTTP/Streamable-HTTP) only need a URL + auth. In practice both shapes end up in the same file, so fragmentation affects both — though the schema difference (command vs URL) adds a fourth axis of fragmentation on top.

Seen in

Last updated · 200 distilled / 1,178 read