Connectors vs Skills vs Projects vs Custom MCP: What Each Layer Is Actually For

Most people are treating four different parts of Claude like they’re the same thing. They’re not. Here’s the cleaner model, why the confusion keeps happening, and how to know what you actually need.

Cowork is getting more useful. It’s also getting easier to misread.

Once you put projects, skills, connectors, plugins, and MCP in the same general conversation, people start flattening them into one fuzzy bucket. It all gets labeled as “agent stuff,” and from there the advice gets sloppy fast.

That’s how people end up asking the wrong questions.

Not: What’s the best layer for this job?
and not: Which feature should I install first?

The better question is:

Where is this workflow actually breaking?

Is Claude losing the thread between steps?
Is the task shape drifting every time?
Is the source material stuck across too many apps?
Is the system you need missing a built-in bridge?
Do you want one setup you can reuse instead of rebuilding it from scratch?

Those are different problems.

So they need different layers.

Here’s the clean model:

Projects hold context. Skills hold method. Connectors extend reach. Custom MCP fills the gaps when the built-ins stop. Plugins package the right pieces into something reusable.

Once you see Cowork that way, the product stops looking like a pile of features and starts looking like what it actually is:

A work surface for carrying context, structure, and tool access across real tasks without making you rebuild the job every step.

The real mistake isn’t technical

Most people aren’t confused because they’re not technical enough.

They’re confused because the language around this category is still messy.

A project can feel like memory.
A skill can feel like intelligence.
Connectors can feel like automation.
A custom MCP server can feel like the advanced version of everything else.
A plugin can feel like a separate product category.

That framing causes trouble because it hides what each layer is really doing.

These are not rival features.
They are different jobs inside one work system.

That distinction matters more than it sounds.

If you blur those jobs, you get the worst kind of AI setup. Lots of capability. Weak structure. Fuzzy permissions. A human still cleaning up the mess at the end.

That’s also why so much Cowork commentary feels thin. It talks about power in the abstract and skips the part operators actually care about:

Where the work gets easier.
What output gets produced.
Where review still happens.
What should stay manual.

Projects are where the work lives

The simplest way to think about a project is this:

A project is where the job lives.

It’s the room.

Not the method.
Not the tool bridge.
Not the packaging.

The room.

This is where the source files, recurring instructions, working history, and task context stay together long enough to matter.

That sounds simple, but it’s one of the most useful shifts in the whole stack.

A lot of people still treat projects like storage. Just a place to dump files and keep related chats nearby. That’s too shallow.

The real value is continuity.

If the work depends on a stable body of material, repeated references, recurring notes, or background context that shouldn’t be re-explained every time, a project is doing real work for you.

Think weekly review packets.
Client prep folders.
Research collections.
Content pipelines.
Internal operating docs.

If your main pain is context decay, start there.

Not because projects are flashy.
Because they remove one of the most boring taxes in AI work: having to keep restating the job.

Skills are how the work gets done the same way twice

If a project is the room, a skill is the playbook.

That’s the cleanest distinction.

A project gives Claude the background.
A skill gives Claude the operating logic.

This is where a lot of users still get sloppy. They treat skills like upgraded prompts or minor behavior tweaks.

That undersells what they’re good for.

The practical value of a skill is consistency.

Same task shape.
Same structure.
Same output pattern.
Same review logic.
Less drift.

That matters a lot in real work.

Many recurring tasks don’t fail because the model lacks raw intelligence. They fail because the approach changes a little every time. The headings shift. The summary logic softens. The source ranking gets inconsistent. The formatting wanders. The handoff becomes harder because the output no longer looks familiar.

A good skill fights that entropy.

So if Claude already has the right background but the task still feels loose, uneven, or unpredictable, you probably don’t need another connector.

You probably need a clearer method.

That’s what a skill is for.

Connectors give Claude reach

This part is easier to understand and easier to overrate.

A connector gives Claude access to another system. Email, files, calendars, docs, spreadsheets, task tools, and so on.

That matters because real work rarely lives in one place. The task is in one app. The context is in another. The draft needs to end up somewhere else. The review point sits with a person outside the original workflow.

So yes, connectors matter.

But here’s the line most people need to hear:

Reach is not judgment.

Connecting Gmail doesn’t create a triage process.
Connecting Drive doesn’t create a research method.
Connecting Calendar doesn’t create scheduling logic.
Connecting Slack doesn’t create an operating cadence.

A connector solves one kind of friction. It shortens the distance between Claude and the system holding the work.

That’s useful. Sometimes very useful.

But it’s still only one layer.

This is why “I connected everything and it still feels generic” is such a common experience.

The surface area got wider.
The workflow didn’t necessarily get better.

And if the method is weak, more access usually just means more mess.

Custom MCP is the bridge layer when the built-ins stop

This is the part people turn into mythology.

It doesn’t need mythology.

The simplest definition is this:

Custom MCP is the bridge layer for the tools Anthropic didn’t already wire up for you.

That’s it.

