Projects vs Skills vs Connectors vs MCP

the simplest decision tree for Claude Cowork, and the safest order to use them

Most people do not need a bigger Claude setup.

They need a cleaner one.

The confusion usually starts with the wrong question.

People ask:

Should I use Projects?
Skills?
Connectors?
MCP?
Plugins?

That sounds like a product menu.

It is not.

These are different layers of the work system.

If you treat them like interchangeable features, you will overbuild early, widen permissions too fast, and end up with a setup that feels smart but still creates cleanup work.

The useful mental model is simpler:

Projects hold context.
Skills hold method.
Connectors give reach.
MCP is the protocol layer for custom reach.
Plugins package the useful combination.

That is the whole stack in one view.

The rest of this article is just making that usable.

What changed, in plain english

Projects are self-contained workspaces with their own chat histories and knowledge bases. Skills are reusable folders of instructions, scripts, and resources for repeatable specialized tasks. Connectors let Claude reach external tools and data, including MCP-powered integrations. Cowork is Anthropic’s desktop agentic work surface for multi-step execution, built on the same architecture as Claude Code. Plugins in Cowork bundle skills, connectors, and sub-agents into a single package.

That means the right comparison is not feature versus feature.

It is workflow bottleneck versus stack layer.

If the bottleneck is lost context, start with Projects.

If the bottleneck is inconsistent method, add a Skill.

If the bottleneck is missing access to tools or data, add a Connector.

If the tool access must be custom, reach for MCP.

If the workflow is proven and you want it portable, package it as a plugin.

That is the default order for sane operators.

Start with the lightest structure that works

Your own Claude Cowork source docs are strong on this point: the audience does not want magical agent talk. They want the narrowest setup that removes real recurring pain, keeps review visible, and makes the workflow more trustworthy instead of more theatrical.

So here is the rule:

Do not ask what sounds most powerful.
Ask what solves the next real bottleneck with the least added complexity.

That one rule will save people a lot of bad setup work.

---

Layer 1: use a Project when the real problem is context

Projects are for continuity.

They give you a focused workspace with its own files, knowledge, and chat history. Projects are available to all Claude users, including free users, and free users can create up to five projects.

Use a Project when the pain sounds like this:

• Claude keeps losing the thread

• I keep re-explaining the same initiative

• my files, notes, and drafts belong together

• I want one place for this body of work

A Project is the right first layer for:

• market research

• content systems

• product work

• client work

• packet assembly

• repeat conversations around one initiative

A Project does not solve every workflow problem.

It helps Claude stay inside the work.

It does not automatically teach Claude your recurring method.

That is a different layer.

best use case

A founder research packet.

You have competitor notes, customer calls, memos, PDFs, and scattered thinking. You want Claude to stop acting like every session is a new job.

Start with a Project.

That is the cleanest fix.

---

Layer 2: use a Skill when the real problem is method

Skills are folders of instructions, scripts, and resources that Claude loads dynamically for specialized repeatable tasks. Anthropic’s docs explicitly frame them as a way to teach Claude how to complete specific tasks in a repeatable way. Custom Skills are available across free and paid Claude plans if code execution is enabled.

Use a Skill when the pain sounds like this:

• Claude gives different quality every time

• the task repeats, but the output shape drifts

• I have a rubric, checklist, voice, or procedure I want reused

• I want Claude to follow a standard, not improvise from scratch

A Skill is the right layer for:

• research rubrics

• review checklists

• memo formats

• briefing structures

• meeting prep formats

• brand voice systems

• recurring analysis methods

A Project says:

here is the body of work

A Skill says:

here is how to handle this kind of work

That is the distinction that most people blur.

best use case

A weekly operating review.

The context changes every week.

The method should not.

That is a Skill problem.

---

Layer 3: use a Connector when the real problem is access

Connectors let Claude understand and take action in connected tools. Anthropic’s current docs describe connectors as the way Claude works with 1st-party and MCP integrations so it can access your tools and data.

Use a Connector when the pain sounds like this:

• the data is in another app

• I do not want to paste the same source material into chat

• Claude needs live access to docs, messages, calendars, or systems

• the workflow depends on external context or action

This is where many people get sloppy.

