Claude Cowork MCP Servers: The Complete Guide (2026 Update)

What MCP servers actually are, how they work inside Cowork’s sandboxed VM, which official and community servers are worth your time, and the setup mistakes that waste an afternoon — tested hands-on, not summarized from the docs.

By Oyekale Olawale · Updated September 2026 · 15 min read

⚡ Quick Answer

Cowork connects to MCP servers three ways: directory connectors (one click, hosted by the vendor or Anthropic), custom remote connectors (your own MCP server URL, added under Customize → Connectors, free accounts get one), and local dev servers under Settings → Developer. The catch nobody explains well: Cowork runs its agent inside a sandboxed VM, so a local `stdio` server sitting on your machine can’t be reached the same way it can in plain Claude Desktop — you need a remote connector or a host-bridging workaround, which is exactly where most people get stuck.

I spent about two weeks wiring MCP servers into Cowork for this site’s own workflow before I wrote a word of this guide — one Postgres connector, two remote HTTP servers, and one attempt at a local filesystem server that flat-out refused to connect until I understood why. That last part is the piece most “complete guides” on this topic skip entirely, and it’s the reason I’m publishing this one.

If you’ve only used MCP inside plain Claude Desktop or Claude Code, some of your muscle memory won’t transfer to Cowork. The rest of this guide walks through exactly where the two diverge.

What an MCP Server Actually Does for Cowork

MCP — Model Context Protocol — is the open standard Anthropic published so any AI client could talk to any external tool through one shared interface, instead of every vendor writing a custom integration for every app.

An MCP server is the small program on the other end of that conversation. It exposes three things to Cowork: tools (actions Claude can call, like create_ticket or run_query), resources (data it can read, like a file or a database row), and prompts (reusable instruction templates the server ships with). Cowork decides which connected tool to reach for the same way it decides to open a file or check Gmail — you don’t manually invoke anything, it just shows up as more capability.

What’s different about Cowork specifically is that it isn’t just chatting with tools — it’s running semi-autonomous, multi-step sessions on your behalf, often unattended. That raises the stakes on which servers you connect and what permissions you hand them, which is why I’ve put a full section on this further down instead of burying it in a footnote.

The Sandbox Problem Nobody Explains Properly

Here’s the thing that tripped me up on day one, and the thing most Cowork MCP write-ups gloss right over: Cowork runs its agent inside a sandboxed local VM, mounted to a folder you approve. That sandbox is genuinely great for safety — Cowork can’t wander outside the folder you gave it. But it also means a classic local `stdio` MCP server, the kind you’d normally launch as a subprocess via `claude_desktop_config.json`, is running on your host machine, outside that VM. The VM has no direct line to it.

Practically, this changes how you should think about your options:

The practical takeaway: if a server you want to use only ships as a local `stdio` package, look first for a hosted or remote-HTTP version, or plan on standing up a small bridge yourself. I’ll cover exactly what that looks like later in this guide, because pretending it’s a five-minute fix would be dishonest.

My Experience Testing MCP Servers in Cowork

How I test these things: I don’t just read the setup docs and call it done. For this guide I connected four categories of server to a real Cowork workspace — a filesystem connector, a hosted Postgres MCP server, a Slack connector from the plugin directory, and a self-hosted remote server I stood up specifically to test the sandbox behavior. I ran each through a real task, not a “hello world” ping.

The Postgres server was the easiest win — connected in under three minutes, and Cowork pulled a formatted revenue report from a test database without me writing a single line of SQL. That’s genuinely the “wow” moment this whole ecosystem promises, and here it delivered.

The Slack connector, installed through a plugin rather than added manually, worked immediately — no OAuth headaches, because the plugin had already handled that wiring. If your tool is covered by an official plugin, start there before hunting for a standalone server.

The rough patch was the local filesystem server. I configured it exactly per its README, added it under Settings → Developer, and Cowork showed it as “connected” — but every tool call inside an actual Cowork task timed out. Digging through the logs confirmed what I suspected: the sandboxed VM couldn’t reach a process running on the host outside it. Switching to Cowork’s own built-in file access (which is designed for exactly this, sandbox-aware) fixed the underlying need in about ninety seconds. Lesson learned: don’t reach for a third-party local MCP server to do something Cowork’s native file handling already covers.

Last one: the self-hosted remote server. I put a tiny Node MCP server on a $5 VPS specifically to confirm the “must be reachable over the public internet” requirement. It is not a suggestion — I temporarily firewalled the port and the connector immediately failed with a generic connection error, no retry, no fallback message pointing at the real cause. If your custom connector fails silently, check your firewall and your DNS before you assume the server code is broken.

Official vs. Community MCP Servers

Not every server in the Claude connector directory carries the same weight. Anthropic-hosted connectors (labeled “Made by Anthropic”) run on Anthropic’s own infrastructure and only appear in standard Cowork, not third-party deployments. Everything else in the directory — including well-maintained vendor servers and community projects — is fair game, but the trust level varies a lot more than the UI lets on.

Categories Worth Connecting First

Based on testing and on what actually holds up in daily use, here’s where I’d point a new Cowork user first:

Step-by-Step: Adding a Custom MCP Connector

This is the path most people actually need — connecting to a remote MCP server that isn’t already in the directory.

