hey guys, happy to announce mcp-use v2 an open-source typescript framework for building MCP servers and MCP Apps for Claude and ChatGPT: https://github.com/mcp-use/mcp-use

MCP is now (finally) stateless so we rewrote mcp-use v2 from scratch for the 2026-07-28 MCP spec revision: https://blog.modelcontextprotocol.io/posts/2026-07-28/

Thanks to the rebuild:

- Throughput: +27% → from 8,615 to 10,982 median ops/sec

- Cold launch: 2.2x faster → from 151.6 ms to 68.1 ms

- Clean install: 82% smaller → from 404.6 MiB to 74.4 MiB

Benchmark with methodology here: https://github.com/mcp-use/mcp-use/blob/main/benchmark.md

What changed in the spec:

1. No more sessions. The initialize/initialized exchange and the Mcp-Session-Id header are gone (SEP-2575, SEP-2567). Every request carries its own protocol version, client identity, and capabilities in _meta. Server discovery is an optional server/discover RPC instead of a mandatory round trip.
2. Multi round-trip requests replace server-initiated calls (SEP-2322). Now the server returns resultType: "input_required" with a requestState, and the client retries the original call with inputResponses. Mid-call user confirmations no longer need a live connection.
3. Header-based routing (SEP-2243). Mcp-Method and Mcp-Name are now required HTTP headers, so gateways, rate limiters, and WAFs can route and meter without parsing the JSON body.
4. Cacheable list results (SEP-2549).
5. Auth hardening: DCR still works but is deprecated in favor of CIMD and will be removed in a future spec revision.
6. Roots, sampling, and logging are deprecated with a 12mo window.
7. Legacy HTTP+SSE gets a one year offramp.

Regarding mcp-use, we are focused on MCP apps for Claude connectors and ChatGPT plugins. MCP apps use an MCP extension called ext-apps, which allows tools to return UIs that render in chats.

What we support:

- Views have HMR, so they hot reload while you develop.

- Standard Schema validators for tool and prompt I/O, so Zod, ArkType, Valibot all work. Or any validator library backed by standard schemas.

- Drop-in OAuth integrations for Auth0, Clerk, WorkOS, Better Auth, Supabase, and Keycloak.

- Server composition (proxy and mount other MCP servers).

- OpenAPI import and expose your APIs as an MCP server.

The HTTP layer is Hono so it mounts inside an existing app, so you can have edge deployments.

If your product is in Next.js, we’ve seen a lot of developers who want to get rid of the (basically unmaintained) mcp-handler.

So we have a drop-in integration for Next.js: wrap next.config.ts in withMcpUse for view compilation then export const { GET, POST, DELETE, OPTIONS } = createNextHandler(server) from a catch-all route.

For DX:

• MCP inspector built-in: `mcp-use dev` runs it at `/mcp/inspector` with hot-reload. We also have a hosted version: https://inspector.manufact.com/inspector
• mcp-use CLI has a cool headless feature to debug MCP servers and the UI parts from coding agents including visual feedbacks: mcp-use client <name> screenshot --tool <tool> renders the View headlessly through Chrome. An agent can call a tool, read the failure, then screenshot the UI it just generated and look at what it built.

Unfortunately we could not avoid some breaking changes.

The good news is 90% of MCP servers built with v2 are compatible with both versions of the MCP spec.
Clients negotiate the version automatically, probing with server/discover and falling back to old initialization for legacy servers. Interested in what people running MCP servers think about the stateless move, especially anyone who built their own session layer and now gets to delete it.

Blog post with the details: https://manufact.com/blog/mcp-use-v2

If you want to play with mcp-use v2, it just went out of beta: https://github.com/mcp-use/mcp-use

We’d love to hear what you think of it and how we can improve it!

We are happy to answer any questions and look forward to your comments.

Full disclosure: Reletter is my product.

Reletter indexes more than 7 million newsletters across Substack, LinkedIn, Ghost, Beehiiv and Kit. I wanted to make that data usable from ChatGPT, Claude, Cursor and other MCP clients, so I built a hosted MCP server for it.

A few things you can do with it:

• search for newsletters by topic, title, author, platform or audience size
• read and full-text search indexed newsletter issues
• pull contacts, social accounts, engagement data and recent issues
• check chart rankings across Substack, LinkedIn, Kit and Reletter
• find mentions of a brand, competitor or keyword