They think access equals usefulness.

It does not.

A bad workflow with more access is still a bad workflow.

Use Connectors only when the workflow has a real need for outside data or actions.

the control nuance that matters

Do not oversimplify approvals.

Some connector flows require explicit approval for actions on your behalf. Anthropic’s Google Workspace connector docs say that clearly. But Research with custom connectors can invoke tools automatically without further approval, which is exactly why Anthropic warns users to disable write-capable tools in that mode.

That means the right rule is not:

all connectors always ask first

The right rule is:

understand the action model of the connector surface you are using, then design review around that reality

That is a much more trustworthy way to talk about control.

best use case

A consultant building a client prep packet from Drive docs, calendar notes, and live email context.

Now access matters.

Add the Connector.

---

Layer 4: use MCP when the access needs are custom

MCP is Anthropic’s open standard for connecting AI systems to tools and data. Anthropic’s docs and tutorials now position remote MCP as the way to build and use custom connectors for proprietary or specialized tools. Custom connectors using remote MCP are available on Claude, Cowork, and Claude Desktop, including free plans, though free users are limited to one custom connector and the feature is still in beta.

This is the cleanest practical explanation:

MCP is not the workflow.
MCP is the custom connection layer.

Use MCP when:

• the tool you need is not already covered cleanly

• the system is internal

• the access pattern is custom

• your workflow depends on proprietary data or actions

Do not start with MCP because it sounds advanced.

That is one of the easiest ways to build plumbing before you have proved the workflow deserves it.

If you have not already identified:

• the recurring job

• the inputs

• the deliverable

• the review point

then MCP is probably too early.

best use case

A team with an internal CRM or knowledge store that Claude needs to query inside a real workflow.

Now custom access is justified.

---

Layer 5: use a plugin when the workflow is proven and worth packaging

This is where the mental model gets much cleaner.

Your own Claude Cowork project docs are explicit:

plugins are packaging
specialists are behavior

Anthropic’s current safety docs also make the packaging point concrete. Plugins bundle skills, connectors, and sub-agents into a single package, and installing one can significantly expand Claude’s scope of action.

That means a plugin is not the first answer.

It is the packaging answer after you know the workflow is real.

Use a plugin when you want to make a proven setup:

• portable

• reusable

• easier to install

• easier to govern

• easier to standardize across a team

This is also why plugins matter so much editorially.

They are one of the clearest ways to show Claude shifting from a blank generalist into a role-shaped specialist.

That matches your internal source docs exactly. The real thing readers care about is not the plugin object itself. It is that Claude starts behaving like a specialist for a real recurring job.

---

baked-in asset 1

the one-screen decision tree

if your real problem is...start with...because...Claude keeps losing the thread across sessionsProjectcontext is the bottleneckClaude handles the task differently every timeSkillmethod is the bottleneckClaude needs data or action from another appConnectoraccess is the bottleneckClaude needs a custom internal or niche systemMCPthe access layer is customthe workflow works and now needs to be portablePluginpackaging is the bottleneck

the safest default order

1. Project

2. Skill

3. Connector

4. MCP

5. Plugin

That order is not a law.

It is the safest default path for most users because it keeps you from adding power before you have added clarity.

---

baked-in asset 2

the workflow fit scorecard

Use this before you build anything.

Score each question from 0 to 2.

• Is the task multi-step?

• Does it depend on files, notes, or persistent context?

• Does it happen often enough to matter?

• Does it produce a clear deliverable?

• Can a human review it before anything high-stakes happens?

• Does it need outside tool access?

• Would a repeatable method improve quality?

how to read the score

• 0 to 4: normal chat is probably enough

• 5 to 8: start with a Project

• 9 to 11: Project plus Skill is likely the sweet spot

• 12+: add Connectors, and only use MCP if the access pattern is custom

This scoring style aligns with your own internal editorial guidance, which repeatedly emphasizes recurring workflows, reviewable outputs, clear task boundaries, and honest scope over feature maximalism.

---

baked-in asset 3

the “what layer do i need?” prompt

I’m designing a Claude workflow and need to choose the lightest structure that works.

Classify this task into the right layer or combination of layers:

