MCP moves context. It doesn't create it.

An engineer argues that the Model Context Protocol (MCP) moves context but does not create it, highlighting that while MCP simplifies tool integration for AI agents, it fails to resolve cross-system facts and state. The post contrasts connectors, enterprise search, iPaaS, per-agent memory, and organizational memory layers, concluding that a memory layer is needed to resolve evolving risks and stale data.

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. 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: php "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 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. 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. 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. 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. 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. 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 https://www.sentra.app/research/terminal-bench . 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. 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.