mcp-use v2 Gets a Stateless Rebuild

By Rogier Muller08.07.26
mcp-use v2 Gets a Stateless Rebuild

The mcp-use maintainers published a new open-source TypeScript release of mcp-use v2, for building Model Context Protocol servers and MCP apps. How agents connect to tools without dragging session state, heavy installs, and slow launches into every workflow. 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 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.

Watch for 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:

Criteria Stateful MCP server habit Stateless MCP server habit
Launch behavior More likely to depend on warm process state or setup carried across calls Easier to cold-start and fan out across short agent tasks
Failure mode A bad session can leak confusion into later calls Each call is easier to retry, inspect, or reject on its own
Permission review Review must include hidden state and tool permissions Review can focus on the request, the tool, and the declared permission
Repo workflow fit Better for interactive, long-lived workspaces Better for CI-like checks, docs lookup, issue lookup, and read-only context
mcp-use v2 signal Previous architecture was replaced The rebuild reports +27% throughput, 2.2x faster cold launch, and 82% smaller clean install

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

Don't give 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, 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.

Integration Start with Allow writes when Keep read-only when
Docs or knowledge base Search and fetch Almost never from a coding task Docs contain policy, customer, or security material
GitHub issues or PRs Read issues, read PR metadata The task is to draft a comment or label an issue, with human review The agent is changing code and does not need to talk externally
Database Schema inspection and safe selects Local dev databases or generated fixtures only Production or shared staging data is reachable
Figma or design assets Read frames and design tokens Exporting approved assets into a branch The task only needs visual reference
CI or build system Read job status and logs Retrying a safe failed job by explicit request Deploys or release jobs are in scope

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

Further reading

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.