{"slug": "mcp-moves-context-it-doesn-t-create-it", "title": "MCP moves context. It doesn't create it.", "summary": "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.", "body_md": "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.\n\nTwo hours later you ask it something that spans two of those tools, and it confidently tells you something that stopped being true in March.\n\nThat gap is not a model problem, and more connectors will not close it. MCP moves context. It does not create context.\n\nThe 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.\n\nAdding a remote MCP server to Claude Code is one line:\n\n```\nclaude mcp add --transport http sentra https://api.sentra.app/mcp/\n```\n\nOr declaratively, for a client that reads a config file:\n\n```\n{\n  \"mcpServers\": {\n    \"sentra\": {\n      \"url\": \"https://api.sentra.app/mcp/\",\n      \"headers\": {\n        \"Authorization\": \"Bearer sk_sentra_YOUR_KEY\"\n      }\n    }\n  }\n}\n```\n\nThat is genuinely infrastructure, and it deserves the hype. Tool access stopped being every vendor's custom problem.\n\nFor what I would call level-one questions, this is enough:\n\n``` php\n\"What is the status of ticket ENG-4471?\"     -> one system, one lookup\n\"Summarize the last call with Acme.\"          -> one transcript\n\"When does the Acme contract renew?\"          -> one CRM field\n```\n\nNow try a question that lives *between* tools:\n\n```\n\"Is Acme at risk of churning, and why?\"\n```\n\nThere is no system that holds the answer. The pieces are scattered:\n\n| Where the evidence lives | What it says |\n|---|---|\n| CRM | Renewal in 47 days, stage unchanged for 6 weeks |\n| Gong transcript, 12 Mar | Champion sounded frustrated about latency |\n| Support | Two escalations, second one never followed up |\n| Slack #eng-acme | An engineer explains the real blocker |\n| Roadmap doc | The fix slipped a quarter |\n| Meeting, 3 Apr | An exec promised a date that no longer holds |\n\nMCP 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.\n\nSo the agent gets artifacts. It does not get state.\n\nIf you are choosing how to give agents access to Slack, Jira, email and tickets, these are the real options, and they solve different problems:\n\n| Approach | Good at | Structurally cannot |\n|---|---|---|\nMCP servers |\nOne integration serving many agents; growing ecosystem of community and vendor servers | Decide what any of the data means, or whether it is current |\nEnterprise search (Glean and similar) |\nBroad connector coverage, permissions mirrored from each source | Return facts rather than documents; it hands back ranked artifacts |\niPaaS (Zapier, Workato, n8n) |\nHundreds of prebuilt connectors, fastest path to moving data | Answer questions; these are built to trigger actions, so agents get events, not understanding |\nPer-agent memory (Mem0, Zep, Letta) |\nDurable recall for one agent in one application | Share what one agent learned with the other agents in your company |\nOrganizational memory layer |\nResolve cross-system facts with time, provenance and permissions | Be lightweight; this is real infrastructure and you feel it |\n\nThe 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.\n\nThe obvious objection: let the agent figure it out at query time. Give it every tool, let it search, let it reason.\n\nYou 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.\n\nBut at query time the agent is reconstructing the world after the fact. On every single request it has to:\n\n```\n1. identify which systems might hold the answer\n2. search each one\n3. resolve identities  (is \"Acme Inc\" the same as \"Acme Corporation\"?)\n4. compare timestamps\n5. detect which artifacts went stale\n6. reconcile contradictions\n7. infer permissions\n8. and *then* answer the actual question\n```\n\nSteps 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.\n\nBecause here is the thing: **some meaning is only cheap to capture when the work happens.**\n\nWrite-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.\n\nThe distinction in one line: **query time retrieves artifacts, write time captures state transitions.** Companies do not run on artifacts. They run on changes.\n\nQuery-time retrieval returns documents, and your prompt absorbs all of them:\n\n```\n{\n  \"results\": [\n    { \"source\": \"gdrive\", \"title\": \"Acme QBR deck v3\", \"chunk\": \"...2400 tokens...\" },\n    { \"source\": \"gdrive\", \"title\": \"Acme QBR deck v2\", \"chunk\": \"...2200 tokens...\" },\n    { \"source\": \"slack\",  \"channel\": \"#eng-acme\",     \"chunk\": \"...1800 tokens...\" },\n    { \"source\": \"crm\",    \"record\": \"Opportunity\",     \"chunk\": \"...900 tokens...\" }\n  ]\n}\n```\n\nFour results, roughly 7,000 tokens, two of which contradict each other, and nothing marking which is current.\n\nA write-time layer answers with resolved facts instead:\n\n```\n{\n  \"facts\": [\n    {\n      \"statement\": \"Acme's latency fix slipped to Q3\",\n      \"valid_from\": \"2026-04-03\",\n      \"supersedes\": \"fact_8812 (Q2 commitment, 2026-03-12)\",\n      \"source\": \"meeting:2026-04-03#turn-58\",\n      \"visible_to\": [\"role:account-team\"]\n    },\n    {\n      \"statement\": \"Acme champion raised latency as a renewal blocker\",\n      \"valid_from\": \"2026-03-12\",\n      \"source\": \"call:acme-qbr#turn-22\",\n      \"confidence\": \"high\"\n    }\n  ]\n}\n```\n\nTwo 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.\n\nSome 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).\n\nAccuracy 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.\n\nUse MCP. It is the right wire, and the ecosystem is going to keep getting better.\n\nJust 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.\n\nIf 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.\n\n*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.*", "url": "https://wpnews.pro/news/mcp-moves-context-it-doesn-t-create-it", "canonical_source": "https://dev.to/sentraai/mcp-moves-context-it-doesnt-create-it-36of", "published_at": "2026-08-21 15:05:29+00:00", "updated_at": "2026-08-21 15:15:22.394067+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["MCP", "Claude", "Glean", "Zapier", "Workato", "n8n", "Mem0", "Zep"], "alternates": {"html": "https://wpnews.pro/news/mcp-moves-context-it-doesn-t-create-it", "markdown": "https://wpnews.pro/news/mcp-moves-context-it-doesn-t-create-it.md", "text": "https://wpnews.pro/news/mcp-moves-context-it-doesn-t-create-it.txt", "jsonld": "https://wpnews.pro/news/mcp-moves-context-it-doesn-t-create-it.jsonld"}}