mcp-use v2 Rebuilds for Stateless MCP

mcp-use v2 rebuilt from scratch for stateless 2026-07-28 MCP spec is a release of mcp-use, an open-source TypeScript framework maintained by Luigi and the mcp-use project for building MCP servers and MCP Apps. It deals with a practical integration problem: coding agents need to connect to GitHub, Slack, databases, and private docs without dragging session state through every server. For users of Cursor, Anysphere's AI code editor, and for ai coding training for teams that now includes real tool use, the takeaway is simple: stateless MCP can make integrations faster, but you still need to implement code review habits for ai-generated code before agents write to anything important. MCP is a protocol, introduced by Anthropic, for giving AI applications a standard way to use external tools, resources, and prompts.

See the rewrite as an integration bet

mcp-use is not a model and not an IDE feature. It is a TypeScript framework for building the small servers that sit between an agent and the systems it wants to use.

The v2 story is that the maintainers rebuilt the framework around the 2026-07-28 MCP spec revision, which the project describes as finally stateless. In plain terms, the server should not need to hold a fragile per-client session just to answer the next tool call.

That matters because MCP servers are often thin wrappers over real systems. One server might read GitHub issues, another might query a doc store, another might fetch a Figma design or inspect a staging database. If those servers are easier to launch, easier to scale, and easier to reason about, the agent workflow feels less like a demo and more like normal development plumbing.

The project reports three concrete changes from its benchmark: median throughput rose from 8,615 to 10,982 ops/sec, cold launch time fell from 151.6 ms to 68.1 ms, and clean install size dropped from 404.6 MiB to 74.4 MiB. Treat those as project benchmarks, not universal promises. The useful point is the direction: less framework weight around every integration call.

Verdict: mcp-use v2 wins when your MCP server is meant to be deployed, restarted, scaled, or reviewed like production code. A stateful prototype still wins when you are sketching an idea locally and want the shortest path to a working tool, but that convenience gets expensive once an agent starts touching real repositories.

Watch what changes in Cursor once MCP is wired up

In Cursor, an MCP server changes the shape of the agent loop. Instead of asking the agent to guess from open files and pasted context, you can give it a tool that reads the ticket, checks the relevant docs, inspects the repo, and returns structured context inside the coding session.

A good day-to-day example is a bug fix. The agent opens the failing test, calls a GitHub MCP tool to read the issue, calls a docs MCP tool to fetch the internal API contract, edits code, and then shows you a diff. The useful part is not that the agent knows more. The useful part is that the context comes from named systems with permissions you can inspect.

The trap is letting the integration become a hidden authority. If the agent can read any database, post to any channel, and mutate any issue, review gets muddy fast. Put the boundary where a reviewer can see it: an AGENTS.md note in the repo, a Cursor rule, and a permission table next to the MCP server config.

This is where the related training topic is useful as background, but the mcp-use v2 lesson is narrower. Better plumbing does not remove judgment. It just makes the tool boundary easier to keep small.

Keep the first MCP server read-only

The safest first MCP server is boring. Let it read issues, docs, and repository metadata. Do not let it merge pull requests, rotate secrets, run migrations, or send messages as a human until you have watched the read-only loop work under review.

This is the practical place to implement code review habits for ai-generated code. Review the diff, the tool calls, and the permission boundary together. If the agent used an MCP tool to gather evidence, the reviewer should be able to tell which system it read and whether the edit actually follows from that evidence.

Here is a small integration decision table you can copy into the repo that owns the MCP server.

Permission-boundary note:

# AGENTS.md

MCP boundary for this repo:
- Agents may use MCP tools to read GitHub issues, CI status, and approved engineering docs.
- Agents must not use MCP tools to write to GitHub, Slack, databases, or production systems.
- Any code change created after MCP tool use must include the tool names used in the PR notes.
- Reviewers should reject changes that rely on hidden external context or unreviewed tool output.

If your repo uses Cursor rules, mirror the same rule in a small .mdc file so the instruction is visible inside the editor. The wording can be plain. The important part is that the rule names the allowed systems and the first forbidden action.

Review the diff without replaying the whole chat

A stateless MCP flow should make review lighter, not more theatrical. The reviewer should not need to replay a long agent conversation to understand why code changed.

Ask for three artifacts in the pull request: the final diff, the tests or checks run, and a short tool-use receipt. The receipt can be dull: Read GitHub issue 4821, read docs page payments/refunds, inspected CI failure on main. Dull is good. Dull is reviewable.

This also keeps engineering team ai adoption from turning into folklore. The habit is not trust the agent more. The habit is make the agent leave ordinary engineering evidence.

For deeper observability work around MCP sessions, Armature Instruments MCP Agent Sessions is a useful companion. mcp-use v2 is about the integration framework. Session instrumentation is about seeing what happened after the agent started using it.

Try one safe connection

Pick one read-only MCP integration and make the permission boundary visible in the repo before you ask Cursor to use it. If the agent cannot explain which tool evidence led to the diff, tighten the boundary before adding write access.

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 Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] 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 Cursor, 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 Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. 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: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “mcp-use v2 Rebuilds for Stateless MCP.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; 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
• Cursor — 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.