What Is a Remote MCP Server and How to Connect

Originally published at https://scriptmasterlabs.com/blog/remote-mcp-server-connect.

Key takeaways

• A remote MCP server is a hosted HTTP endpoint your client reaches over streamable HTTP, while a local stdio server is a process your client spawns and owns.
• Every remote MCP connection follows the same three calls: initialize, tools/list, and tools/call; only the client config changes.
• Keyed servers use a Bearer or custom header, OAuth 2.1 servers issue scoped tokens per the MCP authorization spec, and x402 servers replace credentials with a 402 payment challenge paid in USDC on Base.
• Choose remote when data lives at the provider or you want zero local install; choose local when latency, filesystem access, or query privacy matters.
• Directories read static artifacts, so servers that build tool lists at runtime show empty or stale listings; ship a static manifest per release instead.

A remote MCP server is a hosted endpoint your agent client reaches over HTTP instead of spawning locally over stdio, so Claude Code, Cursor, or a custom agent can call tools on a machine you don't maintain. This guide covers the JSON config blocks, auth headers, and the x402 variant where a 402 challenge replaces the key.

What is a remote MCP server and how does it differ from a local stdio server?

A remote MCP server runs on a hosted HTTP endpoint your client reaches over the network. A local stdio server is a process the client spawns on your own machine and talks to over stdin/stdout. Same protocol, different transport.

Transport: streamable HTTP vs stdio

The MCP spec defines both transports: stdio for local processes, and streamable HTTP for remote servers, where the client POSTs JSON-RPC messages to a single endpoint URL and receives responses as a stream. Remote servers can also push server-initiated messages over the same connection, which stdio handles implicitly.

Lifecycle: who restarts the server

With stdio, your client owns the process: it starts it, and a crash takes the connection down until the client relaunches it. With a remote server, the operator owns the lifecycle. You reconnect, but you never patch or restart anything.

How do you connect a client to a remote MCP server endpoint?

Every remote MCP server speaks the same three-step protocol, and the client only changes in how you hand it the URL. First the client sends an initialize request over HTTP, then a tools/list to discover what the server exposes, then tools/call per invocation. If the endpoint is pay-per-call over x402, the 402 challenge replaces any header auth: the server returns HTTP 402 with payment terms, the client pays USDC on Base, and retries the same request with the payment proof attached.

Claude Code CLI walkthrough

Run claude mcp add --transport http <name> <url> from your shell. Claude Code stores the endpoint, sends initialize on next launch, and shows the server's tools in /mcp. No config file editing needed.

Cursor config walkthrough

Cursor reads the same JSON shape as Claude Desktop: add an entry under mcpServers with "type": "http" and the endpoint URL, then reload. Cursor lists tools from the remote server in its MCP panel.

Custom client: initialize, tools/list, tools/call

The long paragraph above is the whole contract. Our explainer page on the Aave MCP + MetaMask agent wallet follows it: a plain HTTP POST with a JSON-RPC body, a 402 challenge on the first unpaid call, and tools/call after payment clears. Build against those three methods and any compliant server works.

How do you authenticate to a hosted MCP server with static credentials or OAuth?

Bearer and custom header auth

The simplest hosted setup is a static credential in an Authorization: Bearer <token> header or a vendor-specific header like X-API-Key. Your client config carries the header alongside the endpoint URL, and the server rejects requests that omit it. This works fine for one developer, but every call is trusted purely on that string, and a leaked token equals a leaked wallet.

OAuth 2.1 for hosted servers

The MCP authorization spec requires servers offering OAuth to implement OAuth 2.1, acting as or fronting an authorization server so clients can discover metadata and obtain scoped tokens dynamically. That is the right pattern for servers acting on a user's behalf, like the Airbyte MCP server, where the token must map to your cloud workspace.

The 402 challenge as authentication

x402 flips the model: instead of proving identity, your agent proves payment. The server returns a 402 challenge naming price, payee address, and network; your client signs a USDC-on-Base payment and retries. No account, no token rotation, and the spend policy lives in your wallet, not the vendor's dashboard.

What does a working remote MCP server config look like in JSON?

Local stdio config

Local servers run as child processes, so the config names a command, not a URL:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
    }
  }
}

No transport URL, no headers. The client spawns the process and talks over stdio.

Remote keyed config

Hosted servers use a URL plus an auth header:

{
  "mcpServers": {
    "tavily": {
      "url": "https://mcp.tavily.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_KEY" }
    }
  }
}

The header travels with every session; rotate it by editing one line.

Remote x402 config

Pay-per-call servers drop the credential entirely. The endpoint returns a 402 challenge, the client's wallet pays in USDC on Base, and the call replays with proof attached:

{
  "mcpServers": {
    "decisionlayer": {
      "url": "https://scriptmasterlabs.com/decisionlayer-mcp-server"
    }
  }
}

