How many MCP servers are in your config right now? Three? Five? Ten?

Every new MCP server means the same ritual: find the package name, figure out the command and args, paste in API keys, hand-edit a JSON config, restart your client, and pray it works. Repeat for every server on every machine.

This is the number one friction point in MCP adoption. Not the protocol, not the spec, not the servers themselves - the config management. And it is about to get much worse as the ecosystem grows.

The problem nobody is solving

MCP clients like Claude Code, Cursor, and Claude Desktop all use the same pattern: a JSON config file that lists every server you want to use. Something like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_TOKEN": "xoxb-..." }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgres://..." }
    }
  }
}

Three servers, three sets of credentials, three things that can break. And this is a simple setup. Power users have ten or more. Each one bloats the config, loads every tool into context on startup, and wastes tokens on tools the LLM does not need right now.

Nobody should have to be a systems administrator to use AI tools.

What if you only had to configure one thing?

mcp.hosting is one MCP server that orchestrates all your other MCP servers. Your config becomes this:

{
  "mcpServers": {
    "mcp.hosting": {
      "command": "npx",
      "args": ["-y", "@yawlabs/mcph"],
      "env": {
        "MCPH_TOKEN": "mcp_pat_..."
      }
    }
  }
}

Don’t want to hand-edit JSON? Run npx -y @yawlabs/mcph install <client> --token mcp_pat_... in any terminal - mcph picks the right config file for Claude Code, Claude Desktop, Cursor, or VS Code, merges the launch entry without clobbering anything you already have, and seeds ~/.mcph.json so every other MCP client on the machine inherits the token.

One server. One token. Everything else is managed from the mcp.hosting dashboard.

How it works

mcph runs locally on your machine as a standard MCP server over stdio. On startup, it pulls your server config from the cloud. It exposes three meta-tools to the LLM:

  1. discover - List all your configured servers and their status
  2. activate - Connect to a server and load its tools into context
  3. deactivate - Disconnect a server and remove its tools

When you activate a server, mcph spawns it locally (for stdio servers) or connects via HTTP (for remote servers), fetches its tool list, namespaces each tool to avoid collisions, and sends a tools/list_changed notification so your client picks up the new tools immediately.

When you are done with a server, deactivate it. The tools disappear from context. No more burning tokens on 200 tool descriptions when you only need 5.

Context optimization matters

Here is the math. Each MCP tool definition is roughly 200–500 tokens (name, description, input schema, annotations). Ten MCP servers with 20 tools each is 200 tools. At 300 tokens per tool, that is 60,000 tokens of tool definitions loaded into every conversation - before you have even asked a question.

With mcph, you start with 3 tools (discover, activate, deactivate). You activate what you need, when you need it. A typical conversation might use 2–3 servers and 30–50 tools instead of 200.

Cloud-managed config

The real magic is not the orchestration - it is that you never edit a JSON config again.

This is what package managers did for dependencies. This is what app stores did for mobile apps. mcp.hosting does it for MCP servers.

Pricing

Free for up to 3 servers. $9/month for unlimited servers and routing analytics. The free tier costs us almost nothing since the compute runs on your machine - we just sync the config.

Get started

  1. Sign up at mcp.hosting and add your servers
  2. Create a token in Settings
  3. Run npx -y @yawlabs/mcph install <your-client> --token mcp_pat_... (or paste the snippet above into your client’s config by hand)
  4. Restart your MCP client and ask your LLM to discover your servers

That is it. Stop juggling MCP servers. Let the orchestrator handle it.

Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.