How to connect a remote MCP server from a browser

Classic MCP servers run as local subprocesses. You install a package, edit a config file, restart your client. That works for desktop apps — Claude Desktop, Cursor — but it doesn't work from a browser, and it's more friction than it needs to be for tools that are inherently remote anyway.

WebMCP changes that. Remote MCP servers use HTTP+SSE transport, which means a browser can connect directly — no Node, no npm, no config files. Here's how to do it.

What you need

Two things: a WebMCP-compatible client and a server that supports HTTP+SSE transport. The server is just a URL — you don't install anything.

Clients that support WebMCP:

• Claude.ai (browser) — has native remote MCP support
• Claude Desktop (recent versions) — supports HTTP transport in addition to stdio
• Cursor — supports HTTP transport via settings

Connecting from Claude.ai

Claude.ai supports remote MCP connections without any local setup. To add a remote MCP server:

1. Open Claude.ai and go to Settings → Integrations (or look for the MCP/Integrations section in the sidebar).

2. Click Add integration or Connect a tool.

3. Enter the server URL — for AgentReady, that's https://www.agentready.it.com/api/mcp.

4. The client sends a list_tools request over HTTP and displays the available tools.

No install, no config file, no restart. The tools are available in your next conversation.

Connecting from Claude Desktop via HTTP

Claude Desktop traditionally uses stdio. But recent versions also support HTTP transport. In your claude_desktop_config.json, instead of a command, use a url:

{
  "mcpServers": {
    "agentready": {
      "url": "https://www.agentready.it.com/api/mcp"
    }
  }
}

This connects Claude Desktop directly to the remote server over HTTP+SSE — no bridge package, no subprocess. Note: check your Claude Desktop version supports this; it was added in later 2025 releases.

Connecting from Cursor

In Cursor's MCP settings, you can add a server by URL instead of command. Go to Settings → Features → MCP Servers and enter:

{
  "agentready": {
    "url": "https://www.agentready.it.com/api/mcp"
  }
}

How it works under the hood

When you connect, the client opens an SSE connection to the server's GET endpoint. The server can push events (like tool results) to the client over this long-lived connection. When the client wants to call a tool, it sends a POST request with the tool name and arguments.

# Client lists available tools
GET /api/mcp → SSE stream opens

# Client calls a tool
POST /api/mcp
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "ask_site",
    "arguments": {
      "domain": "stripe.com",
      "question": "how do I handle webhooks?"
    }
  }
}

This is standard HTTP — the same request/response model used by every web API, with SSE for streaming. Any language, any framework, any hosting platform can implement it.

Authentication

Public MCP servers (like AgentReady's read-only query tools) don't require auth. Private servers typically use Bearer tokens in the Authorization header, which the client passes with every request. The exact mechanism depends on the server's implementation.

When you're building a WebMCP server that needs per-user auth, the recommended pattern is OAuth 2.0 — the MCP spec includes guidance on this, and clients that support WebMCP generally support OAuth flows for connecting to authenticated servers.

The practical upside

The stdio setup for MCP is genuinely awkward. Finding the config file on different operating systems, knowing to use npx, restarting the client — it's manageable for developers but it's a lot to ask of anyone else. WebMCP reduces that to a URL. That's the whole point: the tool is a service, and connecting to a service should feel like connecting to a service.