The tradeoff: your agent needs a wallet and a spend policy, not a keyring.

When should you choose a remote MCP server over running one locally?

Choose remote when the data lives at the provider, when you want zero local install, or when you pay per call over x402 instead of running your own infrastructure. Choose local when latency matters, when the tool needs filesystem access, or when you can't accept a third party seeing your queries. The Claude Code MCP docs treat the two as parallel transports: stdio for local, HTTP for remote, same config shape.

The tradeoff worth naming: remote shifts trust from code you read to a provider you verify.

How does the Stripe MCP server work as a remote endpoint?

Stripe publishes a hosted MCP endpoint that exposes its API surface as tools: payment links, balance checks, customer lookup, refund operations. Your client connects over streamable HTTP and authenticates with OAuth against your Stripe account, so the server acts with your live or test credentials rather than a static token you paste into config.

The workflow: add the endpoint URL to your MCP client, complete the OAuth consent screen once, then tools/list returns the payment tools your account can call. Each tool call hits Stripe's API with the scopes granted at consent.

For agent payment workflows, this is the account-linked pattern: the agent spends from a real balance under your Stripe permissions, and every call traces back to the identity that completed the OAuth consent screen. It contrasts with the x402 pay-per-call pattern, where the agent holds a wallet and pays USDC per accepted call with no account at all. Pick OAuth when spend should trace to one identity and you want revocation to happen in a dashboard you already control. Pick per-call when you want the agent's budget enforced at the request level, so a runaway loop can spend only what the wallet policy allows rather than whatever the account balance holds. Both patterns work over the same three protocol calls, so the choice is about who holds the spending authority: the vendor account on one side, or the agent's own wallet on the other.

Why do directories show the wrong tools for a remote MCP server?

Directories mostly don't run your server. They read the package, repo, or registry record, and each reads a different source, so a tool list that only exists at runtime is invisible to them.

What directories actually read

Static artifacts: your npm package metadata, GitHub repo, or a registry entry. Some, like mcprush, fall back to the published source when they can't query a running server. If your tools are generated in code, there is nothing to read, and the directory shows an empty or stale tool list.

Static tool lists vs live /offers fetches

Building tools/list from a live /offers fetch feels right but breaks discovery. We shipped three releases in four days to fix it: the fix is a static manifest, committed per release, that a new service must ship a version to update. That costs "new services appear by themselves," but a buyer's agent should know what it's installing. Cursor's docs take the same stance: remote servers are declared explicitly in config, not discovered at runtime (Cursor MCP configuration documentation).

What are common connection errors with remote MCP servers and how do you fix them?

A 404 on the endpoint usually means the URL is missing the path the server expects, such as /mcp or a version prefix. Check the server's llms.txt or OpenAPI contract for the exact route before debugging your client.

Auth failures on a hosted endpoint are often a header problem: the token must go in the exact header the server documents, not a generic Authorization guess. For x402 servers, a 402 challenge is not an error. Your client should read the WWW-Authenticate payload, pay the stated amount in USDC on Base via the facilitator, and retry the same call with the payment proof attached.

A timeout on tools/list against a remote server often means the server builds its tool list at runtime by fetching a live shop or registry. Static, published tool lists respond fast; dynamic ones can hang. If tools/list stalls, retry once, then check whether the server documents a static manifest you can pin against.

FAQ

Can I use a remote MCP server without an API key or account?

Yes. x402-based servers replace credentials entirely: the endpoint returns a 402 challenge naming price and payee, your agent's wallet pays USDC on Base, and the call retries with payment proof attached. No registration, no token rotation. OAuth servers do require an account, since the token maps to your workspace or identity.

Does a remote MCP server cost money per call, and how is it billed?

It depends on the billing model. Keyed providers typically charge through their own dashboard pricing, while x402 endpoints bill per accepted call: the server states a price in the 402 challenge, and your client pays that amount in USDC on Base before the call executes. Local stdio servers cost nothing beyond your own compute.

Is my data sent to a third party when I use a hosted MCP server?

Yes. Every tool call travels over HTTP to the operator's endpoint, so your queries leave your network and the provider can see them. With a local stdio server, queries stay on your machine and you vet the code instead. If that trust shift is unacceptable, run the tool locally.

How do I test a remote MCP server before wiring it into my agent?

Send the three protocol calls by hand: a JSON-RPC initialize POST, then tools/list, then a single tools/call. Expect a 402 challenge on x402 endpoints rather than an error, and check the exact header the server documents for keyed auth. A stalled tools/list often signals a server building its tool list at runtime.

What is the difference between an MCP server and a machine-payable API?

An MCP server exposes tools through the MCP protocol: initialize, tools/list, and tools/call, so an agent client can discover and invoke them. A machine-payable API is any endpoint an agent can pay for, often via x402. An x402 MCP server is both: protocol-compliant tools, with the 402 challenge handling payment per call.