Not the advanced version of Cowork.
Not a magic upgrade.
Not some secret category that replaces the rest of the stack.

It’s what you use when the system you care about isn’t covered by the built-in options and you still want Claude to reach it.

That’s why “skills vs MCP” is the wrong fight.

One gives Claude a way into outside systems.
The other teaches Claude how to operate inside a task.

Those are complementary jobs.

If Claude needs to reach your internal reporting system, custom database, niche SaaS, or company-specific tool, custom MCP may be the missing bridge.

But a bridge isn’t a workflow.

It doesn’t decide what good work looks like.
It doesn’t define the packet structure.
It doesn’t establish review logic.
It doesn’t make broad permission scopes wise.

It just connects the road.

Plugins are packaging

Plugins are where the stack gets easier to use and easier to misunderstand at the same time.

The cleanest way to explain them is this:

A plugin is packaging.

Not a rival concept.
Not a magical extra layer.
Packaging.

A plugin bundles the right pieces for a role or recurring use case so the user doesn’t have to assemble them by hand every time.

That might include skills, connectors, supporting logic, and other workflow pieces that belong together.

This is why plugins matter more for teams, internal builders, and repeatable operating setups than they do for casual experimentation.

They turn “we figured out a useful setup once” into “we can actually use this again without reteaching the whole thing.”

That’s valuable.

It’s also why plugins can quietly widen risk. A packaged setup can carry more permissions, broader scope, and more action surface than the user realizes at first glance.

So the smart rule isn’t “install more plugins.”

It’s:

Install packaging that matches a real recurring job.

If the workflow doesn’t exist yet, packaging won’t save you.

One boring workflow makes the whole stack click

The best first Cowork workflows are usually boring.

That’s a feature, not a flaw.

Take a weekly operating review.

It’s a strong example because it happens repeatedly, it pulls from scattered material, it ends in a visible deliverable, and it still benefits from a human review layer. That gives it much better odds than broad “run my business” fantasy use cases.

Here’s the stack:

Project: the workspace holding prior review packets, notes, recurring instructions, and current source material.
Skill: the method for turning scattered material into the same packet shape each time: wins, blockers, anomalies, decisions, follow-ups.
Connector: access to the docs, email, calendar, file storage, or chat tools where the raw material lives.
Custom MCP: the internal metrics source or company-specific system that isn’t covered by built-ins.
Plugin: the packaged operating-review setup that a founder, operator, or chief of staff can reuse instead of rebuilding from zero.

Now notice where the value actually shows up.

Not in “Claude has tools.”
Not in “Claude is smart.”
In continuity.

The context stays close to the work.
The method stays stable.
The source material is easier to pull in.
The output shape stops drifting.
The human reviews the packet instead of rebuilding it.

That’s the shift.

Less prep.
Less copy-paste.
Less task re-explaining.
More forward motion toward something usable.

That’s why Cowork matters more as a work system than as another chat interface.

The real bottleneck is usually not access

People love adding capability because capability is visible.

A new connector feels like progress.
A new plugin feels like progress.
A custom bridge into another system definitely feels like progress.

But in practice, the bigger bottleneck is often simpler and less exciting:

Workflow design.

What’s the deliverable?
What source material actually matters?
What should stay behind approval?
What’s safe to draft versus safe to execute?
Where does review happen?
What gets meaningfully better if this works?

If you can’t answer those questions, broader access won’t rescue the setup.

This is where a lot of AI writing still goes wrong. It treats capability as proof. It assumes tool access automatically creates leverage. It confuses product surface area with workflow maturity.

That’s backwards.

A narrow setup with a clear packet, draft, brief, or summary is usually more valuable than a broad setup with vague ambition.

That’s also why approvals matter. Not as friction. As structure.

The audience for Cowork is not asking for magic.
They’re asking for a system they can trust.

How to know what to add first

Here’s the simplest decision rule I’d use:

If Claude keeps losing the body of work, add a project.

If the task is inconsistent from one run to the next, add a skill.

If Claude needs to read from or act in another app, add a connector.

If the important system isn’t covered by the built-ins, use custom MCP.

If the setup is worth reusing across people or repeated workflows, package it as a plugin.

That rule is simple on purpose.

Not because the stack is simple.
Because decision rules should be.

The practical takeaway

Most people start too wide.

They ask which plugin to install.
Whether they need MCP.
Which connector is best.
Whether skills replace prompts.

That’s usually backwards.

Start with the deliverable.

What packet, brief, memo, report, prep doc, findings summary, or recurring output are you actually trying to produce?

Then ask what layer is missing.

That’s the better question because it leads to narrower setups. And narrower setups are easier to trust, easier to review, and much more likely to survive past the demo phase.

So the real setup question isn’t:

Which Claude feature should I use?

It’s:

Which layer of the stack is missing from this workflow?

That’s the frame worth keeping.

Because once you see Cowork that way, the noise drops.

And the product starts to fit where it’s strongest:

Not as a magical assistant.
As a practical system for carrying context, structure, and tool access across real work without making you rebuild the job every step.