A Skill packages procedural knowledge — instructions, conventions, reusable scripts — that Claude loads when a task matches. MCP exposes live capability — tools, data, and actions in an external system. Most production setups end up using both.
Claude Skills package how, not what.
A Claude Skill is a folder with a SKILL.md file and, optionally, supporting scripts or reference material. It doesn't grant Claude any new ability to reach the outside world — it teaches Claude how to do something well within the tools it already has: a house style for commit messages, a checklist for running an audit, a template for drafting a weekly report.
Skills are model-loaded context, not infrastructure. There's no server to deploy, no auth flow, no uptime to manage. That makes them cheap to write and cheap to iterate on. If the Skill never triggers, the body quality doesn't matter — start with how to write a SKILL.md that actually gets used.
MCP is how Claude reaches a live system.
MCP servers expose live tools and resources — read a database, call an internal API, send a Slack message, query a CRM. They're the layer that lets Claude act on systems outside the conversation, with real authentication and real side effects. When people say "MCP Claude," this is usually what they mean: Claude talking to a tool you actually run, not a chat that only knows what you pasted.
That comes with the obligations of any service: deployment, secrets management, rate limits, and a security boundary around what the tool is allowed to touch. The Spark Labs impact study is the concrete version: one remote MCP connection across intake, membership, access, and email.
The test: does Claude need new knowledge, or a new door?
If the task is "Claude already has the tools, it just needs to do this consistently" — that's a Skill. House style, internal conventions, a multi-step procedure your team already follows by hand.
If the task is "Claude needs to read or write something it currently has no access to" — that's MCP. A live system, a private data source, an action with a side effect outside the conversation.
In our own stack, Skills carry the conventions (how we structure a campaign brief, how we format a client report) and MCP servers carry the access (BossHub, Nexudus, internal Workers). Skills tell Claude how to use the tools well; MCP is what makes the tools exist in the first place.
They compose. Cowork is a third place the work can live.
A well-designed Skill often references an MCP tool by name, instructing Claude on the right sequence, the right arguments, and the right judgment calls when using it. The Skill is the playbook; the MCP server is the equipment. Neither replaces the other.
Claude Cowork is not a Skill and not MCP. It is Claude working inside an approved local folder so the file never has to bounce through upload and download. Skills still tell it how. MCP still opens doors to systems you own. Cowork is where the deliverable sits on disk. For CRE, that split is the four-part field guide: Skills, Connectors, Cowork, Scheduled Tasks.
If you're writing instructions, write a Skill. If you're writing a server, you're building MCP. Most mature setups need both, and conflating them is the fastest way to over-engineer a simple need.