- Project = persistent workspace and context
- Skill = reusable method, rubric, or procedure
- Connector = access to outside tools or data
- MCP = custom protocol-based access to tools or systems
- Plugin = packaged workflow made from multiple pieces

For the task below, return:

1. the minimum stack I should start with
2. what I should not add yet
3. the main risk of overbuilding this
4. the human review point
5. whether this is better suited for normal Claude, Claude + Projects, or Cowork
6. one sentence explaining why this is the lightest structure that works

Task:
[PASTE TASK HERE]

Context:
[PASTE ROLE / TEAM / FILES / TOOLS HERE]

---

baked-in asset 4

the workflow design prompt

Turn this task into a practical Claude workflow.

Do not give me a feature tour.
Give me a real workflow.

Use this structure:

1. Job
2. Trigger
3. Inputs
4. Steps
5. Output
6. Review point
7. Best first layer:
   - Project
   - Skill
   - Connector
   - MCP
   - Plugin
8. Why that layer comes first
9. What should stay manual
10. What would make this workflow brittle

Task:
[PASTE TASK]

Role:
[PASTE ROLE]

Available files, tools, and systems:
[PASTE CONTEXT]

Goal:
[PASTE DELIVERABLE]

---

baked-in asset 5

the overbuild audit prompt

Audit this Claude workflow for unnecessary complexity.

Look for:

- using MCP too early
- adding connectors before the workflow is proven
- weak review points
- vague deliverables
- permissions that are broader than the workflow needs
- one-off work pretending to be a system
- places where a Skill would help more than more access
- places where a plugin is being used before the workflow is stable

Return:

1. what to remove
2. what to delay
3. what to keep
4. the smallest version worth testing this week
5. the exact human approval point
6. the likely failure mode

Workflow:
[PASTE WORKFLOW]

---

A fully worked example

example: weekly operating review

This is the kind of example your paid ICP will actually value because it shows the stack in motion, not as definitions.

the job

Turn scattered weekly inputs into a leadership-ready operating packet.

the inputs

• project updates

• KPI snapshots

• meeting notes

• blockers

• prior weekly packets

the output

• wins

• blockers

• risks

• decisions needed

• next steps

• one short leadership memo

the right stack

Start with a Project

because the work is context-heavy and persistent

Add a Skill

because the weekly review method should repeat

Add Connectors

only if the sources need to be pulled from live systems like Drive, calendar, or task tools

Use MCP

only if key data sits in an internal system without an existing clean connector path

Package as a plugin

only after the workflow proves stable enough that you want to reuse or distribute it

what stays manual

• final judgment on risks

• anything politically sensitive

• external communication

• major prioritization calls

where review belongs

Right before distribution to leadership.

That keeps Claude useful without pretending it owns the decision.

This matches the kind of role-shaped, reviewable, packet-driven workflow your own sources say the audience responds to best.

---

A bad example, on purpose

This matters because your internal objection map is clear that skeptical readers trust narrower claims, explicit limits, and examples of bad scope much more than feature description alone.

bad example

A solo founder says:

“I want Claude to run my whole sales and operations workflow, talk to all my tools, make decisions, and just keep the business moving.”

That sounds ambitious.

It is also the wrong starting point.

what is wrong with it

• no clear deliverable

• no visible review point

• broad access before proven need

• no distinction between drafting and action

• no recurring method defined

• too much surface area for trust

the better version

Start with one narrow workflow:

assemble a weekly pipeline packet from CRM notes, call summaries, and next-step tasks

Now the layers become obvious:

• Project for pipeline context

• Skill for the packet method

• Connector for the CRM or notes system

• MCP only if the CRM access is custom

• plugin later, if the workflow becomes worth packaging

That is the difference between a fantasy agent and a usable work system.

---

The simple rule to remember

If you only keep one line from this article, keep this one:

Projects store the work. Skills shape the work. Connectors reach the work. MCP customizes the reach. Plugins package the result.

That is the cleanest operator mental model I know for this stack.

It is also the one least likely to waste your time.

Because most people do not need to start by installing more capability.

They need to start by choosing the right bottleneck.

And once you do that, Claude stops feeling like a pile of features and starts feeling like a real work surface.