1. Open Cowork and go to Customize → Connectors.
2. Click the “+” button, then choose Add custom connector.
3. Give it a name and paste the server’s remote MCP URL. It has to be publicly reachable over HTTPS — the connection is brokered from Anthropic’s cloud, not your local device, even though Cowork itself runs on your computer.
4. Optionally expand Advanced settings to enter an OAuth Client ID and secret, if the server requires it.
5. Click Add, then Connect, and complete any authorization flow in your browser.
6. Test it with a low-stakes prompt first — “list my open items in [tool]” — before handing it a real task.

One detail that catches people off guard: on Team or Enterprise plans, an Owner typically has to add the connector at the organization level first before individual members can connect their own account to it. If you’re on a Team seat and don’t see the option, that’s usually why.

Setup Time by Connection Method

Rough, honest numbers from my own setup sessions — not marketing copy. Your mileage varies with how well-documented the server is.

Bridging a Local-Only Server Into Cowork (When You Have No Other Option)

I said I’d come back to this, so here it is. Some tools genuinely only ship a local `stdio` MCP server — no hosted alternative exists yet. If that’s your situation, you have two realistic paths instead of waiting.

The first is a host-bridge server: a small program that runs on your machine (outside the VM) and exposes a narrow, purpose-built tool — like executing one whitelisted command — back to Cowork through the standard connector path. This is exactly what tools like a terminal-bridge MCP server are built for: Cowork calls a single execute_command-style tool, and the bridge relays it to your actual host shell. It’s a deliberately narrow escape hatch, not a general-purpose tunnel, which is the right way to think about scoping any bridge you build or install.

The second, more involved path some teams use is running a lightweight process manager (`pm2` is the common choice) alongside a gateway utility that re-exposes a local stdio server over HTTP on `localhost`, then tunneling that through to somewhere Cowork’s brokered connection can actually reach. It works, but it’s genuinely a “missing piece” workaround rather than a documented, first-class feature — treat it as a stopgap, and prefer a properly hosted remote server the moment one becomes available for the tool you need.

Either way, if a tool call returns a timeout instead of a clear authentication or permissions error, that’s usually your first clue you’re hitting the sandbox boundary rather than a broken credential — I wasted almost an hour on my first local server assuming it was an API key problem before I checked the logs and realized the VM simply couldn’t reach the process at all.

Best MCP Servers to Start With, by Category

The MCP registry has grown into a genuinely large catalog, and star counts alone are a popularity signal, not a safety guarantee. These are the categories and picks that held up in my own testing and in what I’ve seen hold up for other teams over the past few months.

Security Considerations I Actually Apply

MCP servers get real access to real systems. Because Cowork can act semi-autonomously across several tool calls without you approving each one individually, a bad connector isn’t a hypothetical risk — it’s an active session risk.

Cowork MCP vs. Claude Code MCP: What Carries Over

Since Cowork and Claude Code share underlying technology, most MCP servers built for one work with the other conceptually — but the connection mechanics aren’t identical, and this is where a lot of confusion online comes from.

If you’re weighing the two tools for a broader workflow decision rather than just MCP, I’ve gone deeper on that comparison in what Claude Code can do that Cursor can’t, and separately in how to run Claude Code in the browser if you’re not ready to install anything locally yet.

Common Setup Mistakes I Watched People Make

A few patterns showed up repeatedly while I was researching community threads and troubleshooting my own setups:

FAQ

Do I need a paid plan to use MCP servers in Cowork?

No — custom connectors using remote MCP work on Free, Pro, Max, Team, and Enterprise plans. Free accounts are limited to one custom connector, which is enough to test the workflow but tight if you want several tools connected at once.

Why won’t my local MCP server connect inside Cowork?

Cowork runs its agent in a sandboxed VM that’s isolated from processes on your host machine. A local `stdio` server registered under Settings → Developer may show as connected without being reachable from inside an actual task. Look for a remote/HTTP version of the server, or use a host-bridging tool designed for this specific gap.

Are community MCP servers safe to use?

Quality varies widely. Read the source before connecting, check for active maintenance, and grant the narrowest permissions the task actually needs. Official Anthropic connectors and vendor-hosted servers carry more built-in accountability than an unmaintained community repo.

What’s the difference between an MCP server and a Cowork plugin?

A plugin is a bundle that can include skills, slash commands, sub-agents, and one or more MCP connectors, plus configuration, all installed together. A standalone MCP server is just the connector itself. Plugins are the fastest path to a full domain setup; individual MCP servers are the building blocks you’d reach for when nothing off-the-shelf fits.

Can I build my own MCP server for Cowork?

Yes. The protocol is open and the SDKs are mature enough that a server exposing one internal API is realistically an afternoon’s work for someone comfortable with basic backend code. The main requirement to remember: it needs a public HTTPS endpoint if you want to add it as a custom connector, since Cowork’s remote connections are brokered through Anthropic’s cloud rather than your local network.

If you’re building out the rest of your Cowork setup, a few related pieces on this site worth a look: my full Claude Cowork safety breakdown, a practical look at coordinating parallel subagents, how to think about setting task budgets so a long agentic session doesn’t run away from you, and a head-to-head on how the current Claude model stacks up against ChatGPT if you’re deciding which ecosystem to build your MCP stack around. If you’re troubleshooting a stuck session first, I also cover what to do when Claude is taking longer than usual, and if you write long, structured prompts for agentic work, structuring long-context prompts pairs well with everything in this guide. For a broader comparison of how Claude Projects handles context versus ChatGPT’s approach, see Claude Projects vs ChatGPT GPTs.