Claude Projects vs MCP: When to Use Each (2026)

People keep asking the same question. “Should I put this in a Claude Project or build an MCP server?”

The answer is annoying. They are not the same shape of thing, so the comparison feels muddy. One is a feature inside Claude. The other is a protocol that Claude (and other clients) can speak. You can use both at once. You can use neither. You can replace one with the other for some jobs but not others.

This post is the decision framework. What each one actually is, what each one is bad at, and the question to ask before picking.

What Claude Projects actually is

Claude Projects is a workspace feature inside the Claude app. You create a project, upload files, write a project-level instruction, and every chat inside that project has access to all of it.

The mechanics, per the official Claude help docs, are simple. Upload a file (PDF, DOCX, CSV, TXT, HTML, and a few more formats). Cap is 30MB per file with no hard limit on file count. Add a custom instruction telling Claude how to behave in this workspace. Start a chat. Claude has access to the instruction, the files, and the chat history of every other conversation in that project.

Free Claude accounts get five projects. Paid plans get unlimited projects and the better retrieval. Free users still get the feature, just with the smaller cap and the simpler retrieval.

The strength is obvious. Projects gives you a Claude that already knows your topic. No re-pasting. No re-explaining. Open a fresh chat in the same project and the AI starts from your context.

The weakness is also obvious. Everything is locked to claude.ai. Switch to ChatGPT, Cursor, or Claude Code and the project does not exist. The files are read-only after upload, so a Project is a frozen snapshot. To update the knowledge you re-upload. The “Project knowledge” is not a real database. It is a folder of files, a system instruction, and a smarter retrieval layer than a regular chat.

What MCP actually is

The Model Context Protocol, released by Anthropic in late 2024, is an open standard that defines how an AI client talks to external data sources and tools.

An MCP server runs as a separate process. It exposes tools. The client (Claude Desktop, Claude Code, ChatGPT in Developer Mode, Cursor, Cline) reads the tool list at session start and decides, mid-conversation, when to call each one. The wire format is JSON-RPC, defined in the public spec.

The mechanism gives MCP three properties Claude Projects cannot match.

First, the data is live at query time, not frozen at upload. An MCP server backed by Notion, your filesystem, or your bookmark collection returns whatever is true right now.

Second, the AI decides when to query. You ask a question. Claude reads the question, looks at the available tools, picks the right one, and calls it. No template editing. No “use this knowledge” prompt prefix.

Third, the same MCP server works in every MCP-compatible client. Build it once, connect it to Claude Desktop, Claude Code, ChatGPT, and Cursor. The same data lights up everywhere.

For more on what MCP is in plain English, see What Is MCP? and Personal AI Context Stack for Claude.

Claude Projects vs MCP: the split that actually matters

The cleanest way to remember it: Projects is a place. MCP is a phone line.

A place holds a fixed set of things. A phone line connects you to whatever is on the other end, live.

When Claude Projects wins

There are real cases where Projects is the right answer and MCP is overkill.

Your knowledge is a fixed bundle of finished documents. A book manuscript. A locked-down legal pack. A reference set of brand guidelines that does not change. Upload it once, set the instruction, never think about it again.

You want a project-level system prompt. Projects lets you write instructions like “Always cite the relevant source document and never invent statistics.” That instruction applies to every chat in the project. With raw MCP you would put that in the client’s system prompt, which is per-client and per-session.

You want chat history scoped to a topic. All chats inside a project share a sidebar. You can scroll back to “what did Claude say about chapter three” without searching across your whole Claude history. MCP does not do this. Chat scoping is a Claude product feature, not a protocol thing.

You only use Claude. If you live entirely inside claude.ai and have no plans to leave, the cross-client portability of MCP buys you nothing. Projects is simpler.

The data is too sensitive to expose as a tool. A signed NDA contract you absolutely do not want sitting on a server. Drop it into a Project, work on it for a week, delete the project. Even a self-hosted MCP server is a longer-lived attack surface than a one-off upload.

For most knowledge workers, the honest test is: do I want this knowledge to come with me when I switch tools? If yes, it does not belong in a Project.

When MCP wins

Almost everything else.

Your data is alive. Notion pages are edited daily. Your bookmark collection grows weekly. Your filesystem changes by the hour. A Project of “my notes” goes stale the moment you save a new note. An MCP server returns whatever is true at the moment Claude calls it.

You use multiple AI clients. Most people who pay for AI tools end up with at least two: Claude for thinking, ChatGPT for fast tasks, Cursor for code, plus Claude Code in the terminal. A Project of brand guidelines is invisible the moment you leave Claude. An MCP server lights up in all four.

