Detailed Analysis
A developer attempting to integrate a privately hosted Outline Wiki with Claude Desktop on Windows has encountered a fundamental architectural incompatibility between local MCP server execution and Anthropic's cloud-routed collaboration features. The user's configuration relies on `mcp-remote` — a bridge tool that proxies HTTP/SSE-based MCP endpoints — pointed at an internal-only hostname (`https://outline.internal/mcp`) that is intentionally unreachable from the public internet. The silent failure in Claude Desktop, combined with the failure in Claude Code's "Cowork" mode, strongly suggests the requests are being tunneled through Anthropic's cloud infrastructure rather than originating locally from the user's machine, rendering the private DNS name unresolvable.
The diagnostic evidence the user has assembled is technically illuminating. The MCP server functions correctly in Claude Code CLI and OpenAI Codex desktop, both of which execute tool calls directly on the local machine. It also succeeds in Claude Code's "Code" mode. The precise failure point — Cowork mode — is the key variable. Cowork mode is a collaborative, multi-agent feature in Claude Code that coordinates sessions through Anthropic's backend, meaning that the process initiating the MCP connection is no longer the local client but a cloud-side agent that has no path to the `outline.internal` hostname. Claude Desktop's MCP implementation may similarly offload or intermediate certain connection types through remote infrastructure, particularly when using `mcp-remote` with an HTTPS URL rather than a locally spawned stdio-based process.
The configuration itself reveals a compounding issue. Using `cmd /c npx -y mcp-remote https://outline.internal/mcp` is the correct pattern for HTTP-based MCP servers, but `mcp-remote` was designed as an adapter for publicly reachable SSE endpoints. For a strictly private network context, the more appropriate architecture would be a locally running stdio-based MCP server (a Node.js or Python process that directly queries the Outline API using a local API key) configured with a `command` pointing to that local binary. This eliminates the HTTP transport layer entirely and ensures Claude Desktop spawns the process locally, making internal network access a non-issue regardless of what mode is active.
The broader implication for enterprise and team deployments of Claude Desktop is significant. Organizations with air-gapped or private-network tooling cannot safely assume that MCP integrations configured in `claude_desktop_config.json` will always execute with local network context. As Anthropic builds out collaborative and agentic features that increasingly coordinate work through cloud-side orchestration, the boundary between "runs on my machine" and "runs via Anthropic's infrastructure" becomes less transparent to end users and deployers. This is particularly consequential for non-technical users, as the user notes — silent failures with no actionable error messages represent a serious usability and trust gap for teams attempting to adopt AI tooling against internal systems.
This case also reflects a wider pattern in the MCP ecosystem where the specification's flexibility — supporting both stdio and HTTP/SSE transports — creates deployment ambiguity. Developers accustomed to the stdio model may not realize that `mcp-remote` fundamentally changes the trust and routing model of the connection. As MCP adoption grows across enterprise contexts, clearer documentation and error surfaces from Anthropic distinguishing local versus cloud-mediated execution paths would substantially reduce this class of integration failure, especially as more organizations attempt to bridge Claude's capabilities with private internal infrastructure.
Read original article →