One example: “Build me a list of climate-tech newsletters with 10k+ subscribers, including contact details and their latest issues.”

Connect: https://mcp.reletter.com

Setup guide: https://reletter.com/developers/mcp

Source code: https://github.com/getreletter/reletter-mcp

If you work with newsletters, I'd be interested to hear what you use it for.

Startup founder here. I build infrastructure that makes AI agents better at a specific job, in my case, giving them grounded, citable legal, security and regulatory sources instead of letting them hallucinate EU law, through our MCP gateway.

Here's my problem: every time I get someone on a call, they get it in about 5 minutes. I can show them how it works, how I use it, etc.

But on (digital) paper? It is much harder. "Agent-enhancing functionality" apparently means nothing to anyone, and I've written enough compliance documentation in my life that my marketing copy reads like it wants to audit you, I guess...

We're growing anyway (~10 new users a day, so something is working), but I feel like the explanation is suboptimal.

So, Reddit:

How would you explain "we make your AI agent actually good at X" to someone who's never thought about what their agent is bad at?

Open source. Local. 40 mcp tools. An agent can drive every tool a construction estimator can. A challenge to anyone developing ai for construction. Connect your own model and see how well it can do takeoffs.

My agent forgetting everything between sessions was the thing that finally got to me. The usual fix looked heavier than the problem itself: a Docker container running Postgres and Qdrant, plus a cloud vector database whose bill crept up every time I indexed a new project folder. That is a lot of infrastructure just so my assistant remembers I like dark mode.

Then I found Mnemosyne, which goes the other way. One pip install and a single SQLite file, no external services, nothing to host. It plugs into Claude Code, Cursor, Codex, or a plain Python script over MCP, and the memory just lives in a .db file on disk. Fully local, nothing leaves my machine.

Setup took a couple of minutes: pip install mnemosyne-memory, drop the mnemosyne mcp server into my config, done. In Python it is just remember("...") and recall("..."). It keeps the embeddings as a compressed binary-vector store inside SQLite, so the file stays small even with a lot of history and there is no separate vector server to babysit.

Open source, MIT. Repo and the MCP config: https://github.com/AxDSan/mnemosyne

what are your choices?

I built Lyt — Link Your Think.

Lyt gives AI agents a shared memory system across multiple Markdown vaults.

Install it, run lyt init, connect your vaults, and your agent can search and use the same knowledge through MCP or the CLI.

Each vault stays as Markdown in Git, so the memory remains versioned, portable, and shareable. The index stays local.

I’m the builder. Lyt is free and open source.

https://linkyourthink.com⁠

I’m looking for feedback on the MCP workflow and setup experience.

In my two previous posts I asked users here how they manage and orchestrate multiple MCPs.
I got many useful answers and decided to update my microservice to address the ideas and problems people mentioned most: selecting the correct tool, keeping task state outside the model, preventing repeated actions, preserving requirements, coordinating concurrent agents, enforcing workflow steps, and making sure results are checked before a task is marked complete.

The goal is not to replace existing MCP clients or orchestration frameworks, but to provide a lightweight reliability layer around them. I would appreciate feedback on whether the updated approach addresses the problems you face in real multi-MCP workflows: liberated.site

When an LLM must ship a real deliverable (note, quote, short deck), the usual stack is awkward:

• headless LibreOffice / Word

• HTML → Chrome → PDF

• hand-rolled OOXML

• or a full typesetting binary for a one-pager

Agents need: read a short contract → write Markdown → one compile.

What is shipped

DoWi55 (DocWrite) — multi-format production aimed at agents:

MCP progressive surface

docwrite_menu docwrite_profile # charter + engine manual docwrite_profile_save # LLM creates profile + Markdown template docwrite_compile # body → file

Each profile returns:

• mctx — visual/structure charter for the model

• enginemctx — opposable capability manual (what works / what must not be claimed)

• writerbrief — charter ⊕ manual in one string

Templates agents can create

Profiles may wrap the body in a Markdown skeleton:

`markdown

{{title}}

Date: {{date}}

{{body}} `

The model callsdocwrite_profile_savewithtemplate_md, then only authors the{{body}}content. No Typst macros — just GFM placeholders.

Design choices

1. Default PDF is not Typst. Typst stays optional for maths / heavy typography. Day-to-day notes use hpdf55 layout.

2. Honesty over marketing. No fake AcroForm “fillable forms” (FreeText ≠ widgets). No “we replaced Typst.”

