Config-driven Server management

This is where MCP's value becomes undeniable. Remember the M×N problem? We've solved it for a single server. Now let's scale to multiple servers and watch how adding a new data source becomes a single line in a config file.

Instead of hard-coding server connections, we'll use a server_config.json file. Each entry defines a server name and how to launch it. Want to add arXiv? Add 3 lines to the config. Want to remove Slack? Delete its entry. No code changes.

server_config.json
json
{
  "mcpServers": {
    "wikipedia": {
      "command": "uv",
      "args": ["run", "python", "servers/wikipedia-server-full-stdio.py"]
    },
    "arxiv": {
      "command": "uv",
      "args": ["run", "python", "servers/arxiv-server.py"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/allowed/path"]
    }
  }
}

Three servers configured. Each one launches with a command and arguments.

Multi-server architecture

One client reads the config, connects to all servers, and routes tools automatically.

When the client starts, it reads the config, connects to each server, calls list_tools() on each, and merges all tools into one list. The LLM sees tools from all servers at once. When it calls a tool, the client routes it to the right server automatically. No new schemas, no new functions, no new dispatchers.

Quiz: Quiz

Loading practice…