A Pile of MCP Connectors Is Not a Context Engine

Today, wiring an agent into your tools takes about ten minutes. Claude ships a connector catalog, there are MCP servers for GitHub, Slack, Jira, Notion, Google Drive and whatever else your team is paying for.

We frequently get the question: if Claude can already reach every source directly, what is Unblocked for?

The premise sounds right, but the conclusion is wrong. Connecting an agent to your sources gives it access. It does not give it understanding. The distance between those two is where most of the value lives, and where most of the cost hides.

What a connector actually gives you#

Give an agent a Slack MCP, a Jira MCP, and a GitHub MCP, and each one behaves the way its authors built it, often mapped 1:1 to the underlying API: you send a query, you get back a list of matching documents from that one system. Search Slack, get Slack messages. Search Jira, get Jira tickets.

That's genuinely useful for known-item lookups. "Fetch PR #4821." "Create a ticket in PROJ." If that's the whole job, connectors do it fine.

But the questions that actually slow engineers down don't sit inside one system. Take something like "why does the payment service retry like this?" The answer is spread across a PR review thread from last year, a Slack argument that never made it into any doc, a Jira ticket that got closed as won't-fix, and the code itself. No single connector holds more than a fragment of it. Which means someone (or something) has to assemble it.

With raw connectors, that somebody is your agent. At inference time, on your token bill.

Your agent becomes the integration layer#

Here's what cross-source research looks like when the agent does the stitching itself: query Slack with three or four keyword guesses derived from the quality of your prompt, query Jira, query GitHub, read a dozen results per source, notice a link, fetch it, guess again, repeat. Every intermediate result lands in the context window, relevant or not. Every hop is another turn. Every turn is another pile of tokens wasted.

None of that is hard, exactly. It's just slow, expensive and easy to get wrong, which is the same thing we said about humans doing it manually back when humans were the ones doing it.

We benchmark this constantly. We run the same task, same model, same codebase with a blind (LLM) judge:

• On a Kotlin SDK task, the agent with Unblocked context finished 83% faster, used 48% fewer tokens and cost 60% less. It scored 9.5/10 on following the team's conventions, where the agent without context scored 2/10.
• On a frontend feature-toggle task, 26.6% faster with 41.6% fewer tokens. The agent without context ran out of turns and never produced working code at all.

We also ran the same question through Claude Code internally, once with Unblocked and once without. The session without it spent 81 turns of subagent exploration crawling the codebase, roughly 84% of a session that cost about 10x more, and still came back with the wrong answer.

The session with Unblocked answered correctly in 40 seconds.

You shouldn't take our word for any of that, which is why we open sourced context-engine-simulator. Point it at your own repo, use your own tooling and your own model key, and see what the delta looks like on your codebase instead of ours.

The point isn't that agents are bad at searching. It's that "search each silo and reconcile the results" is a hard, expensive job and per-source connectors assign that job to the most expensive worker in the building: your frontier-model inference loop. Frontier labs have even written explicitly about separating the thinking model from the working model.

The agent doesn't know what it doesn't know#

There's an assumption buried in that retrieval loop: that the agent knows what to search for in the first place. Mostly it doesn't. It doesn't know your team calls the checkout rewrite "phoenix" in Slack and "checkout-v2" in Jira. It doesn't know the retry behavior was settled in a PR comment rather than a doc. It doesn't know the argument that settled it ever happened. You can't write a query for a conversation you don't know exists, in vocabulary you've never seen, against a system you didn't think to check.

Anthropic's Thariq Shihipar has good framing of this: the map is not the territory. The map is the prompts, skills, and context you hand the model. The territory is where the work actually happens. The gap between them is your unknowns, the points where the agent hits something it wasn't told and has to guess at what you wanted. With frontier models, his argument goes, the quality of the work is no longer limited by the model. It's "bottlenecked by my ability to clarify its unknowns."