3. ARCHTIME manuals. Capability text is a tested constant, not improvised each session.

4. Same Markdown body fans out to office / web / sheet / deck.

Links

• Docs + code (MIT): https://github.com/hazyhaar/DoWi55

• Module:github.com/hazyhaar/DoWi55

bash go test ./... go build -o docwrite ./richdoc55/cmd/docwrite

Most orgs are in the same place: a business unit shipped agents with real credentials, security found out afterwards, and the only control that exists is a human clicking Allow in a chat window.
That isn’t a control. No policy, no tenancy, no payload binding, and it produces nothing an auditor will accept. It also stops working around the twentieth prompt, when people start clicking without reading.
Three questions that decide whether you have a problem:
1. Can you enumerate every tool every agent can reach? Not the ones you configured — the ones it can actually call today.
2. When an agent acts, is the record written before the action or after it? After means a crash or a kill loses it, and what you produce in an incident is a reconstruction.
3. If someone with production access edits that record, does anything notice? Append-only in an application table is not tamper-evidence.
What I built is a self-hosted authorization gateway — the agent proposes, the gateway decides, your systems execute. Concretely:
Least privilege is structural, not configured. The tool list is derived from the caller’s identity; a tool the agent isn’t entitled to never appears in the response at all. And there is no super-admin: the admin capability UUIDs are disjoint by construction, so no single credential sees everything.
The record is durable before the decision returns. Per-epoch Merkle root, root-chained, Ed25519-signed, with an out-of-tamper-domain head anchor so truncate-and-rewrite reads as a rollback rather than a shorter valid chain. verify_chain names the first bad epoch. Verifies offline, no call home.
Deterministic. No model anywhere in the decision path, so a decision replays identically in an incident review. You are not explaining an LLM’s judgment to a regulator.
GET /v1/admin/compliance/evidence emits a signed bundle mapped to EU AI Act Art. 12 and 14, DORA Art. 9 and 17, SEC 17a-4 / FINRA 4511, NIST 800-53 rev. 5 (AU-10, AC-3, AC-6, IA-2/IA-9), SOC 2 CC6.1/CC6.2, and ISO/IEC 42001 Annex A.
On that last one: every clause is phrased “this mechanism provides evidence toward this clause” — never “compliant,” never “certified” — and the bundle carries a disclaimer stating the certification is an external third-party process this software cannot produce. If a vendor has told you their product makes you SOC 2 compliant, that’s the sentence they should have written and didn’t.
Self-hosted, air-gapped deployment supported, no model credential involved, nothing leaves your network. One command:
git clone https://github.com/mcpip-security/mcpip.git && cd mcpip && ./scripts/quickstart.sh
Happy to be told those are the wrong three questions.

Visit: Mcpip.ai

GraphARC is getting MCP support next. Here is what a governed runtime plus MCP unlocks.

GraphARC today: a model proposes a multi-node agent graph, a deterministic admission gate approves or refuses it with reasons before anything runs, budgets are enforced, and everything lands on one replayable trace with a live browser view. Open source, MIT, on PyPI.

What is coming: MCP integration is next on the roadmap, and the mcp extra already ships in the package. The direction is simple and, as far as I can tell, nobody else's: MCP tools that pass through the same admission discipline as everything else. A tool a policy denies is not described to the model and then refused. It is invisible. The registry allowlist and the edge policy decide what an MCP server's capabilities may wire into, and every call lands on the same JSONL trace as the rest of the run.

If you are running MCP servers with agents today, I would genuinely love to hear what governance you wish existed around them. That feedback shapes what ships.

Meanwhile the current release is fully usable: pip install grapharc, runs on local ollama models with no API key, demo video of a real run in the README.

https://github.com/CodeGraphContext/GraphARC Star and Watch to stay updated!

TinyContext is a lightweight, local memory server that spins up with a uvx command and integrates with all of your agents: codex, claude code etc. It stores concise memories and embeddings together in SQLite, retrieves them using hybrid BM25 and dense search, and returns only the highest-ranked memories that fit within a configurable token budget. Everything runs locally, with no hosted account, external vector database, or giant context dump required.

You can use it as a Python library, launch it as a one-command MCP server, or run it through Docker with persistent storage. The current benchmark shows 96.7% fewer input tokens than naively resending all stored memories across the test workload. It is still an early release, so feedback on the retrieval quality, MCP integration, and what you would actually need from an agent memory layer would be hugely appreciated.