[FEATURE] Support Remote MCPs in Cowork as in Claude Code
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Hi,
this is re-opening #63266.
We're in a situation where not every MCP is a STDIO one, but we have a few internal to our network that use http. Unfortunately, in Cowork it's not possible to easily use those as they require to be open to the public internet and are talked to by the Anthropic Cloud according to https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities#h_4201f9e625
Custom connectors connect to your MCP server from Anthropic's cloud, not from your local device. Your server must be reachable over the public internet. If it's behind a firewall or on a private network
That's not what we want. These remote servers should stay internal to our network and thus be more secure.
Adding this to the Claude config under claude_desktop_config.json leads to an error on startup that it can't load the MCP and skips it.
"mcpServers": {
"custom-mcp": {
"type": "http",
"url": "https://ourcustom.mcp.com"
}
}
I don't really understand the rationale behind that decision as it severely limits the usefulness and extendability of Cowork for people, if you ask me. Other connectors based on e.g. a command are also running locally. So I'm not sure why HTTP based ones need to be routed through this special path. Especially since this is already possible through Claude Code and works just fine.
Proposed Solution
I'd like to be able to add a custom HTTP-based remote MCP without the need to open it to the public internet and have feature parity between Claude Code and Claude Cowork in that regards.
Cheers,
Christoph
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
MCP server integration
Use Case Example
_No response_
Additional Context
_No response_
4 Comments
If the rationale was to disallow that people just use too many unverified remote MCPs, please consider the following alternative.
Create a whitelist for remote MCP URLs that an organization can configure without putting the burden on them to route traffic through the Anthropic cloud and opening up a server that is internally hosted and thus way more secure from the start. This whitelist would be then checked in Cowork when this is in the config and allowed if the url is in the whitelist rather than completely disallowing the
httptype.Cross-linking #81764, which asks for the sibling case: local stdio MCP servers bridged into cloud Cowork sessions over the device connection that already exists.
Different transport, same underlying constraint you describe here: in a cloud session the MCP server is reached from Anthropic's cloud rather than from the local device, so anything that must stay inside a private network is out of reach.
One argument from that issue is relevant here too. The remote HTTP path routes OAuth through
mcp-proxy.anthropic.com, which currently does not refresh tokens (anthropics/claude-ai-mcp#228, anthropics/claude-code#65036, anthropics/claude-ai-mcp#308, all open). So the transport Cowork does offer in the cloud is also the one with the open token-lifecycle defect. Reaching MCP servers via the local device would address both problems with one mechanism.Note that #20377, which tracked the local/stdio side, is closed and locked to collaborators, which is why the follow-up went into a new issue.
This is not stale just because there is no further comment.
the thing that'll bite even after remote http lands is the skip-on-load behavior you already hit. a config that can't load just gets skipped at startup, so the app comes up looking fine with a short toolset and nothing tells you the mcp is gone. wire remote http through that same path and a transient blip or an expired token at launch silently drops the server for the whole session, no error surfaced, no retry. worth making a failed remote mcp a loud startup error you can retry, not a quiet skip that reports ready.