Every Developer on Your Team Has a Different MCP Config. Nobody Is Managing It.

Ask an engineering manager what MCP servers their developers are running, and most of them cannot answer. Ask a security engineer which third-party MCP servers have access to the company's codebase, and the answer is usually some version of "I don't know, but I'm pretty sure it's a lot." Ask a developer what MCP servers their teammates are using, and they will describe their own config but trail off when asked about anyone else's.

MCP setup is personal. Each developer configures it themselves, from documentation and README instructions, on their own machine, with whatever tools they decide to use. That is fine for individual productivity. It is not fine when your team's AI tooling is touching your production codebase and you have no visibility into what it is doing, who authorized it, or where the data is going.

What config drift looks like after six months

Teams that roll out AI tools without a governance model discover something consistent: within six months, there is no such thing as "the team's MCP setup." There is a collection of individual configurations that started from the same instructions and diverged from day one.

What a typical 12-person team's MCP configs look like after 6 months:
  -> 4 developers on Context+ MCP (different versions)
  -> 3 developers on a community codebase MCP they found on GitHub
  -> 2 developers on no codebase MCP (gave up on setup)
  -> 2 developers on a paid service MCP (personal accounts)
  -> 1 developer on a custom internal MCP nobody else knows about
  -> Zero developers with identical codebase context
  -> Zero audit visibility into what any of them are querying

The consequences of this configuration divergence are not immediately visible. The team appears to be using AI tooling. Developers appear to be getting codebase context in their AI sessions. But the quality of that context differs by developer based on which MCP they chose, which version they are running, and how recently their local index was refreshed. Two engineers debugging the same service may be working from fundamentally different AI context about how that service behaves.

The quality inconsistency is frustrating but recoverable. The security gaps are not.

What nobody owns

Per-developer MCP setup has no natural owner for the governance questions that matter most in a professional engineering environment. Those questions do not belong to any individual developer, and they are not answered by telling developers to be thoughtful about their tooling choices.

What nobody owns in the per-developer MCP model:
  -> Which MCP servers are approved for use with company codebases
  -> Whether MCP servers have been reviewed for data handling
  -> What versions are running across the team
  -> Which developers have which integrations connected
  -> What happens when a developer's MCP server sends data to a third party
  -> How to revoke access when a developer leaves
  -> Whether the context any given developer is using is current or stale

The "which MCP servers are approved" question is the one that tends to trigger a governance reckoning. When a security team or a compliance auditor asks this question and the answer is "whatever each developer decided to install," the follow-up questions get harder: What data does each of those servers send externally? What are the data retention policies of those servers' vendors? Have those vendors been reviewed under your vendor security assessment process?

Most MCP servers are open-source projects maintained by individuals or small teams. Some of them send context to external APIs. Some of them store conversation history. Some of them have not been updated in months. None of this is visible from the per-developer config model, because the per-developer config model was not designed with organizational governance in mind — it was designed for individual developer convenience.

The approved-tool list problem

Most engineering organizations maintain an approved software list — a set of tools that have gone through security review, procurement, and vendor assessment. When AI tooling was limited to IDE plugins and standalone applications, getting these tools on the approved list was straightforward. The tool was a defined artifact with a vendor, a privacy policy, and a terms of service.

MCP servers break this model. They are not installed the same way software is installed. They are configured in a JSON file, pulled from npm at runtime, and capable of connecting to external services in ways that are not visible from the configuration surface alone. A developer adding a codebase MCP from GitHub is not going through a procurement workflow. They are copy-pasting a configuration block.

Security teams that understand this have two options: block all MCP usage (which defeats the productivity benefit) or establish an approved list of managed, reviewed MCP endpoints that developers are directed to use instead of self-selecting from the open ecosystem. The second option requires someone to own and maintain the approved list, which requires centralization.

Inconsistent context produces inconsistent AI output

Beyond security, the consistency problem has direct productivity consequences. When two developers are working on the same feature and their AI coding assistants are drawing on different codebase context, the AI output they receive diverges in ways that are not obvious until the code is reviewed. One developer's AI understood the payment service's retry logic because their MCP indexed it. Another developer's AI hallucinated the retry behavior because their local index was three weeks stale.

Code review catches this kind of divergence, but only after the time and energy of writing the wrong code was already spent. The root cause is not developer error or AI model failure — it is an absence of shared context infrastructure that ensures every developer is working from the same understanding of the system.

This is the same problem that documentation tools solved by centralizing docs in wikis: a shared source of truth produces more consistent behavior than N copies of individual notes. Codebase context tools are relearning the same lesson.

What centralized governance actually looks like

The governance model that resolves this is not more rules for developers to follow. It is a managed MCP endpoint that makes the right choice the default choice — where connecting to the team's codebase context requires adding one endpoint string to your editor config, not selecting from a menu of open-source MCP servers and hoping you picked the right one.

What governance looks like with a centralized managed MCP:
  -> One approved server for the whole team
  -> One integration per external system (GitHub, Jira, etc.)
  -> Consistent codebase context for every developer
  -> Access managed at the organization level, not the individual level
  -> Audit log of all queries through one system
  -> Single point of revocation when a developer off-boards
  -> Security review of one platform, not every developer's config

Kognita provides this model. The organization connects repositories once. Developers add a single Kognita MCP endpoint to their editor configuration. That endpoint is the team's codebase context — not twelve different MCPs, not five different versions, not a mix of stale and current indexes. One endpoint, centrally managed, consistently maintained, with access governed at the organization level.

The security team can point to one vendor for their assessment process. The compliance team can see one audit surface. The engineering manager can tell a developer on day one exactly what to configure, with confidence that it matches what everyone else on the team is using. The developer who leaves the company has their access revoked in one place, not through a request to go find and delete their local MCP config.

The governance question is not optional

AI tools touching production codebases are becoming standard infrastructure, not experiments. As they mature from experiments to infrastructure, the governance questions that apply to all infrastructure apply to them: who owns it, who can access it, what data does it handle, and who is responsible when something goes wrong.

Per-developer MCP configs were the right model for the experimental phase. They are not the right model for teams that rely on AI coding tools as a core part of how they build software. At that point, the tooling needs governance, and governance requires centralization.

Final take

Twelve developers with twelve different MCP configurations is not a team with AI tooling. It is twelve individuals with personal AI setups who happen to work at the same company. That distinction matters when a compliance audit asks how the company governs AI access to its codebase, or when a security incident requires tracing which tools had access to which systems.

The answer to the governance problem is not a policy document. It is an architecture that puts codebase context in one managed place, with consistent access, consistent quality, and a single point of audit, instead of distributing it across personal developer configs with no oversight.

When AI tools become team infrastructure, they need to be governed like team infrastructure. Per-developer MCP configuration was appropriate for experimentation. Production use requires a shared managed endpoint that engineering leadership actually owns.