The distinction
An MCP server connects the assistant to your systems — it is about access. A plugin or skill packages your workflow, instructions and tools into a reusable capability — it is about knowledge. Different problems, and the symptom tells you which you have.
Both extend what Claude can do for your organisation. They solve different problems, and the terminology gets used loosely enough that buyers cannot tell which they are being offered.
Which problem do you have?
| Symptom | What you need |
|---|---|
| "It gives good advice about data it cannot see" | MCP server / connector |
| "We paste the same context every time" | Plugin / skill |
| "Everyone gets different output for the same task" | Plugin / skill |
| "It cannot look up an order" | MCP server / connector |
| "One person's workflow never spread" | Plugin / skill |
| "Security blocked us connecting it" | MCP server, built properly |
The diagnostic in one question: is the assistant missing information, or missing instructions? Missing information means you need a connection to your systems. Missing instructions means you need the workflow packaged. Teams frequently commission one when they needed the other.
What an MCP server provides
- Access to live systems through narrow validated operations.
- Permission mapping so each person sees what they are entitled to.
- Audit logging of what was requested and returned.
- A standard interface that any MCP-capable client can use.
- Governance your security team can review and approve.
What a plugin or skill provides
- Packaged workflow knowledge — your process, encoded once.
- Consistent output regardless of who invokes it or how they phrase it.
- Bundled instructions and context that nobody has to re-supply.
- Shareable capability across a team rather than trapped with one person.
- Optionally, tools — frequently using MCP underneath.
A connector without packaged workflows gives you an assistant that can see everything and still needs telling how you work. A plugin without a connector gives you consistent process applied to stale information.
How they fit together
| Layer | Responsibility |
|---|---|
| Plugin / skill | What to do, in what order, in what format |
| Tools (often via MCP) | Reaching out to systems for data or action |
| Access layer | Permissions, validation, logging |
| Your systems | The actual data |
Cost and effort
| Build | Typical effort | Main driver |
|---|---|---|
| Plugin packaging existing workflow | Days to 2 weeks | Clarity of the process |
| MCP server, documented API behind it | 2–5 weeks | Tool design and permissions |
| MCP server, legacy system behind it | Considerably more | Building the adapter first |
| Both, integrated | Combined | Usually sequential |
The variable that dominates is what sits behind the connector. A modern documented API makes an MCP server a matter of weeks. A legacy system without one means building an integration layer first — which is a systems project with an MCP layer on top, and should be scoped as such.
A sensible sequence
- Package one workflow your team repeats. Cheap, fast, and it demonstrates value immediately.
- Watch what it cannot do for lack of live data — this identifies which connections matter.
- Build the connector for the highest-value data, read-only first.
- Combine them — the workflow now operates on real information.
- Expand on evidence from usage rather than assumption.
What both must get right
- Narrow operations — never a general query capability.
- Permission mapping to the requesting person.
- Approval gates on anything consequential.
- Untrusted content handling — retrieved text may contain manipulation attempts.
- Audit logging, reviewed rather than merely collected.
Unsure which you need? Describe what the assistant currently cannot do — the symptom usually identifies the answer. See our Claude plugin service, connector service, and the MCP guide.