Which AI Clients Support Remote MCP in 2026?

Support Is A Matrix

The practical question is not whether a client can speak to a remote MCP server. It is which transport it accepts, where configuration lives, who can approve the connection, how authentication is performed and what happens when the server's tool list changes. MCP defines JSON-RPC messages over transports such as stdio and Streamable HTTP, where client messages reach a single endpoint by HTTP POST and responses come back as JSON or a request-scoped event stream. Client products then wrap that protocol in different user and admin experiences.

Claude And Claude Code

Claude's chat product treats remote MCP as a custom connector. The connector is configured with a remote MCP server URL, and the setup flow can use OAuth, sign in when needed, no sign-in or fixed request headers. Team and Enterprise organizations put an admin step in front of that setup: owners or authorized roles add the connector, then individual users connect and enable it. The remote server must also be reachable from Anthropic's cloud infrastructure, which is a real deployment constraint for teams whose tools usually sit behind a VPN or private firewall.

Claude Code is more developer-shaped. A remote HTTP server can be added directly from the terminal:

claude mcp add --transport http workspace https://mcp.example.com/mcp

If the server needs a bearer token or API key, the same CLI flow supports request headers, and OAuth-capable servers can be authenticated from /mcp or the login command. Scope is important. A personal experiment can stay local, while a team endpoint can be written as project configuration:

claude mcp add --transport http workspace --scope project https://mcp.example.com/mcp

That writes shared MCP configuration for the repository, so treat it like infrastructure code. Keep the URL and server identity reviewable, keep secrets out of the committed file and verify with claude mcp list or claude mcp get workspace. Claude Code also documents that connectors added in claude.ai can appear in Claude Code when the session is authenticated with a claude.ai account, so there are two paths to understand: local/project MCP entries and account-managed connectors.

Cursor And VS Code

Cursor supports local stdio, remote SSE and Streamable HTTP MCP servers. The remote case is usually a URL entry in .cursor/mcp.json for a project or ~/.cursor/mcp.json for a user. A minimal remote entry looks like this:

{
  "mcpServers": {
    "workspace": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:AGENT_MCP_KEY}"
      }
    }
  }
}

Cursor's docs also describe OAuth for remote servers, static OAuth client credentials, fixed redirect URLs for web and desktop authentication and admin allowlists for approved command or URL patterns. That makes Cursor friendly to a single workspace endpoint, but it also means you should test the exact surface your team uses: desktop, web agents, project config and team-distributed configuration do not all have the same governance story.

VS Code uses its own top-level servers object in .vscode/mcp.json, while the portable workspace format uses a top-level mcpServers object in .mcp.json. Microsoft recommends portable destinations for new servers when the configuration needs to work across compatible Copilot tools. A remote server in the VS Code format is intentionally small:

{
  "servers": {
    "workspace": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

The VS Code-specific wrinkle is trust. Workspace MCP servers inherit Workspace Trust, and restricted mode blocks workspace MCP configuration. That is a useful difference from Cursor and Claude Code: the same remote endpoint may be easy to configure everywhere, but the review and trust prompt a developer sees can change the rollout plan.

ChatGPT And The OpenAI API

OpenAI exposes remote MCP in two distinct ways. In the API, a developer can attach an MCP server as a tool by passing type: "mcp", a server_label and a server_url. Approval behavior is part of the request design. OpenAI's docs show require_approval controls and warn that remote MCP servers can access data or take action in third-party services, so sensitive tools should keep an approval path.

const response = await client.responses.create({
  model: "gpt-6-astra",
  tools: [
    {
      type: "mcp",
      server_label: "workspace",
      server_url: "https://mcp.example.com/mcp",
      require_approval: "always"
    }
  ],
  input: "List open incidents tagged checkout."
});

When the server requires an upstream OAuth token or bearer token, the API docs state that the authorization value is not stored and must be sent on each Responses API request. That is a major difference from GUI clients that store connector credentials for the user or organization.

ChatGPT's workspace MCP story is admin-led. Developer mode and MCP apps are documented for ChatGPT Business, Enterprise and Edu customers on web, with admins or owners enabling developer mode, creating custom apps, scanning tools and publishing apps for the workspace. OpenAI describes full MCP support, including write and modify actions, as a beta rollout in that context. In other words, do not assume a remote MCP server that works in the API is automatically something every ChatGPT user can paste into settings.

Protocol Calls Still Look The Same

Even when the product surfaces differ, the server should preserve the ordinary MCP boundary. Discovery is still a tools/list request. The tools specification says servers that declare the tools capability must respond with the tools currently available to the requesting client, and the set may vary by authorization. That makes per-user or per-key filtering legitimate, but it also means a client can reasonably cache or display the list it received.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Invocation is still tools/call. If the server exposes a namespaced issue-search tool, a client call can remain normal JSON-RPC while the server handles routing, credentials and policy behind it:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "linear/search_issues",
    "arguments": {
      "query": "priority:high label:checkout",
      "limit": 10
    }
  }
}

This is where compatibility bugs usually show up. One client may refresh a changed tool list quickly, another may need a new session, and another may hide a failed server behind a status panel. For rollout testing, verify five behaviors per client: initial connection, OAuth or header authentication, tools/list contents, one successful read-only tools/call and the user-facing error when the endpoint returns an authorization failure.

Where SPYN3 stands

SPYN3 serves remote MCP over HTTP at https://api.spyn3.com/agent/mcp. A client that can send an Authorization header can use it with an API key. We tested Claude Code end to end on 2026-10-14. MCP sign-in (OAuth) is also served, but we have not yet verified claude.ai's connector flow against it, so treat that path as unproven. Because clients differ in whether they refresh tools mid-session, SPYN3 does not rely on it: call_tool reaches opened tools either way.

Rollout Checklist

1. Pick the client surfaces you actually support: Claude web connectors, Claude Code, Cursor, VS Code, ChatGPT workspace apps, the OpenAI API or a smaller set.
2. For each surface, write the exact remote configuration and where it lives. For Claude Code, include claude mcp add --transport http. For Cursor, include .cursor/mcp.json. For VS Code, decide between .mcp.json and .vscode/mcp.json.
3. Decide whether the client authenticates to the MCP endpoint with OAuth, a bearer token, fixed headers or a per-request authorization value.
4. Run the same tools/list and read-only tools/call test from every client. Compare tool names, argument schemas, approval prompts and logs.
5. Test a write-capable tool with a read-only credential and confirm the denial happens at the server policy layer, not only in the model prompt.
6. Simulate an unreachable upstream and capture what the user sees. A remote MCP endpoint that vanishes silently will create different confusion in chat, IDE and API contexts.

This is also a good place to keep the architecture agent-agnostic. A single endpoint makes it easier to switch AI agents without rebuilding integrations, while a gateway-style layer keeps the client setup aligned with the MCP gateway pattern. The client matrix still matters, but it stops being the place where every upstream system is wired by hand.