Why would we need a separate context tool when Claude already has MCPs, projects and enterprise plans?
Because each of those holds context in one place. A Project holds uploaded files, CLAUDE.md holds one repo's rules, the plan holds admin controls, and a connector is one system's search box. None reasons across code history, PRs, Slack, Jira and incidents, follows the engineer into Cursor or Codex, or answers why. A separate context tool does that, delivered into Claude Code over MCP.
You need a separate context tool because each of Claude's features keeps context in one place, and engineering questions cut across places. A Project, a CLAUDE.md, an admin console and a connector are each good at their job. None of them reads the pull request, the Jira ticket, the Slack thread and the incident together and tells you why the webhook timeout is 30 seconds. A context tool is a service that indexes code, PRs, issues, docs, chat and incidents together, reconciles them, and returns one cited answer filtered by the asking person's permissions; Unblocked calls this a context engine. It sits beside Claude's features and reaches Claude Code over MCP.
| Claude feature | Holds | Does not do |
|---|---|---|
| Projects | Uploaded files and instructions, per project | Read code history, PRs or Slack |
| CLAUDE.md and auto memory | One repo's rules, under 200 lines | Travel to Cursor or Codex |
| Team and Enterprise plans | SSO, SCIM, audit logs, connector policy | Add knowledge of their own |
| Connectors and enterprise search | Live search of one system at a time | Join or rank results across systems |
What Claude's stack gives you, and it is a lot#
The question is fair, so start with the pieces. A Claude Project holds files and instructions for every chat inside it, and "when your project knowledge approaches the context window limit, Claude will automatically enable RAG mode" (Claude Projects help).
Claude Code's CLAUDE.md files and auto memory are "loaded at the start of every conversation" (Claude Code memory docs). The same page says "longer files consume more context and reduce adherence" and sets a target of under 200 lines per file.
The Team plan lists "enterprise search across your organization," SSO and "admin controls for remote and local connectors"; Enterprise adds SCIM, audit logs and role-based access (Claude pricing). Enterprise search is a pre-configured project that queries your connectors live. "You only see search results from data you have permission to access in the original systems," and "no data from connected services are indexed in our systems for serving queries" (enterprise search help). Admins can also push remote MCP servers to every Claude Code user with managedMcpServers (managed MCP docs).
That is a complete toolkit for rolling Claude out. The gap is in what the toolkit knows.
None of the pieces reasons across sources#
Take the question every new engineer asks: why does the webhook time out at 30 seconds? The answer is in four places: the code, a PR from last spring, a Jira comment, and the Slack thread after the incident that cut it from 60. A Project knows only what someone uploaded. A CLAUDE.md under 200 lines cannot carry one repository's history, let alone forty.
Enterprise search and connectors come closer. They still leave the join to the model. Enterprise search requires "a connector for both Documents and Chat" and queries each one live. On the API side, the Developer Platform's MCP connector supports "only tool calls" from the MCP feature set (MCP connector docs). So the model gets a Jira result, a Slack result and a GitHub result, each ranked by its own system. It then decides in the context window which one to trust. That decision is fragile. A January 2026 study of 13 open-weight models found their source preferences "can be reversed by simply repeating information from less credible sources" (Whose Facts Win?). We measured the cost of an agent gathering its own context in same prompt, same model, different context: 42% fewer tokens in that one run with Unblocked attached than with no MCP servers. The direct-MCP comparison covers the rest. A context engine does that join once and treats code as ground truth when the wiki disagrees (inside the Unblocked context engine).
Each feature stays inside its own product#
Projects live in claude.ai. CLAUDE.md lives in Claude Code and the repos it opens. Cursor keeps its own rules in .cursor/rules, "version-controlled and scoped to your codebase," with team-wide rules on its Team and Enterprise plans (Cursor rules docs).
So the same question gets a different answer depending on which tool asked it and whose laptop it ran on. For example, the engineer who tuned a CLAUDE.md gets good answers in Claude Code and loses them in Cursor. A context engine sits behind one MCP server that every agent can load, so Claude Code, Cursor, Codex, VS Code and JetBrains ask the same service and get the same cited answer.
Permissions are per connector, and the hard part is per source#
Anthropic handles this well, with one caveat. On Team and Enterprise plans, after an admin adds a connector, "users individually connect to and enable that connector," and "Claude can only access tools and data that the individual user has access to" (custom connectors help). Enterprise-managed auth is a second option that lets an admin "authorize a connector once for your entire organization," with Okta supported at launch (organization-wide connectors help).
The caveat is in the custom connectors article: a connector set up with a shared credential, such as an API key, "gives everyone who uses it that credential's access" in Claude. Any server a platform team builds to join sources has to solve per-user filtering itself, at query time. It is the most expensive thing to retrofit, as building a context engine on MCP notes. Unblocked ships it as Data Shield, which keeps "the permissions established in your connected third-party systems." An answer built from a private Slack channel and a restricted repo only reaches someone who can see both.
How the two fit together#
Keep everything Claude gives you and add one server. Projects keep shared prompts and reference files. CLAUDE.md keeps one repo's conventions. The plan keeps SSO, audit logs and connector policy. The context engine takes the cross-source and historical questions those cannot answer.
Austin Rojan, Onboarding Specialist at Subsplash, described the before and after: "Before Unblocked, I was manually compiling documentation into a local folder just so Claude Code could reference it. Now it pulls everything directly. I'm getting 90% accuracy on complex data structure questions that would have taken hours to figure out. It eliminated work that was genuinely mind numbingly arduous." The Unblocked MCP docs describe what replaced that folder: one server, two tools. That folder is the Project-and-CLAUDE.md approach done by hand, and most teams are there before they look for a separate context tool.
Skip the extra tool when questions do not cross sources: one repo, a small team, history short enough to fit in a Project. The signal to add one is the first time an engineer asks Claude why something was built that way and gets an answer assembled from whichever connector returned first.