His prescriptions are worth reading in full: blind spot passes, brainstorms, structured interviews, reference walkthroughs, implementation logs. They work. But look at what they cost. Each one is a human-in-the-loop ritual, re-run for every task, spending your time and your tokens rediscovering context that already exists somewhere in your org. And each one is bounded on both ends: an interview only surfaces what you already know how to answer, and a blind spot pass only scans what the agent can reach. The convention buried in three years of PR history survives both.

That's the case for attacking unknowns from the other end. Unblocked shrinks them before the session starts, at ingestion time instead of inference time. The engine has already mapped which system holds what, already learned that phoenix and checkout-v2 are the same project, already linked that PR to the Slack thread that reversed it. The agent doesn't have to know where to look, because the engine already knows what exists.

Sources disagree. Connectors don't care.#

Say the agent clears that hurdle and finds the information. A second problem is waiting: knowing which version of it is still true.

Almost every engineering org I've worked in looks like this: a Confluence page says one thing, a Slack thread three weeks later reversed it and nobody went back to update the page. The README documents the old auth flow, and the reasoning behind the new one lives in a review comment on the PR that replaced it.

An agent querying sources one at a time has no way to know which answer wins. It stops at the first plausible result, and "plausible" is exactly how you end up shipping code against a decision your team reversed months ago.

Unblocked's context engine does this reconciliation server-side, before anything reaches the agent: recency and authority signals resolve contradictions, and every answer carries citations so you can see the provenance. That's a different contract than search. Search tells you where information lives. A context engine tells you what's actually true.

Some knowledge doesn't live in any source#

Here's the deepest gap, and the one no amount of connector-chaining can close: some organizational knowledge cannot be constructed from queries to individual systems, no matter how many you run because it only exists in the patterns across systems, observed over time.

• Unwritten conventions. No document says "PRs touching the auth module always get a security review" or "changes near the order flow always run the payment integration tests first." Those rules exist only as patterns in years of PR history. You can't query for them; you have to have watched.
• Expertise topology. Who actually knows the payment service, not who the org chart says owns it? The answer is derived from who reviews those PRs on GitHub, who answers those questions in Slack, and who closes those bugs in Jira, weighted by recency. No single system holds it. It emerges only when you observe all of them, longitudinally.

Unblocked builds this continuously as part of ingestion: an institutional map of people, projects, conventions, and workflows that gets applied to every query. An agent with ten MCP connectors and an empty context window reconstructs none of it and it starts from zero on every session. That's a high price to pay in search tokens and wasted time.

Ten connectors is ten security surfaces#

There's an operational cost to the connector-mesh approach that security teams have started noticing. Every direct source connector you hand an agent is a separate credential, a separate permission model, and a separate slice of the "lethal trifecta" — an agent with access to sensitive data, exposure to untrusted content, and the ability to act. We hear this from platform and security teams weekly: they don't want an agent holding raw keys to Google Drive and Slack and Jira, each governed differently, each auditable separately.

Unblocked collapses that to one connection with server-side enforcement: permissions from every underlying source are propagated at ingestion and enforced before results leave the server, so an agent can only ever surface what the requesting user is authorized to see. One integration to govern, one surface to audit, and no source credentials living in an agent's configuration.

When a connector is the right call#

All that said, if the job is transactional, use a connector. Create the ticket, post the message, fetch the one file you already know you need. Unblocked is not trying to replace any of that, and plenty of our customers run both, with connectors handling the writes and Unblocked as the research layer their agents call when the question starts with why, who, or what did we already decide.

Access is table stakes. Understanding is the product.#

MCP made it easy to give agents access, and that's genuinely good. It's the reason Unblocked can deliver its context through a single MCP server into Claude Code, Cursor, Windsurf, Copilot, or anything else that speaks the protocol. But access was never the hard part. The hard part is turning ten systems' worth of partial, contradictory, decade-deep history into one decision-grade answer an agent can act on quickly enough to matter and cheap enough to run on every task.

That's not a feature a connector catalog grows into. It's a key building block of the future of agentic applications.

Run context-engine-simulator against your own repo. If the numbers come out differently than ours did, I'd like to hear about it.