mcp-use v2 Gets a Stateless Rebuild

mcp-use v2 rebuilt from scratch for stateless 2026-07-28 MCP spec is an open-source TypeScript release from the mcp-use maintainers for building Model Context Protocol servers and MCP apps. It deals with a boring but important integration problem: how agents connect to tools without dragging session state, heavy installs, and slow launches into every workflow. The takeaway is simple: stateless MCP makes integrations easier to run, but it also makes permission boundaries and review habits more important, especially when you implement code review habits for ai-generated code around those tools. MCP is a protocol for letting AI agents call external tools and read external context through a standard interface.

This sits right in the daily path of Codex users. Codex, OpenAI’s coding agent, gets more useful when it can work near real repo context, issue trackers, docs, and verification commands without turning every integration into a custom one-off. That is why this release is worth reading as an engineering story first, not as another round of engineering team ai adoption advice.

Read the rebuild as an integration story

The mcp-use maintainers say they rewrote v2 from scratch for the 2026-07-28 MCP spec revision, with statelessness as the major design shift. Their reported benchmark numbers are concrete: median throughput rose from 8,615 to 10,982 ops/sec, cold launch dropped from 151.6 ms to 68.1 ms, and clean install size fell from 404.6 MiB to 74.4 MiB.

Those numbers matter because MCP servers often sit on the hot path between a coding agent and the systems it needs. A GitHub MCP server, a docs search server, or a database inspection server may be called repeatedly during one task. If each call pays for a heavy process model or sticky state, the agent feels slow and brittle.

The trap is to treat “stateless” as a pure performance feature. It is also an operating model. Stateless integrations are easier to start, stop, scale, inspect, and deny.

A good Codex example is a repo where AGENTS.md tells the agent how to verify work:

# AGENTS.md

Before opening a PR:
- Run `npm test -- --runInBand` for backend changes.
- Run `npm run lint` for TypeScript changes.
- Use MCP docs search as read-only context.
- Do not call write-capable MCP tools unless the task explicitly asks for it.

That last line is where the release becomes practical. Fast integrations are still integrations. They need a boundary.

Compare stateful MCP habits with stateless MCP habits

A stateful server can be useful when a workflow needs a long-running session, local cache, or remembered conversation state. A stateless server is usually cleaner when the agent should make isolated requests against a known tool surface.

Here is the comparison that matters for code work:

Verdict: stateless wins when an MCP server should behave like a small, auditable adapter between Codex and a system such as docs, GitHub, or a ticket tracker. Stateful still wins when the tool really needs continuity, but that continuity should be explicit enough that a reviewer can see what is being remembered.

If you want a deeper sibling read, see mcp-use v2 Goes Stateless. Keep this article in the narrower lane: what the rebuild says about integration shape and review boundaries.

Wire MCP into the workflow, not around it

The day-to-day change is subtle. A coding agent can stop asking you to paste context from five places and start pulling the right context through MCP.

For example, a Codex task might inspect the repository, search internal docs through an MCP server, and then run the normal CLI verification loop. The agent is not magically trusted because it used a protocol. It is useful because the context path is repeatable.

A small command workflow might look like this:

# Human starts with a narrow task
codex "Update the billing retry copy. Use docs search only for context. Do not modify migrations."

# Agent proposes a patch
npm run lint
npm test -- billing-retry

git diff -- src/billing

The trap is giving the MCP layer more authority than the task needs. A docs MCP server can be read-only. A GitHub MCP server might be allowed to read issues but not merge pull requests. A database MCP server should almost always start with schema and query-read access, not mutation.

For more on this kind of boundary-setting across agentic coding work, the related training topic is agentic coding governance.

Put the review at the permission boundary

The best ways to implement code review habits for ai-generated code are usually small and boring: review the diff, review the commands, and review the tool calls that produced the diff. MCP makes the third part visible enough to write down.

Use this as the review checklist for an MCP-backed Codex change:

• Diff scope: Does the patch touch only files named in the task or files clearly required by the change?
• Tool scope: Which MCP servers were used, and were they read-only or write-capable?
• Permission match: Did the task require write access, or did the agent receive it because it was convenient?
• Verification: Which local commands passed, and are their outputs included in the handoff?
• Data exposure: Did the agent read secrets, customer data, production logs, or private documents that were not needed?
• Human decision: Is any merge, deploy, comment, or ticket update still waiting for a person?

A useful permission-boundary note can live in AGENTS.md:

## MCP boundaries

Default MCP access is read-only.
Write-capable tools require an explicit task sentence naming the target system and action.
Never use MCP to merge PRs, change production data, or post external comments without human confirmation.
Include a short tool-call summary in the final handoff.

That note is not a giant ai coding training for teams program. It is one repo rule that gives reviewers something concrete to enforce.

Decide which MCP servers deserve write access

Not every integration should be powerful. The cleanest MCP setup starts with read paths, then adds writes only where the workflow genuinely improves.

The rule of thumb is plain: read access helps the agent understand; write access changes the world. Make the second one earn its place.

Common questions

• What changed in mcp-use v2?

  mcp-use v2 was rebuilt from scratch around a stateless MCP design. The maintainers report +27% median throughput, 2.2x faster cold launch, and an 82% smaller clean install, with benchmark methodology published in the project repository.

• Why does stateless MCP matter for Codex work?

  Stateless MCP makes each tool call easier to isolate, retry, and review. For Codex workflows, that means docs lookup, issue lookup, and verification helpers can behave more like small adapters than long-running sidecars with hidden memory.

• What are the best ways to implement code review habits for ai-generated code?

  The best ways are to review the diff, the verification commands, and the MCP tool permissions together. A reviewer should see which servers were called, whether they were read-only, and whether any write-capable action matched the original task.

• Should every MCP server be stateless?

  No. Stateless is a strong default for repeatable integration calls, but some workflows need session continuity or local cache. The important caveat is visibility: if the server remembers state, the reviewer needs to know what kind of state and how it affects later actions.

• Can MCP replace normal code review?

  No. MCP improves how agents reach context and tools; it does not prove the patch is correct. You still need tests, diff review, ownership checks, and a human decision before merge, especially when a write-capable integration was available.

Best ways to use this research

• Best for: engineers wiring Codex or another coding agent into real repo context through MCP, especially when the first question is what should stay read-only.
• Best first artifact: add an AGENTS.md MCP boundary note that names allowed read tools, blocked write tools, and required handoff details.
• Best comparison angle: compare stateful and stateless MCP servers by launch cost, failure isolation, and review visibility rather than by protocol enthusiasm.
• Best review habit: ask for a final handoff that includes changed files, verification commands, and MCP tool calls used to produce the patch.

Further reading

• mcp-use v2 rebuilt from scratch for stateless 2026-07-28 MCP spec — source
• Model Context Protocol — specification
• Codex — Agent
• OpenAI Codex
• mcp-use on GitHub
• mcp-use benchmark methodology

Start with one safe server

Pick one MCP server that only reads context, wire it into a small Codex task, and require the agent to summarize its tool calls in the handoff. If that review feels boring, you probably drew the boundary well.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.