What is an MCP server?
An MCP server is a process that speaks the Model Context Protocol — an open spec for letting LLMs call tools and read resources from external systems. Claude Code and Claude Cowork both speak MCP natively; every tool the agent calls is either built-in or backed by an MCP server somewhere.
A few concrete examples:
- A filesystem MCP exposes
read_file,write_file,list_directory. - A Slack MCP exposes
send_message,search_channels,read_thread. - A custom in-house MCP might wrap your company's CRM or deploy pipeline.
The MCP server can run locally (a process on your machine, started by
Cowork from your .mcp.json config) or remotely (an HTTP endpoint that
speaks the protocol over the network). Either way, the contract is the
same: the server publishes a list of tools, the agent decides which to
call, the server runs them and returns results.
Why this matters for a Cowork rollout:
- Every MCP is a new audit boundary. A Slack MCP can read or post on behalf of the agent. A filesystem MCP can move data around. If you can't see which MCPs are installed on a teammate's machine, you can't reason about what the agent could have done.
- MCPs aren't versioned by Cowork itself. A user can update an MCP silently and change what it returns. If a skill that depends on it starts breaking, the MCP version is usually the first place to look.
- A capture layer like Argus inventories MCPs at session start. That inventory is the closest thing you get to a "what tools could this session have used" answer.
In short: MCP is the plumbing that gives a Cowork session its capability surface. Knowing which MCPs are installed is half of understanding what your team's Cowork install can actually do.