In the previous post, I showed how to write a simple MCP server in just 17 lines of Python.

But we also saw that setting up the MCP server and making it available in Claude for Desktop can be tedious. Since we’re still in the early days of the protocol, the experience is rough around the edges — but it’s bound to get better.

One such improvement is the ability to remotely host MCP servers with authorization. Both remote hosting and authorization are already defined in the MCP spec. It’s just a matter of time before Claude for Desktop and other clients natively support them.

In this post, I’ll explain why remote MCP servers are the real deal — and why the local setup we’ve seen so far is just a glimpse of what MCP has to offer. I’ll also cover the challenges and considerations to keep in mind if you’re building a remote MCP server today, especially given how new this protocol still is.

Local MCP Servers Still Matter

Let’s not discard local MCP servers — in fact, they’re probably the best way to handle certain use cases that require direct access to the user’s machine. For example:

  1. Local command execution eg: iTerm, git
  2. Local file system access
  3. Local computer or browser control

These are incredibly powerful use cases. But they come with some setup complexity — requiring users to install and run additional software.

Why Remote MCP Is the Future

For everything else — especially cloud-based integrations — remote MCP servers will be far more practical and widely adopted. Why? Because they’re easier to deploy, simpler for users, and more scalable.

Remote MCP servers are ideal for integrating with:

Developers and companies can build purpose-specific AI agents and expose them to users as remote MCP servers. This unlocks a brand new category of software — and it’s clear that AI agents are going to be a major part of the future.

The State of Remote MCPs (as of April 2025)

If you’re building a remote MCP server today, here are a few things to keep in mind:

  1. Protocol Version & Transport: The original spec from November 2024 (2024-11-05) uses HTTP+SSE (Server-Sent Events) for persistent communication. This transport is supported by the official Python and TypeScript SDKs and is currently the most widely used.

  2. New Transport: Streamable HTTP: Unfortunately, HTTP+SSE is not ideal for production use due to its inefficiencies. The newer spec (2025-03-26) introduces Streamable HTTP, a significantly more efficient transport mechanism. However, it’s still so new that most SDKs haven’t added support for it in their stable releases. This updated spec also officially deprecates HTTP+SSE as the transport mechanism for remote MCP servers.

  3. Client Support Limitations: Neither HTTP+SSE nor Streamable HTTP are currently supported by Claude for Desktop. So if you want to use a remote MCP with Claude, you’ll need to run a local gateway that exposes the remote MCP as a local one. The good news: this isn’t as complex as it sounds.

The Bright Side: What’s Coming Soon

There’s plenty to be excited about:

  1. OAuth 2.0 Support: MCP now officially supports OAuth 2.0 for authorization — a robust, industry-standard protocol.

  2. MCP Server Registry: Anthropic is planning to launch an official MCP Server Registry. This will make it easy to discover new servers.

  3. Server Verification: The registry will likely include a verification process to help users avoid malicious or unofficial servers.

In summary, remote MCP servers are a game-changer. They unlock new types of integrations, simplify deployments, and pave the way for intelligent, agent-powered software. While we’re still early in the lifecycle of MCP, the progress so far is promising — and things are only going to get better from here.