mcp-use v2 Goes Stateless

mcp-use v2 rebuilt from scratch for stateless 2026-07-28 MCP spec is a Show HN release post from Luigi and the mcp-use maintainers about their open-source TypeScript framework for building MCP servers and MCP apps. It deals with a practical problem: MCP integrations need to start fast, stay small, and avoid dragging hidden session state into coding-agent work. The takeaway is simple: stateless MCP makes the integration boundary easier to review before the agent touches your repo. For Claude Code, Anthropic's coding agent, that boundary is also where you implement code review habits for ai-generated code.

What mcp-use rebuilt

Model Context Protocol, or MCP, is a standard way for coding agents and apps to connect to external tools such as issue trackers, docs, databases, and private services.

mcp-use sits on the builder side of that line. It gives TypeScript developers a framework for building MCP servers and MCP apps, so an agent can call a real integration instead of guessing from stale context.

The v2 story is not a cosmetic rewrite. The maintainers say MCP is now stateless in the 2026-07-28 spec revision, so they rebuilt mcp-use v2 around that shape rather than carrying forward the old architecture.

The headline numbers are the kind backend engineers actually notice. The maintainers report median throughput moving from 8,615 to 10,982 ops/sec, cold launch dropping from 151.6 ms to 68.1 ms, and clean install size shrinking from 404.6 MiB to 74.4 MiB.

That matters beyond benchmark bragging. In ai coding training for teams, the boring failure mode is not usually the model being dramatic. It is an integration doing too much, keeping too much state, or making a write action look like a harmless lookup.

Why stateless changes the agent workflow

A stateless MCP server is easier to reason about because each call has to carry the context it needs, or fetch it explicitly. That does not make the integration safe by itself. It makes the boundary more visible.

In a Claude Code repo, that changes the review conversation. Instead of asking whether the agent seemed careful in chat, you can ask what the MCP call was allowed to read, what it was allowed to write, and what evidence came back.

Take a GitHub-style issue triage server. A stateful version might quietly remember a selected repository, a prior search, or a working branch. A stateless version should make the repo, issue id, query, and requested action explicit on each call.

The trap is to treat stateless as a synonym for low-risk. It is not. A stateless call can still delete a branch, leak a private document, or comment on the wrong pull request if the permissions are too broad.

Compare the rebuild before wiring it in

Here is the honest comparison that makes the mcp-use v2 release interesting. The wins are concrete, but they do not remove the migration question.

Verdict: mcp-use v2 wins when you want fast cold starts, smaller installs, and an integration style that fits ephemeral agent work. The older architecture may still be the safer choice for a project that depends on long-lived behavior you have not ported or tested yet.

This is also where mcp-use connects to the larger agentic coding story. Faster servers are nice. Smaller servers are nicer. But the real prize is an integration that a reviewer can understand without replaying the whole agent session in their head.

For a nearby research note on the same release, see mcp-use v2 Rebuilds for Stateless MCP.

Keep the first server read-only

The safest first experiment is not the most impressive one. Wire one MCP server into Claude Code with read-only permissions, then ask the agent to use it while making a small code change.

A good example is a docs lookup server for an internal API. Let the agent search docs, fetch endpoint examples, and cite the pages it used. Do not let it update docs, create tickets, push branches, merge pull requests, or touch deployment systems on the first pass.

For Claude Code, I like a small slash-command workflow for this kind of test:

• Run /mcp-review before the task to list the server, tools, and allowed actions.
• Let the agent make the code change using the read-only integration.
• Require a short review receipt in the pull request: files changed, MCP tools used, external records read, tests run, and uncertainty left.
• Use a PreToolUse hook boundary to block write-shaped tools such as merge, deploy, delete, update, or comment until you intentionally allow them.

That gives you a concrete way to implement code review habits for ai-generated code without making the process theatrical. Review the integration boundary, then review the diff.

Permission-boundary note: read-only is not harmless if the source contains secrets, customer data, or private roadmap material. Treat read as exposure. Treat write as change.

Copy this MCP review card

Use this as a small review artifact when you test a stateless MCP server with Claude Code. It is intentionally boring. Boring is good here.

Review checklist:

• The MCP server has a named owner and a short purpose.
• The first task uses read-only tools only.
• The agent output includes a receipt of MCP calls or external records used.
• The pull request explains which evidence came from the integration.
• A reviewer can reject the change without needing the original chat transcript.
• Any write permission gets a separate review before it is enabled.

If you want the broader practice map around code review guardrails, the related training topic is agentic coding governance.

Try one safe connection

Pick one read-only MCP server, run one small Claude Code task through it, and require the review card in the pull request. If the receipt is clear and the hook boundary held, then you have something worth expanding.

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.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai coding training for teams?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of ai coding training for teams. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “mcp-use v2 Goes Stateless.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• mcp-use v2 rebuilt from scratch for stateless 2026-07-28 MCP spec — source
• Model Context Protocol — specification
• Claude — Agent
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.