The Model Context Protocol (MCP) connects AI agents to tools and data sources. A context layer decides which knowledge an agent needs before it changes a specific part of your codebase. They are not competitors — they sit at different layers of the stack, and a serious AI-engineering setup needs both.
Since Anthropic introduced MCP in late 2024, it has become the default way to wire assistants into filesystems, databases, and SaaS APIs. That is a real and useful standard. But "my agent can reach the repo" and "my agent knows what it must not break in the repo" are different claims, and conflating them is how teams ship confident, wrong changes.
What MCP actually does
MCP is plumbing — and good plumbing. An MCP server exposes tools, resources, and prompts behind a uniform interface, so any MCP-compatible client can call them without a bespoke integration (see the MCP specification). Before the standard, every pairing of an AI app with a data source was a one-off connector; MCP collapses that many-to-many problem into something both sides implement once.
What MCP transports is access: the ability to list files, run a query, read an issue. What it does not transport is judgment: the fact that a particular file carries a non-obvious invariant, or that a tempting refactor was already tried and rolled back.
What a context layer does
A context layer answers a narrower, sharper question: given these files, what does whoever is about to change them need to know first? That means surfacing the decisions, gotchas, and invariants attached to the exact code in play — code-anchored context rather than a generic document dump.
MCP connects agents to tools. A context layer connects agents to repo context. Retrieval is moving information; context is knowing which information is the right information.
Why you need both
- MCP without context gives an agent the keys to your systems and no briefing. It can read everything and still miss the one constraint that matters, because that constraint was never written where it could be read.
- Context without access is a well-kept memory the agent cannot act on. The knowledge is correct but stranded.
- Both together is the goal: the agent can reach the code (MCP) and is told what the team already knows about it before it edits (the context layer).
A concrete example
Suppose an agent is asked to "speed up invoice rendering." Through MCP it opens the billing module, reads the code, and proposes caching the rendered invoice. Competent — and wrong, if six months ago the team decided invoice previews must never be cached because they reflect live tax rates. That decision lives in someone's memory, not in the code. A context layer delivers it at the moment of the edit; MCP, by design, never will.
How this maps to Driftless
Driftless is the context layer. Topics capture what a part of the codebase does, the decisions behind it, and the invariants that must hold — anchored to globs so they surface for the exact files an engineer or agent touches. It is delivered through the CLI and through MCP itself, so the access layer and the context layer compose:
driftless context get --files "src/billing/**"The result is not a summary of the code the agent can already read. It is the context behind the code, which it cannot.
FAQ
Does Driftless replace MCP?
No. MCP is the transport that lets agents reach tools and data; Driftless is the knowledge that tells them what to do with that access. Driftless is itself reachable over MCP.
Isn’t retrieval-augmented search enough?
Search helps an agent find information it asks for. It does not proactively warn an agent about a constraint it didn’t think to ask about. Context anchored to the files being changed is delivered without the agent knowing to request it. See retrieval-augmented generation.
Where do I start?
Pick one area that has burned the team before, write down the decision and the gotcha, and anchor it to that area’s files. Read more on repo memory and our note on context drift.
Driftless is the context layer for human–AI engineering teams. See how it works.