How MCP Changed AI Code Review

The short version

MCP killed the chat-and-paste workflow for code review. Your AI client calls the review tool, the tool runs, the result shows up inline. That's it.

Before MCP, getting a second model to look at your code meant copying the diff into another tab, pasting, waiting, and copying the answer back. Review was a ritual. Now it's a function call.

Joint Chiefs ships as an MCP server exposing a single tool — joint_chiefs_review. Any MCP client can call it. Pass the code, the server runs the full multi-model debate, the consensus streams back through the same pipe your client is already using. No context switch. No tab-juggling.

What MCP actually is

MCP stands for Model Context Protocol. It's an open spec for connecting AI clients to external tools. Three primitives — tools, resources, prompts — over JSON-RPC. The dominant transport is local stdio, which means the client spawns the server as a subprocess and talks to it through standard input and output.

The spec is small on purpose. No networking. No bespoke auth. No service discovery. The server declares its tools on startup, the client reads the declaration, and from that point on the client can call any declared tool with structured arguments and get structured results back.

What makes it a standard instead of yet another integration layer is that the primitives match what LLMs already do. Tools map to function calling. Resources map to retrieval context. Prompts map to system-message templates. The protocol formalized patterns that were already being built ad hoc, one vendor at a time.

Why stdio-only matters for security

Stdio is the whole security model. Worth pausing on.

An stdio MCP server has no listener. It doesn't bind a port. It doesn't accept network connections. It has no inbound path the parent process didn't open. The MCP client owns the server's stdin and stdout, and everything the server does happens inside that pipe. From an attack-surface standpoint, the server is a function your client is calling — not a service running on your machine.

That single property is what makes it reasonable to send source code through a review tool. No shared listener anyone else can reach. No auth layer to misconfigure — because there's no one else to authenticate. The trust boundary is the MCP client itself. If you trust the client to hold your API keys and read your filesystem, you've already trusted everything the review tool needs.

The flip side is real. Because the security model depends on the client, the server cannot add guarantees the client doesn't honor. A server can refuse to log sensitive payloads or scrub inputs, but it can't protect against a hostile client. That's the right distribution of responsibility for a local tool, and it matches how developers already think about subprocesses.

The UX shift

Before MCP, code review with a second model looked like this. You finished a change, copied the diff, opened a second chat, pasted, waited, read the response, copied the parts that mattered back, and resumed work. Every step was a context switch you had to make. The review tool didn't know about the project or the file or the question you were actually trying to answer. It only knew the bytes you pasted.

With MCP, the same review looks different. The AI client you're already talking to calls the review tool, passes the diff and any surrounding context it already has, streams the result back into the same turn, and can reason about the result before you even read it.

This isn't a small UX improvement. It changes when review happens. Chat-and-paste is friction, so it gets skipped on small changes — the overhead is higher than the value. A tool call has almost no per-invocation cost, which means it gets used on changes that otherwise would have gone unreviewed. The ceiling on review frequency stops being your tolerance for tab-switching.

Why tool-call review is better review

The less-obvious win from MCP is context threading. A standalone review CLI sees only what you pass it on the command line. Your AI client has already read adjacent files, followed references, and built a working model of the code. When the client calls a review tool, it can forward that context along with the diff — the function two files up, the test that depends on this behavior, the PR description explaining what the change is supposed to do.

More context means better findings. A reviewer that flags a method as "probably not thread-safe" is less useful than one that flags it as "not thread-safe — the caller two frames up holds a lock, but this method releases and re-acquires it inside the loop." The first finding comes from reading the diff. The second comes from the client forwarding the caller's code along with it.

Tool-call review closes the loop differently too. The client asks the question. The tool answers with structured findings. The client decides which findings are worth surfacing, and you see the ones that matter for the question you were actually asking. The review tool isn't trying to guess your intent — it's answering something specific the client asked on your behalf.

How Joint Chiefs exposes the tool

The Joint Chiefs MCP server declares one tool: joint_chiefs_review. The argument schema is small — code to review, optional context, optional strategy overrides (consensus mode, provider weights, round count). The client calls it with structured arguments and the server does the rest.

Under the hood, the tool runs the full hub-and-spoke debate. Spoke providers — OpenAI, Gemini, Grok, plus optional Ollama — review in parallel. Claude moderates up to five rounds with an adaptive early break when positions converge. Findings get anonymized before the final synthesis so the moderator judges arguments, not brands. The consensus streams back through the MCP transport the same way any other tool result would.

One tool instead of many was deliberate. The client shouldn't have to pick among joint_chiefs_security_review, joint_chiefs_style_review, and joint_chiefs_logic_review. Review is one operation with a configurable strategy, and the strategy belongs in the arguments — not the tool name. A smaller tool surface is less for the client to reason about and less for you to configure.

Where this is going

Specialized MCP servers are starting to form a layer of the AI stack that didn't exist a year ago. One server exposes one capability — code review, database introspection, file search, a specific API — and any MCP client can call it. Clients stay general. Capabilities stay narrow. The protocol glues them together.

The analogy to Unix pipes is obvious. Imperfect, but obvious. Pipes connect programs that share a byte stream. MCP connects an AI client to a tool that returns structured results. The underlying bet is the same — small, composable, portable tools over a stable local protocol. It works as long as servers stay focused and clients stay dumb about implementation details. The spec encourages both.

For code review specifically, the practical consequence is that "which AI code review tool do I use" is losing its coupling to "which AI client do I use." Pick the client you like. Pick the review server that fits your work. The layers compose. That's a healthier shape than the alternative — every review tool as a plugin for one specific vendor — and it's the shape MCP is pushing the field toward.