You Set Up a Codebase MCP for Claude. Your Product Manager Still Can't Use It.

The codebase MCP is configured. It is working. Claude Code has richer context about your repository than it has ever had. And your product manager is still messaging a developer to ask whether the feature they are speccing is feasible, because they have no way to ask the codebase directly.

This is the part of the codebase MCP success story that does not make it into the setup guides: MCPs are a developer interface. They require a code editor, an MCP-compatible client, and some level of technical fluency to configure and use. They are excellent at what they do for developers. But the moment you ask whether non-technical team members can use a codebase MCP to answer system questions, the answer is no — and that no has consequences for the rest of the team every day.

What a codebase MCP actually is

A Model Context Protocol server is a process that an AI client connects to in order to receive additional context. For a codebase MCP, that context is semantic information about your repositories: function signatures, dependency graphs, service relationships, behavioral patterns. The MCP delivers this context to the AI model during a session, so the model can make more grounded inferences about the system it is being asked about.

To use a codebase MCP, you need a client that speaks MCP. Today that means code editors: Cursor, Windsurf, VS Code with the right extension, Claude Code in the terminal. You configure the MCP server in a JSON settings file, provide credentials or API tokens, and the editor handles connecting to the server during your AI session.

What a developer needs to use a codebase MCP:
  -> A code editor that supports MCP (Cursor, Windsurf, VS Code with extension)
  -> A local or cloud MCP server configured in their editor's JSON settings
  -> API credentials or OAuth tokens for the MCP server
  -> Ideally: a local repository checkout for tools that run locally
  -> Technical familiarity with JSON config files and environment variables

Every item on that list is something a developer maintains as a matter of course. None of it is standard equipment for a product owner, support lead, scrum master, or engineering manager. They are not going to configure a JSON settings file to ask the system a question. They are going to open Slack and message an engineer.

Who is asking codebase questions and where those questions go

Codebase questions do not only originate from developers. A product owner writing a feature spec needs to know whether the current system can support the behavior they are designing. A scrum master estimating a story needs to understand which services are involved. A support lead receiving an escalation needs to know whether the described behavior is a bug or expected. An engineering manager asked about release risk needs to understand which components are in scope.

Codebase questions that come from non-developers every day:
  -> "Which services does this epic touch?" (PM writing a rollout plan)
  -> "Is this customer complaint a known bug or expected behavior?" (Support)
  -> "Can we ship this feature before the payment provider integration?" (Scrum master)
  -> "Which teams own the services that could be affected by this change?" (Engineering manager)
  -> "How does the subscription renewal logic actually work?" (Customer success)
  -> None of these people have a code editor with a codebase MCP configured

These questions exist regardless of whether the team has a codebase MCP configured. The only difference is where they go. Without accessible codebase intelligence, every one of them routes to an engineer. The engineer answers — or defers, or gives a partial answer from memory, or schedules time later that week. The person asking waits. The team moves slower than it should.

With a codebase MCP that only developers can access, nothing about this changes for non-developers. The MCP improved the developer's AI sessions. It did not touch the information asymmetry between technical and non-technical team members at all.

The access format is the barrier

It is worth being precise about what is excluding non-technical team members. It is not a permissions problem — they could theoretically be given credentials to a codebase MCP server. It is an access format problem. MCPs are accessed through developer tools that non-technical team members do not use and have no reason to install.

Asking a product manager to install VS Code and configure an MCP JSON settings file so they can ask system questions is not a reasonable workflow. It is a significant technical barrier that most non-developers will not clear, and should not be expected to clear. Their job is not to become developers — their job is to make good product decisions, and good product decisions benefit from system knowledge they currently cannot get without an engineer's help.

This is the architectural limitation of every codebase MCP that is accessed exclusively through IDE tooling: the format of access is inherently developer-facing, even if the information it provides would benefit anyone on the team.

What the gap costs in practice

Consider what happens in a typical sprint when product needs a feasibility answer. A product manager is writing a spec for a feature that involves changes to the subscription renewal flow. They want to know which services are involved and whether there are any existing constraints that would affect the implementation timeline. Without system access, they ask the nearest available engineer.

The engineer answers from memory or looks at the code. The answer takes 20 minutes to an hour of engineer time. If the engineer is in a deep work session, the PM waits a day. If the engineer's answer is incomplete — because they are not the owner of the renewal service — the spec gets written with a gap that surfaces two weeks later in engineering review.

With a codebase MCP that developers use, the developers themselves can answer these questions faster during their AI coding sessions. But the PM still cannot ask the question directly. The engineering dependency for basic system understanding is intact.

The interface that actually works for non-technical teams

The interface that removes the engineering dependency for non-technical team members is not a different MCP. It is a plain-language dashboard: a web interface where a product manager can type "which services does the subscription renewal flow touch?" and get a grounded answer in plain English, without configuring anything technical first.

Kognita provides both interfaces in the same platform. Developers get a cloud-hosted MCP endpoint they plug into their editor. Non-technical team members get a dashboard where they ask questions in plain language and get answers grounded in the same indexed codebase. The same underlying semantic index powers both interfaces — the difference is only in the access format.

This means that when a PM asks about the subscription renewal flow, they get the same quality of answer that a developer's AI would get through the MCP — not a best-guess from an engineer's memory, not a reference to documentation that may be out of date. Actual behavior from the actual codebase, presented in language that does not require reading code to understand.

Why this matters now

The argument for giving non-technical team members direct codebase access has been around for a while. What changes with AI is that the translation layer — converting raw code into plain language — now exists and works well enough to build products on. The blocker was never the willingness of PMs or support leads to understand systems. It was the cost of translation.

Codebase MCPs removed that cost for developers by letting AI handle the translation in context. The same capability, extended through a different access format, removes it for the rest of the team. What is not inevitable is configuring a codebase MCP for developers and stopping there, treating the half of the team that cannot access developer tools as an acceptable casualty of the tooling architecture.

Final take

A codebase MCP is a meaningful improvement for developers who use AI coding tools. It is not a codebase access solution for a team. The format of access — JSON config files, code editors, developer credentials — is architecturally limited to people who maintain development environments.

The half of the team that does not use code editors still needs system understanding to do their jobs. They still make decisions that depend on knowing how the system behaves. They still route those questions to engineers when they have no other option. Adding a developer-facing MCP does not change any of that for them.

Codebase intelligence is not just a developer problem. It is a team problem. The tool that solves it needs to work for the product owner writing a spec, the support lead debugging an escalation, and the scrum master planning a sprint — not just the engineer in an AI coding session.