pyRPCRemote MCP servers sound like the obvious next step. Host the server, point agents at it, skip the local install entirely. But the ecosystem is not there yet, and pretending otherwise leads to integration dead ends. Here is what actually works, what does not, and why.
Claude Desktop refuses remote servers
Claude Desktop runs MCP servers locally over stdio. It does not connect to remote HTTP endpoints. This is a design decision, not a bug: Anthropic’s custom-connector model assumes the server runs on the user’s machine, under their control. If you host a remote MCP server and point Claude Desktop at it, it will not connect.
VS Code supports them natively
VS Code’s MCP integration includes a servers.http configuration that connects to remote endpoints. This is the one major client where remote servers work out of the box. Cursor also supports SSE transport, though the setup is less documented.
The auth gap
The MCP specification has no built-in authentication for HTTP servers. There is no OAuth flow, no API key handshake, no token exchange. The spec defines JSON-RPC over HTTP, period. This means any remote server either runs completely open or bolts on auth outside the protocol. Neither option is great for production use.
What read-only actually means
When we describe a remote MCP server as read-only, we mean the server serves static documentation, not your code. It can return framework references, API schemas, and configuration examples. It cannot import your routers, validate your payloads, or introspect your types. The data is public knowledge with no blast radius, which is exactly why auth matters less.
Rate limiting and availability
A hosted MCP server is infrastructure. Infrastructure has SLAs, cost curves, and failure modes. Rate limiting protects against abuse but also throttles legitimate use. Downtime means every connected agent loses context. For a documentation server this is manageable; for a code-introspection server it is a non-starter.
The two-server pattern
The practical architecture today is two servers with different trust profiles. The local server handles code introspection: it imports your routers, validates payloads, and regenerates clients. The remote server handles framework knowledge: it serves documentation, configuration patterns, and API references. Agents connect to both, but they serve different purposes and carry different privileges.
agent
|
+---> local stdio server (your code)
| - introspect_project
| - check_call
| - run_codegen
|
+---> remote HTTP server (docs)
- framework reference
- config examples
- API schemas
Why this is still better than copy-pasting docs
The alternative to a remote documentation server is stuffing docs into context windows manually. That approach burns tokens on every conversation, goes stale between copy-paste sessions, and has no structured query surface. A remote MCP server serves current documentation through a protocol the agent already speaks, with structured tool calls instead of raw text dumps.
The future
The MCP specification is evolving toward OAuth 2.0 support for HTTP servers. When that lands, remote servers can authenticate properly, which opens the door to hosted introspection servers with credential scoping. Registry servers that aggregate multiple MCP endpoints behind a single authenticated surface are also emerging. For now, the local-first, remote-for-docs pattern is the pragmatic choice.