Everything so far has been conceptual. This guide is the hands-on version: how a host application actually finds and talks to a server, what the two transports look like in practice, and how to get your first server running.
The config file pattern
Most MCP hosts - Claude Desktop, Claude Code, and most IDEs with MCP support - use a JSON config file that lists the servers to connect to on startup. A typical entry for a local server looks like this:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
}
}
}The host reads this file, launches each listed command as a subprocess, and creates an MCP client to talk to it. That's the entire setup for a local server - no network configuration, no ports to open.
stdio: the local transport
stdio (standard input/output) is how local servers communicate: the host launches the server as a child process, and the two exchange JSON-RPC messages over the process's stdin and stdout pipes. There's no networking involved at all - it's the same mechanism any two programs on your machine use to pipe data to each other. This is why stdio servers are simple to set up (the command above) but also why they only make sense for things running on the same machine as the host.
Streamable HTTP: the remote transport
When a server lives elsewhere - a company's internal system, a hosted third-party service - the host connects over the network instead, using Streamable HTTP. This transport replaced the earlier SSE-based approach in the current spec, and it's built to support the same kind of long-running, multi-message exchanges a local stdio connection allows, just over HTTP instead of a pipe. A remote server entry in a config file points at a URL rather than a local command:
{
"mcpServers": {
"internal-crm": {
"url": "https://mcp.yourcompany.com/sse",
"transport": "http"
}
}
}stdio: a pipe to a process on your own machine. Streamable HTTP: a network call to a server elsewhere, typically authenticated with OAuth.
Authentication for remote servers
Since remote servers are frequently gatekeeping real production systems rather than local files, the spec recommends OAuth for authenticating to them - the host walks the user through an OAuth flow the first time it connects, and the resulting token is what authorizes subsequent tool calls. This means connecting a remote server usually involves a one-time browser-based sign-in step, not a static API key pasted into a config file, though some servers still support simpler API-key auth for internal or low-stakes use cases.
A practical first connection
The lowest-friction way to try MCP for the first time is a local, stdio-based server that doesn't need any credentials - a filesystem server pointed at a project folder, for example. From there, the pattern for adding any new server is always the same: find the server (there's a large public directory of them), add an entry to your host's config file pointing at it, restart the host, and the new tools show up automatically in the next conversation.