MCP moves context. It doesn't create it.

Taran Singhania — Fri, 21 Aug 2026 15:05:29 +0000

The first time you wire Claude to a real tool and watch it work, it feels like the future showed up early. It reads a file, inspects a database, searches a repo, opens a ticket, and stitches an answer out of systems that used to need ten browser tabs.

Two hours later you ask it something that spans two of those tools, and it confidently tells you something that stopped being true in March.

That gap is not a model problem, and more connectors will not close it. MCP moves context. It does not create context.

What MCP actually solves

The Model Context Protocol is an open standard for connecting AI applications to external systems. The official docs use the analogy of a USB-C port for AI applications, and that is the right mental model: one protocol instead of a pile of bespoke integrations with slightly different auth, schemas and failure modes.

Adding a remote MCP server to Claude Code is one line:

claude mcp add --transport http sentra https://api.sentra.app/mcp/

Or declaratively, for a client that reads a config file:

{
  "mcpServers": {
    "sentra": {
      "url": "https://api.sentra.app/mcp/",
      "headers": {
        "Authorization": "Bearer sk_sentra_YOUR_KEY"
      }
    }
  }
}

That is genuinely infrastructure, and it deserves the hype. Tool access stopped being every vendor's custom problem.

For what I would call level-one questions, this is enough:

"What is the status of ticket ENG-4471?"     -> one system, one lookup
"Summarize the last call with Acme."          -> one transcript
"When does the Acme contract renew?"          -> one CRM field

Where it stops

Now try a question that lives between tools:

"Is Acme at risk of churning, and why?"

There is no system that holds the answer. The pieces are scattered:

Where the evidence lives	What it says
CRM	Renewal in 47 days, stage unchanged for 6 weeks
Gong transcript, 12 Mar	Champion sounded frustrated about latency
Support	Two escalations, second one never followed up
Slack #eng-acme	An engineer explains the real blocker
Roadmap doc	The fix slipped a quarter
Meeting, 3 Apr	An exec promised a date that no longer holds

MCP will happily fetch all six. It will not tell the agent that these six form one evolving risk, that the promised date is stale, or that the support escalation contradicts the CRM stage.

So the agent gets artifacts. It does not get state.

The connector landscape, honestly

If you are choosing how to give agents access to Slack, Jira, email and tickets, these are the real options, and they solve different problems:

Approach	Good at	Structurally cannot
MCP servers	One integration serving many agents; growing ecosystem of community and vendor servers	Decide what any of the data means, or whether it is current
Enterprise search (Glean and similar)	Broad connector coverage, permissions mirrored from each source	Return facts rather than documents; it hands back ranked artifacts
iPaaS (Zapier, Workato, n8n)	Hundreds of prebuilt connectors, fastest path to moving data	Answer questions; these are built to trigger actions, so agents get events, not understanding
Per-agent memory (Mem0, Zep, Letta)	Durable recall for one agent in one application	Share what one agent learned with the other agents in your company
Organizational memory layer	Resolve cross-system facts with time, provenance and permissions	Be lightweight; this is real infrastructure and you feel it

The dividing line that matters: connectors move content, a memory layer resolves it. When two systems disagree, a connector faithfully delivers both answers and leaves the agent to guess.

Query time versus write time

The obvious objection: let the agent figure it out at query time. Give it every tool, let it search, let it reason.

You can get far that way, and Anthropic's own context-engineering guidance describes just-in-time strategies where agents load information at runtime through references. Every serious agent system will use some version of it.

But at query time the agent is reconstructing the world after the fact. On every single request it has to:

1. identify which systems might hold the answer
2. search each one
3. resolve identities  (is "Acme Inc" the same as "Acme Corporation"?)
4. compare timestamps
5. detect which artifacts went stale
6. reconcile contradictions
7. infer permissions
8. and *then* answer the actual question

Steps 1 through 7 are rediscovery. Your agent pays for them in tokens and latency, on every request, forever, and it re-derives them from residue rather than from the moment the change happened.

Because here is the thing: some meaning is only cheap to capture when the work happens.

A customer promise is clearest the moment it is made
A decision reversal is clearest when the meeting ends
A contradiction is clearest when a new commitment conflicts with an old one
A handoff is clearest when ownership actually moves

Write-time memory records the state change as work arrives, with provenance and validity, instead of waiting for an agent to ask the perfect question three weeks later.

The distinction in one line: query time retrieves artifacts, write time captures state transitions. Companies do not run on artifacts. They run on changes.

What that looks like in a response

Query-time retrieval returns documents, and your prompt absorbs all of them:

{
  "results": [
    { "source": "gdrive", "title": "Acme QBR deck v3", "chunk": "...2400 tokens..." },
    { "source": "gdrive", "title": "Acme QBR deck v2", "chunk": "...2200 tokens..." },
    { "source": "slack",  "channel": "#eng-acme",     "chunk": "...1800 tokens..." },
    { "source": "crm",    "record": "Opportunity",     "chunk": "...900 tokens..." }
  ]
}

Four results, roughly 7,000 tokens, two of which contradict each other, and nothing marking which is current.

A write-time layer answers with resolved facts instead:

{
  "facts": [
    {
      "statement": "Acme's latency fix slipped to Q3",
      "valid_from": "2026-04-03",
      "supersedes": "fact_8812 (Q2 commitment, 2026-03-12)",
      "source": "meeting:2026-04-03#turn-58",
      "visible_to": ["role:account-team"]
    },
    {
      "statement": "Acme champion raised latency as a renewal blocker",
      "valid_from": "2026-03-12",
      "source": "call:acme-qbr#turn-22",
      "confidence": "high"
    }
  ]
}

Two facts, a few hundred tokens, each with provenance, a validity window, and an explicit record of what it replaced. The superseded Q2 commitment is not returned alongside its replacement, which is the whole point.

Does this actually pay for itself?

Some numbers from our own evaluation, so treat them as vendor-run and check the methodology rather than taking my word: on Terminal-Bench 2.1, an agent given a task-scoped memory layer reached 88.31% mean reward against an 83.37% published baseline across 445 trials, with 72.6% lower model cost and 41.2% fewer tokens. Per-task trial data is published at our Terminal-Bench writeup.

Accuracy up and cost down at the same time is the signature you expect when the mechanism is less but better context, rather than a smarter model.

The decision rule

Use MCP. It is the right wire, and the ecosystem is going to keep getting better.

Just be clear about what it is: MCP is the finger pointing at the moon. It gets your agent to the systems where work happens. Whether the agent understands what it finds there is a separate layer, and if you skip it, every agent you deploy will rediscover your company from scratch, expensively, and sometimes wrongly.

If your agents answer single-system questions, connectors are enough. The moment two systems can disagree about the same fact, you need something that decides which one is true.

I work on Sentra, where we build that layer as a company brain: cross-system facts with time, provenance and role-scoped access, served to agents over MCP. If you want the longer argument without the code, the original essay is here. If you are weighing connector approaches specifically, we keep an honest comparison of the options above.

DEV Community: Sentra