MCP in the Real World

A server on your laptop is one thing. A server that a whole company uses is another. There are two ways to connect, and the choice depends on where the server runs.

• A server on your laptop
• A server for a company
• Two ways to connect

Connecting apps to servers

Most MCP apps use a small settings file like this one. A local server is started as a program, and it talks through standard input and output. A remote server is just a web address, with a token. Note how the token comes from an environment variable, so it never sits in the file. Add one entry, and the app gets all of those tools.

{
  "mcpServers": {
    "velo-supply": {
      "command": "python",
      "args": ["server.py"]
    },
    "github": {
      "url": "https://example.com/mcp",
      "headers": {"Authorization": "Bearer ${GITHUB_TOKEN}"}
    }
  }
}

Local or remote?

Which transport should you use? Standard IO suits local tools, such as reading your files, with no network involved. HTTP suits shared services, with proper logins, and it can scale across many users. Companies usually host remote servers behind a gateway, so that they can control who uses what.

The 2026 update

The specification keeps moving. The revision dated July twenty twenty six was the biggest yet. It made the protocol stateless, removing the opening handshake, so that each request stands alone. That makes servers far easier to scale behind load balancers. It added a formal extensions framework, and tightened authorisation. Always check the current spec, because this area is changing quickly.

Summary