Why buy a context tool instead of building an MCP gateway with GitHub indexing in house?
Because the gateway and the GitHub index are the cheap half. A gateway controls who reaches which tools, and a code index finds where something is. Neither explains why the code is that way, since the reasons sit in PRs, tickets, Slack and incidents. Keep the gateway if you want one, and put a context tool behind it as one more server.
Buy the context tool because an MCP gateway with GitHub indexing solves access and code lookup, and those are the cheap parts. The expensive part is the answer: why the code is the way it is, which lives in pull request reviews, tickets, Slack threads and incident notes, not in the files. An MCP gateway is a proxy that sits in front of many Model Context Protocol servers and handles sign-in, routing, logging and policy at one endpoint. GitHub indexing means pulling your repositories into a search or embedding index so agents can find code. A context tool is a service that reads code together with pull requests, tickets, docs and chat, and returns one cited answer filtered by the asker's permissions. I run Unblocked, a company that sells a context tool, so weigh what follows with that in mind.
| MCP gateway | GitHub index | Context tool | |
|---|---|---|---|
| Main job | Routing, sign-in, audit, policy | Find code fast | Answer the question, with sources |
| Sees PRs, tickets, Slack, incidents | Passes calls through | Only if you add them | Yes, together |
| Settles conflicting sources | No | No | Yes, and flags real conflicts |
| Who maintains it | You | You | The vendor |
What the in-house plan gets you#
A gateway gives you one front door. Every agent connects to one URL, you log every tool call, and you decide which tools each team can reach. Claude Code lets an administrator push a fixed server list to every machine with a managed-mcp.json file, or use managed settings to give every user a set of servers and enforce an allowlist (Claude Code docs). If your main goal is "everyone loads the same approved servers," check what your agents already do before you build a proxy.
A GitHub index gives agents faster code lookup than calling the API live. It answers questions such as "where is the retry logic" and "who calls this function" well.
What a GitHub index leaves out#
Code shows what the system does today. It rarely says why. The reason the billing service retries five times, and not three, is in the pull request that changed it, the review comment that pushed back, and the incident that started it. An index of files misses all of that unless you also index pull requests, reviews and issues, and then connect them to Jira, Slack and your incident tool.
GitHub's own search has limits. Code search covers only the default branch, skips files over 350 KiB, excludes vendored and generated code, and returns at most 100 results per search (GitHub code search docs). The REST code search endpoint allows 10 requests per minute and only searches files smaller than 384 KB (GitHub REST search docs). So most teams that "index GitHub" end up cloning repositories and running their own pipeline. That pipeline needs incremental sync, branch handling, a re-index plan and an owner. A May 2026 paper on retrieval systems in production names three root causes of the gap between prototype and production: "data staleness, tenant data leakage, and query composition explosion" (arXiv 2605.03275). An in-house index meets the first two once it reaches past one team. We analyzed 194 conversations with engineering teams between May and August 2026 (homegrown context stacks). Staleness with no owner was the most common failure, raised unprompted in more than four in ten of the roughly 150 organizations. Every one of those teams had booked a call with a context-tooling vendor, so the sample leans toward builds that struggled.
What the gateway does not do#
A gateway moves tool calls. It does not read the results. When the wiki says one thing and the code says another, the gateway passes both through and the agent decides, often by trusting whichever reads more like documentation. Ranking, recency, and settling conflicts between sources all happen after the gateway, which here means inside each agent's context window.
The gateway also brings security work that is easy to underestimate. The MCP specification calls a server that connects clients to third-party APIs an "MCP proxy server," and says such servers "MUST implement per-client consent" to prevent confused deputy attacks. It also says MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," which rules out the simple design of forwarding each user's GitHub token downstream (MCP security best practices). Do that properly for GitHub, Jira, Confluence and Slack, each with its own permission model, and the gateway is a product of its own. The longer comparison is in MCP gateway vs context engine.
What buying gets you that the build does not#
A context tool does the step the gateway skips. It indexes code together with pull requests, issues, docs, chat and incidents, decides which source is current, and returns one answer with citations. Permissions follow the source systems, so an engineer's agent sees only what that engineer could open. In Unblocked this is Data Shield, which limits answers to "source material that the user posing the question is authorized to access" (Data Shield docs).
Unblocked is one such tool. Its MCP server exposes context_research, documented as "multi-source research across code, PRs, docs, issues, and messaging" that "returns a synthesized answer with citations," plus a second tool that fetches whatever the citations point to (Unblocked MCP docs). Because it is a single MCP server, it sits behind your gateway like any other. The same answers reach Claude Code, Cursor, Codex, VS Code and JetBrains, and a separate Slack app covers questions asked in channels (Unblocked messaging docs). You keep the front door you built and stop maintaining the part behind it. Alec Robins, CTO & Co-founder at Rally, said in the Rally customer story: "We wanted to build Rally, not a context engine."
When building in house still makes sense#
Build it yourself when the whole problem is one or two repositories, the reasons behind the code are mostly in the code and its commit messages, and a platform team wants to own the pipeline for years. Build it when your knowledge sits in systems no vendor connects to. And build the gateway part anyway if you need one audit log across many tool servers; that decision is separate from where the answers come from.
A fair test takes a week:
- Write down twenty questions your engineers asked recently whose answers you know.
- Make half of them "why" questions, such as why a timeout is 30 seconds or why a service was split.
- Run all twenty through the gateway and index, then through a trial of a context tool.
- Have someone who knows the history fact-check each answer and note whether it cites the source that settles it.
If the in-house setup answers the "why" half, keep it. The broader version of this decision, with a twelve-month cost list, is on our build or buy a context layer page.