You want write actions, not just reads. Updating a Notion page. Posting to Slack. Creating a Linear issue. Saving a bookmark with a tag. Projects can read its uploaded files. MCP servers can do anything they expose, including writes.

Your corpus is too big or too dynamic for upload. Your bookmark collection from the last three years. Your full Slack archive. A code repo with 10,000 files. Projects with the 30MB-per-file cap and the 200K context window starts to feel like a paper bag. MCP queries surgically: it pulls only the slice the AI asked for, even if the underlying source is enormous.

You want the AI to decide when to query. Drop an MCP server into Claude. Ask an open question. Claude reads the tool descriptions, decides which to call, and pulls the data. With a Project, Claude has to scan everything you uploaded to figure out what is relevant. With MCP, the server returns only what you asked for.

For a list of MCP servers worth running today, see 7 Best MCP Servers for Knowledge Workers (2026).

Where Claude Projects and MCP actually overlap

A small but useful overlap exists. Both can act as “Claude has read this background and will lean on it.”

A 50-page strategy doc you need Claude to reason over for the next month: either works. Upload it to a Project for instant access without setup, or run a Filesystem MCP server pointed at your strategy folder. The Project is faster to set up. The MCP server scales when the folder grows or when you start using the same docs in Cursor too.

Where Projects is uniquely good is the system instruction baked into the workspace. Where MCP is uniquely good is the AI choosing to query, live, across clients.

When in doubt: would you re-create this in another tool tomorrow? If yes, MCP. If no, Project.

Most useful stacks combine Claude Projects and MCP

Here is the part most posts miss. The smart move is not picking one. It is putting the small, fixed, instruction-heavy things in Projects, and the large, live, cross-client things in MCP.

A worked example.

A founder writes investor updates. Her stack:

• Claude Project: “Investor Updates” — holds the last six months of letters, the cap table, the brand voice doc, and a system instruction telling Claude how she writes. Files: 12. Total size: 8MB. Updates: monthly.
• MCP servers — Notion (live company docs), her ContextBolt bookmarks (saved articles she has reacted to), Filesystem (her drafts folder).

When she opens the project and asks “draft this month’s investor update”, Claude has the locked context (voice, last letters, cap table) from the Project, plus live access to whatever is in Notion and her bookmarks via MCP. The Project handles the slow-changing reference. MCP handles everything that moved this week.

This is the actual answer most “Projects vs MCP” posts dodge. Use Projects for a small, scoped reference. Use MCP for everything that breathes. They do not fight each other. They do different jobs at different layers of the same stack.

For a deeper look at what to plug in, see Claude Skills vs MCP: When to Use Each (2026) and 5 Personal Data Sources to Connect to Claude.

How ContextBolt fits

A worked example, since I run one.

ContextBolt captures bookmarks from X, Reddit, and LinkedIn into a Chrome extension, tags each one with AI, and exposes them through an MCP endpoint. The Pro tier ($6/month) gives you that endpoint for Claude Desktop, Claude Code, Cursor, ChatGPT Developer Mode, and any other MCP-compatible client.

Could you use Claude Projects for this instead? Technically yes, if you wanted to manually export every bookmark to a CSV, upload it to a project, and re-upload it every time you saved something new. Nobody does this because it is the wrong shape of solution. Bookmarks grow daily. They live across three social platforms. They want to be queried by meaning, not scrolled through.

ContextBolt is MCP because the data is live, the corpus is large, and you want the same bookmarks visible whether you are in Claude or ChatGPT. A Project would freeze the data the moment you uploaded it. An MCP server keeps the connection live.

If you also have a fixed reference doc, like a writing style guide, drop it in a Claude Project. Use the Project for the locked context. Use ContextBolt MCP for the bookmark layer. Stack them. They are not competing.

Claude Projects vs MCP: the question to ask before picking

Forget “Projects or MCP?” Ask three questions instead.

Does this knowledge change? Yes -> MCP. No -> either.

Do I use multiple AI clients? Yes -> MCP. No -> either.

Do I want a system instruction baked in? Yes -> Project. No -> either.

The combination of answers tells you which side wins for that knowledge source. Most personal stacks end up with one or two Projects (writing style, a locked reference doc) plus three or four MCP servers (Notion, bookmarks, filesystem, web search). That is the natural shape.

The mistake is treating them as competitors. Once you separate “this is a Claude feature for fixed knowledge” from “this is a protocol for live tool calls”, the choice becomes mechanical.

That is the whole framework. Projects is a place. MCP is a phone line. Use places for things that sit still. Use phone lines for everything else.