Claude project knowledge vs an MCP server: which one knows what changed?

Claude's project knowledge is a folder of files copied from your repository, frozen at your last click on "Sync"; an MCP server is a source Claude queries at the moment the question is asked. Both give Claude context about your product. Neither gives the same context, and never at the same date.

The difference is not about model quality. It comes down to three things: how fresh what Claude reads is, whether git history is there at all, and who is allowed to ask. This article takes one ordinary week in a repository and looks, day by day, at what each route knows at that moment.

The short answer, in two definitions

Project knowledge is the knowledge base attached to a Claude Project. You upload documents to it, or you sync files from a GitHub repository into it. Claude reads that pile of files as conversation context.

An MCP server is not a folder. It is a service Claude calls while it answers, with the user's question in hand. There is nothing to copy up front, because nothing is copied at all.

Hence the line that separates them: project knowledge answers from a snapshot, an MCP server answers from the source.

One week in a repository, seen from both sides

Take an ordinary application repository. The events below are an illustrative scenario; the mechanics they trigger are documented and quoted further down.

Monday, 9am. A developer syncs the repository into a Claude Project. At that minute the two routes are level. Claude knows Monday morning's code.

Monday, 4pm. A fix changes the default value of a purge setting, from 30 days to 7. The commit is pushed. Project knowledge still holds 30. The MCP server sees the new code as of the push.

Wednesday. A customer writes to support: their data vanished earlier than expected. The support agent asks Claude. The Project answers 30 days, confidently, because that is what it reads. The answer has been wrong for forty-eight hours, and nothing in the conversation flags it.

Thursday. A developer reopens the thread and asks the real question: why did that value change? Here project knowledge does not get it wrong. It does not answer at all. Files say what the code does today, never why it stopped doing something else. Intent lives in the diff and in the commit message, and neither was synced.

Friday. Someone asks what changed in the product this week. Project knowledge cannot answer: it holds one state, not two, and a difference needs two. You would have to compare Monday's folder with Friday's, which assumes you kept the first one.

Five days, three missed questions. Not one of them was missed for lack of intelligence.

What Claude's documentation actually says

None of this is guesswork. It is written in Claude's public documentation, re-read on 15 September 2026:

• Syncing is manual. The help centre describes the gesture: click "Sync now" to pull the latest changes after the repository has been updated.
• History is not retrieved. The wording leaves no room: only files on a given branch, names and contents, are synced, and "we do not retrieve commit history, PRs, or other metadata".
• One branch at a time. Selection happens branch by branch in the file browser.
• Size matters. The repository has to fit within Claude's context window. On paid plans a RAG mode takes over as the limit approaches, with a stated capacity gain of up to ten times.

None of these is a design flaw. A project knowledge base is built for stable documents: a specification, a brand guide, a style guide. Code is not a stable document. It changes several times a day, and its informative value often sits in the change itself.

The three questions that decide

Which date? Project knowledge carries the date of your last click. An MCP server carries the date of the last push. On a product that ships weekly, the gap between the two is precisely the window during which your answers are wrong without saying so.

Is the past readable? A folder of files describes a present. The questions that keep a support desk, a help centre and a changelog alive are about transitions: what is new, what was fixed, what went away. They need commits and diffs. The documentation says those are not there.

Who is asking? This is the part most often missed. Project knowledge lives inside one person's Claude Project, fed by that person's GitHub credentials. It does not serve your support agent, an agency's client under NDA, or a contractor with no repository access. An MCP server hands out answers rather than access, and connects to askers who will never hold a token on your code.

"I'll just click Sync"

This is the first objection, and it deserves better than a quick dismissal. It is partly right: a click fixes freshness. It does not fix the other two gaps.

A click does not make commit history appear, since the documentation says it is not retrieved. And it only happens if somebody knows it is due. That is the quiet failure in this model: you click "Sync" when you remember the code changed, which mostly means when you are the developer who changed it. The people who most need the update are the ones who do not know it is owed.

The tooled option exists too, and we have written it up: the official GitHub MCP server gives API access, diffs included, one call per commit. It is a good tool for an equipped developer. It wants a token per asker, which lands you back on the third question above.

"But DeployIt reads my repository too"

It does, and it is the same family of mechanism with a different split of roles. DeployIt's GitHub connection is read-only and revocable at any time. Content is re-synced on every push, with no human gesture. There is one server per project, not blanket access to your organisation.

More to the point: what leaves the server is answers sourced to commits and diffs, not raw code files. Your agents and your teams get the information; the code stays in the repository. That asymmetry is what makes a third-party support platform connectable without handing it a GitHub token — see how to plug a support agent into the codebase.

When project knowledge is plenty

Keep it in three cases, without hesitating.

A repository that fits in the context window and that you read yourself to write code: Claude has whole files in view, which is more direct. A stable documentation base, a specification or a settled architecture decision: the format suits it. And any one-off exploration where day-level freshness has no effect.

The switch happens when the question stops being about the code as it stands and starts being about what changed, or when the person asking is not the person holding the credentials. At that point no Project setting closes the gap, because a setting is not what is missing.

Mini-FAQ

Can you run both? Yes, and many teams do. A developer keeps the Project for writing code, and queries the MCP server for release and history questions. The two routes compete over nothing.

How long does project knowledge stay wrong? For the time between the push and the next click. Nobody measures that duration, which is what makes it uncomfortable: the answer stays plausible for its whole lifetime. We cover this in our piece on detecting documentation drift.

Is an MCP server slower? It adds a network call during the answer. In exchange it does not add your whole codebase to the context window, which usually makes the whole thing lighter.

Is this the same as a RAG index? No, and the comparison deserves its own page: an index is built in advance, an MCP server explores at the question. The detail is in MCP vs RAG for codebase knowledge.

What to take away

Claude project knowledge is a snapshot of files: one branch, one date, no history, one identified asker. It is useful, it is free, and for plenty of uses it is the right tool.

An MCP server answers as of the last push, with commits and diffs, to askers who need no repository access. The day your first question of the week starts with "what changed", the folder of files has already lost.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server is in early access, and the design partner program is taking applications.