MCP Config Management Is Broken - Why We Need an App Store for AI Integrations
MCP Config Management Is Broken
The Model Context Protocol is a good idea that landed with rough edges on the developer experience side. MCP gives AI agents a standardized way to connect to tools and data sources - one protocol, any LLM, any tool. In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, and by early 2026 it had become the de facto standard for agent-to-tool connectivity with adoption from Anthropic, OpenAI, Google DeepMind, Microsoft, and AWS.
The protocol is solid. Setting up and managing MCP servers is painful.
A post in r/modelcontextprotocol describing an "App Store for AI Integrations" got significant traction because the frustration is universal: everyone who runs more than a handful of MCP servers has hit the same wall.
What the Config Problem Actually Looks Like
A realistic desktop automation agent connects to: GitHub (for code and PR management), Slack or Discord (for team communication), a database (for structured data), a file system server (for local files), a calendar API, a browser automation server, and possibly several internal tools.
That is eight MCP servers before you have done anything exotic. Here is what the Claude Desktop config looks like for eight servers:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>"
}
},
"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "<your-token>",
"SLACK_TEAM_ID": "<your-team>"
}
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres",
"postgresql://user:pass@localhost/db"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem",
"/Users/matt/Documents", "/Users/matt/Projects"]
},
"brave-search": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "<your-key>"
}
}
}
}
This is the simplified version. Production configs get longer. When a server is misconfigured, the error messages range from unhelpful to absent. When an npm package updates and breaks something, you find out when a capability silently stops working. When you set up a new machine, you manually reproduce all of this from scratch.
The friction is real and it discourages people from setting up integrations they would otherwise find valuable.
What the MCP Registry Is Doing About It
The MCP Registry - launched in September 2025 and approaching 2,000 entries - is the first step toward the app store model. It provides a central index of available MCP servers with documentation, ratings, and installation information.
The 2026 MCP roadmap published by Anthropic in March 2026 makes discoverability and developer experience a top priority. The planned improvements include:
- Standardized server manifests that describe capabilities, required auth, and configuration parameters in a machine-readable format
- OAuth 2.1 support for servers that need user authentication, eliminating the manual token management step
- A configuration portability standard so configs can be exported and imported across machines without manual editing
- Better error reporting when servers fail to connect or return unexpected responses
The OAuth 2.1 flow is particularly significant. Right now, setting up a GitHub MCP server means generating a personal access token, copying it into a config file, and hoping you saved it somewhere secure. With OAuth 2.1, the setup flow becomes: click authorize, complete the standard consent screen, done. The token management is handled by the protocol rather than by the user.
The App Store Model Comparison
The difference between current MCP setup and an app store model is the same gap that package managers filled for software development.
Before npm, installing a JavaScript library meant downloading a tarball, extracting it, copying files into your project, and manually managing transitive dependencies. After npm: npm install <package>, done.
Before Homebrew, installing a macOS CLI tool meant finding the source, running configure/make/install, and figuring out dependencies. After Homebrew: brew install <tool>, done.
An MCP app store would turn "find GitHub's MCP server on GitHub, read the README, copy the JSON snippet, install dependencies, debug connection issues, handle token rotation" into: search for GitHub in the MCP store, click install, authorize with OAuth, done.
The building blocks for this exist. The MCP Registry provides discovery. OAuth 2.1 support handles auth. Server manifests handle configuration. What remains is a client-side application layer that assembles these into a user-facing install flow.
Several teams are building in this direction. The challenge is that MCP clients (Claude Desktop, Cursor, IDEs, custom agents) each have their own config formats and install flows, so an app store UI has to either integrate with each client separately or provide a config-generation layer that outputs the right format for each target.
The Desktop Agent Angle
For desktop agents like Fazm, MCP is one integration path among several. The macOS Accessibility API gives agents direct semantic access to application state - which UI elements are present, what their labels say, how they respond to interaction - without requiring those applications to have an MCP server.
This is significant because MCP servers only exist for applications and services that someone has built one for. The Accessibility API covers every macOS application by default. You do not need to find, install, or configure an MCP server to interact with your email client, your browser, your code editor, or any other macOS app. The OS provides the access directly.
The fewer MCP servers, better results principle matters here: MCP adds value for backend services that do not have desktop UIs - databases, APIs, internal tools, external services. For applications with a GUI, the Accessibility API is usually the better integration path - more reliable, no configuration required, works with any application regardless of whether an MCP server exists for it.
The ideal desktop agent architecture: Accessibility API for application interaction, a small curated set of MCP servers for the backend services the Accessibility API cannot reach, and (eventually) an app store for discovering and installing those MCP servers without manual JSON editing.
Managing MCP Configs Today
Until the app store model arrives, practical config management:
Version control your config files. Keep claude_desktop_config.json in a dotfiles repository. When you set up a new machine, git clone replaces the manual reconstruction step.
Use environment variables for all secrets. Never put tokens directly in config files. Reference them as $GITHUB_TOKEN in the config and store actual values in your password manager or system keychain. This prevents accidentally committing credentials and makes rotation easier.
Keep a setup script. A shell script that installs the npm packages for each server and sets the environment variables takes 10 minutes to write and saves hours on each new machine setup.
#!/bin/bash
# setup-mcp.sh
npm install -g @modelcontextprotocol/server-github
npm install -g @modelcontextprotocol/server-slack
npm install -g @modelcontextprotocol/server-filesystem
echo "Set GITHUB_PERSONAL_ACCESS_TOKEN, SLACK_BOT_TOKEN in your environment"
Test servers individually before adding them to production config. npx @modelcontextprotocol/server-github in isolation tells you quickly whether the package installs and connects correctly before you add it to a config that affects everything else.
The app store will arrive. The protocol is already the standard; the tooling is catching up. In the meantime, version control and scripted setup are the practical alternatives to rebuilding from scratch every time.
Fazm is an open source macOS AI agent. Open source on GitHub.