Your first connection: running an existing server

Before you write a server, connect to one. The fastest way to build intuition is to run an existing server in a real client and watch its tools appear.

Most hosts read a small JSON config that lists servers to launch. In Claude Desktop, it's claude_desktop_config.json (on macOS at ~/Library/Application Support/Claude/, on Windows at %APPDATA%\\Claude\\). A local server entry looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Desktop"]
    }
  }
}

That tells the host: launch this command, talk to it over stdio, and treat whatever it exposes as available tools and resources. Add an env block if the server needs API keys. Restart the host to load it — in the current UI, connected servers appear under the "+" (Add connectors) menu.

What you'll observe is the whole point of the lesson: the host calls tools/list, the server answers with its tool definitions, and those tools now show up for the model to use. You didn't write integration code — you dropped in a config entry and the standard did the rest. That's the M+N promise made concrete.

For remote servers, the flow is similar but you paste an https://.../mcp URL as a custom connector and complete an OAuth sign-in; the host then talks Streamable HTTP to it.

A reference catalog of open-source servers lives in the official modelcontextprotocol/servers repository — filesystem, fetch, git, and more — so you can experiment with several before building your own.

Play with one now. Ask the model to use a tool the server exposes, and notice that the model decided when to call it while you granted the connection. That division — model chooses the action, you authorize the capability — is the heartbeat of everything that follows, especially when we get to security.