How a Host Uses MCP Servers

Configure, initialise, expose, execute

A host reads its configuration (a list of servers: a command to launch for stdio, or a URL for HTTP, plus environment variables), starts or connects to each server, performs the initialize handshake, and calls tools/list (following pagination). It then merges the tool definitions into what the model can see, often prefixing names by server to avoid clashes. When the model requests a call, the host checks policy and asks the user if required, sends tools/call to the right client, and returns the result to the model. The host also handles list-changed notifications, reconnects, timeouts and cancellation. Good hosts let users enable or disable individual tools and servers.

Connect, expose, approve

A host connects to servers, shows the model a curated tool list and keeps the user in control.

A typical server configuration (illustrative)

The file format and location differ between hosts; the idea is a named server with a launch command and environment. Not run here.

{
  "mcpServers": {
    "orders": {
      "command": "python",
      "args": ["server.py"],
      "env": { "ORDERS_DB_URL": "<set via a secret store, not committed>" }
    },
    "docs": { "url": "https://mcp.example.com/docs" }
  }
}

Quick check: Why might a host prefix tool names with the server name?

• To train the model
• To compress tool descriptions
• To skip the handshake
• To avoid name clashes between servers