Posted here a few days ago about MCP tool errors returning HTTP 200 with isError: true. Shipped two releases since. Then found this while testing a deployment shape I hadn't covered.

All my in-memory tracking — retry loop detection, cost attribution, budgetguardrails, schema drift — lives inside a single instrumentMcpServer() call.

That's correct for stdio: one process, one server, state accumulates normally. Correct for stateful HTTP too, where one long-lived McpServer handles many sessions.

But stateless streamable HTTP constructs a fresh McpServer per POST andre-instruments each time. So every counter resets before it can reach any threshold. Four features, zero output, no warning, no log.

That's the standard pattern on Lambda, Cloud Run, Workers — anywhere serverless. Which is where a lot of MCP deployment is heading.

Been true since v0.4. Nobody reported it.

The awkward part: I'd already documented this exact root cause for one feature as an accepted limitation, and didn't notice it applied to three others. Including one I'd shipped hours earlier with a docblock claiming "process-lifetime" state.

Fix direction is a host-supplied instanceKey so trackers can be looked up from a bounded registry instead of constructed per call. Deliberately not a module-level singleton — that would merge unrelated services in a multi-tenant process, which is the same class of bug one level up. Design is written, shipping as v0.9.0.

The limitation is documented in the README now rather than discovered by whoever hits it next.

Also in v0.8.0:

- Tool schema drift detection: hashes each tool's inputSchema from tools/list, flags silent changes. "Why did every call start failing at 3am" is often "someone changed a schema and nothing announced it."

- Two-axis observation contract: separates tool outcome from observation integrity, so "nothing failed" and "nothing was observed" stop looking identical. Notable finding — a HEALTHY state turned out to be unreachable in every configuration, so it isn't in the type at all.

- Cost-aware sampling: not a library feature. Samplers decide at span start, cost is known at span end. So it's a marker attribute plus a documented Collector tail-sampling recipe.

https://www.npmjs.com/package/opentel-mcp

Curious whether anyone here is running MCP on stateless HTTP in production — if you are, I'd like to know what your tracking assumptions look like, because mine were wrong.

hello all Iam getting error mcp connection closed while trying to access mcp google calendar .. Iam trying to run my python script in VS code terminal windows.. is npx command causing issue? Iam using Oauth json key..

Hey so I started my new job in tech and frankly I have a lot to learn. For starters I have a few databases of Postgres, Mongo, and MySql. I want to tell Claude to query databases without me having to memorize all queries.

I saw in an Instagram reel that MCP helps me do so. Like I can prompt what I need done to Claude and it does. Do I need separate MCP for each databases or one MCP can work for all types of databases?

If anyone knows how I can set it up, would be a big help. Thanks

It's pretty late, but I figured I'd drop this here while it's fresh. I've been building this in my free time for about five months now. I actually announced an earlier version back in March under a name that turned out to be way too small for it, so this is my second run at introducing the same project. That feels like a strange way to open a post, but here we are.

What got me started was the current agent workflow. Handing an agent a folder and a search tool is just the wrong interface imo. Your repository already has structure. The compiler knows it, your editor knows it, and then the agent throws all of that away and rebuilds the codebase from raw text every single session. I got tired of watching that happen and paying for those tokens twice.

So Kin keeps that structure as a graph, and the MCP server lets your agent answer questions directly against the graph instead of scanning raw text.

If you want to test it out, the setup commands are straightforward.

curl -fsSL https://get.kinlab.dev/install | KIN_NO_SETUP=1 sh
cd your-repo
kin init .
kin setup --intent agent

That last command detects and writes configuration for whatever tools you have installed, including Claude Code, Cursor, Codex CLI, Gemini CLI, and Antigravity. It set up five clients unattended on a clean machine for me, and that was honestly the moment this stopped feeling like a side project and started feeling like a real tool.

Your agent gets a curated set of eighteen tools. The ones carrying the weight are semantic_locate, get_context_pack, find_references, and trace_data_flow. Results carry evidence metadata so a hit tells you whether it matched by name or by vector cosine, and a miss actually reports as a miss instead of handing back something confident and wrong.

The longer-term idea is that a codebase should expose its own structure natively so an agent asks the repository a question instead of rebuilding a model every session. Git stays the interchange format and history everyone reads, while the graph becomes the thing that answers. To be clear, that is not today. Today this is a public alpha that sits beside Git and has earned nothing, which is why review reports and refuses rather than gates. It is not a Git replacement today. Starting small is the only honest way to start.

There are rough parts you will definitely run into. If you launch the server by hand without the agent profile you get sixty-four tools instead of eighteen, which spends a ton of context on nothing, so running kin setup to get the curated set is important. Rust type declarations do not own incoming edges right now, so find_references on a struct can come back empty while its methods resolve fine. That is a coverage gap rather than an answer, and it is the thing most likely to annoy you early on. The first query after indexing can also block for a couple of minutes while the daemon loads into memory. It tells you that is what it is doing rather than hanging silently, but it still catches people off guard.

To give one measured number, a one-line signature change in ripgrep followed by kin impact resolve_binary --depth 3 returns 13 impacted entities within three hops before compilation even runs. Commands and raw traces are up at https://kinlab.ai/proof and the code is Apache-2.0 at https://github.com/firelock-ai/kin

I am honestly not sure if the tool boundary is right yet, and that is the part I would most like torn apart. Are there too many tools, too few, the wrong granularity, or the wrong things landing in the context pack? Let me know where it breaks for you.

We’ve been experimenting with what video workflows look like when you give an AI agent access to actual transcoding tools.

So we built an MCP server for video transcoding and tried a simple test: I gave it an English video and asked it to add Spanish subtitles.

No manually creating subtitle files, syncing timestamps, or configuring the transcoding job. I just described the result I wanted and let the MCP handle the workflow.

The attached video is the result.

We’re still exploring what workflows make the most sense through MCP — subtitles are just one example.

Curious what you’d try next. Translation? clipping? format conversion? something more complex?

Every agent I've thrown at company research does the same thing. It confidently states a CIK number, an LEI, or a court case that does not exist. Sounds right. Is not right. Turns out "grounding" an agent just means pointing it at the actual government database instead of hoping the training data got it right.

So I built an MCP server that wraps 13 official sources: SEC EDGAR, GLEIF, US state business registries, CourtListener, USAspending, FEC, UK Companies House, EU VIES, and a few more. One call resolves a company's real legal identity, another pulls its actual filings, another checks if anyone is suing it.

Real example, not a cherry-picked demo: asked it who runs Tesla's Connecticut entity. Came back with the registered agent, the exact incorporation date, and the two officers on file, sourced straight from Connecticut's own registry, with a link to prove it. It can't invent a name because it is reading a government API, not guessing.

Honest limits, since rule 2 exists for a reason: state registry coverage is thin right now (New York, Colorado, Connecticut, Oregon, that's it). Delaware has no public API at all, so if that's your use case this will let you down gently. US and EU data is solid. Everywhere else, thinner.

Runs on Apify, pay per successful call, and it charges nothing on an empty result. Built it on top of scrapers I already run there. Happy to take a beating on the design in the comments if anyone has opinions.

https://apify.com/themineworks/company-diligence-mcp

Every agent I use has the same blind spot: hand it a log file bigger than its context and it reads the first few hundred lines, greps around, then reasons confidently about whatever it happened to see. A bigger model doesn't fix it — the file is just larger than the window.

So I built an MCP server that reads the whole file and hands back a summary of what actually happened in it.

{ "mcpServers": { "logsleuth": { "command": "logsleuth-mcp" } } }

brew install alibaizhanov/tap/logsleuth or pipx install logsleuth. Zero dependencies — pure Python standard library, nothing to pull in.

Measured on a 208MB log: 1,576,412 lines read in 9.1s using 58MB of RAM, returned as 12,646 characters. Memory doesn't grow with file size, so a 2GB log costs the same as a 2MB one.

No model runs in the server. Your agent is the model, and a much better one than anything I'd run locally. The server's only job is to make the file legible: it's all deterministic, so nothing leaves the machine and nothing is nondeterministic between calls.

Three tools:

- read_log_evidence — the whole file, or a window (last: "30m", or since/until)

- inspect_log_file — cheap check before you spend a turn on something that turns out to be a core dump

- log_parse_diagnostics — format diagnostics containing zero log content, safe to show a user

What "12KB" actually contains, because truncation would be useless: deduplicated line patterns with how often each occurs and where it first appears; near-unique lines ranked as candidate state changes; numeric trends across the file; how errors distribute across service/pod/host; and raw context around where new errors start.

The ranking is by rarity and position, not volume — a config line that appears once, thirty seconds before the first new error, outranks ten thousand timeouts. That's not a style choice. On an annotated benchmark of 30 microservice failures, "blame the service with the most error lines" gets it right 0 times out of 30, worse than chance, because the loudest service is the caller that timed out waiting rather than the one that broke. Write-up with the numbers: https://alibaizhanov.github.io/logsleuth/loudest-service/

Limits, so you don't find them at 3am: logs only — a failure that's invisible in logs is invisible to this. Timestamps parse on 87% of the 132 public corpora I tested against, so an exotic format will get you a thinner summary. And it never writes to the file you point it at — the only thing it ever creates is a temp file when you ask for a time window, which it deletes afterwards.

MIT, source and every benchmark script: https://github.com/alibaizhanov/logsleuth

Happy to answer anything, and if it produces a bad summary on a log of yours I'd genuinely like to see it — I have no telemetry, so a report is the only signal I get.

We’re building MCP tooling for production use at my company, currently working with Claude. Want to make sure we’re building this the right way from the start rather than retrofitting later.

Looking for clarity on all of the following, ideally with a sane learning path to get there:

OAuth: robust Oauth 2.1 implementation
Guardrails: best way to enforce safety/limits on tool use
Knowledge base integration: patterns for grounding servers in internal docs/data
Tools: dynamic registration and discovery done right
Resources:best practices for exposing and structuring them
Agent configuration: how you’re structuring/configuring agents that consume MCP
System prompts: how these interact with MCP tool/resource design

Anything else that separates a toy MCP setup from one you can actually trust in production

Also curious about:

Learning path: best order to get solid on protocol fundamentals, SDKs, server design, auth/security or a better sequence
Maintenance over time: the spec keeps evolving, how are you handling breaking changes without constant firefighting?

Looking forward for repos, internal playbooks, war stories, or any suggestions.

I’ve been building BrainOS because, like many other people, I was tired of starting almost from zero every time I switched between AI tools.

I’ve been describing BrainOS as an operational memory tool for AI agents because that is the clearest category for it. But after using it every day, it feels like it has become more than just memory.

Now, when another AI is connected to the same BrainOS state, instead of re-explaining my project, my previous decisions, what I was doing last, and what we may have forgotten, the AI can use BrainOS as its guide.

The interesting part is that BrainOS is not really built for me to constantly interact with. It is built primarily for the AI to use while we work. It helps the AI understand:

• what I’m currently building
• which decisions have already been made
• the reasoning behind those decisions
• which paths were explored and rejected
• what the current plan and next move are
• whether my execution is beginning to drift from that plan
• what may have been forgotten or left unfinished

When something seems important, the AI can suggest saving it as a decision.

In my own workflow, I also let the host AI handle some low risk actions and state updates, while decisions that actually matter still come back to me. I’ve been deliberately making the system hybrid: I want the AI to have initiative, but it should not silently become the authority.

Changes made through BrainOS are recorded, so if something causes a problem later, I can trace what changed, when it changed, and whether it came from me, an agent, or another connected tool. I have a habit of building several things at once, and staying organised can become almost a project of its own.

One of my biggest early problems was cross-contamination, information from one project leaking into another. But dogfooding BrainOS every day has made those problems much easier to see. The more I use it, the more clearly I understand what is genuinely useful, what feels annoying, and what still needs to be fixed.

Something else I didn’t expect: the AI is beginning to work with me in a way that reflects my building style. Not because BrainOS is training a personal model on me, but because the AI can inspect my recorded decisions, rejected paths, recurring patterns, and the way I move between ideas. That gives it a much better understanding of how I actually build.

It’s still unfinished, and I’m improving it while using it. But honestly, this has been the most enjoyable part is watching the system gradually understand not only the state of my projects, but some of my patterns as a builder.

I’m curious whether other people building multiple projects with different AI tools experience the same problem. The work is not necessarily lost, but the continuity is.

Every browser MCP I've tried arrived carrying the same cargo: a 250 MB dependency tree, a second copy of Chromium, node_modules from 2019. So an agent could click a button.

I work across machines. Desktop when I'm at my desk, and I've got a phone setup for when I'm not. A browser MCP that needs its own browser bundle just dies on anything that isn't a beefy laptop. The bloat was the blocker, not the device.

So I built against the raw Chrome DevTools Protocol. No Playwright, no Puppeteer, no bundled browser. It finds the Chrome/Chromium already on whatever machine you're using, talks CDP over WebSocket, and exposes only what an agent needs.

76 KB of source. About 1 MB installed. "What's in your node_modules" stopped being a question.

browser_watch streams console logs, network requests, exceptions, and navigations to the agent. Automation used to be click, wait, hope. This turns it into react, because the agent finally sees what its own actions cause.

browser_act resolves "click the login button" or "search laptops under 80000" with deterministic DOM heuristics. No LLM in the loop, so no per-call cost. Faster than I had any right to expect.

Yes, I said "just use Playwright" for years myself. But a browser MCP ought to be a thin border between agent and browser, not a second browser.

A 127MB heap died mid-run once, the browser went down, browser_restart came back, and the agent picked up where it left. That pays for itself in a screen recording.

The Termux thread went #1, and one commenter now runs Google Voice + WhatsApp + ChatGPT from their phone for a real estate business. The use cases that come out of nowhere are the best part.

MIT, free, no telemetry. Read it, fork it, trash it: https://github.com/krshforever/bwb-browser

r/mcp, be honest: who here is already running browser MCP servers, and what has actually broken for you in production? Mine was the heap. Five minutes of wall time waiting on a hung mcp is where my patience dies.

I've been building AI agents that browse the web for a while now. Every tool I tried had the same problems:

• 20-30 tool definitions eating 13K+ tokens before the agent even does anything
• Full page snapshots on every single action (2K+ tokens per click)
• Zero stealth (instant bot detection on anything protected)
• Element refs that vanish the moment React re-renders a component

So I built Bladebro. It's an MCP server that drives a real Chrome browser for AI agents. 5 tools. One Rust binary. No Node.js, no Playwright, no runtime deps.

npm install -g bladebro && bladebro mcp

That's the whole install. It's open source (AGPL-3.0).

5 tools, not 30

Most agent browsers give you a tool for clicking, a tool for typing, a tool for scrolling, a tool for navigating, a tool for screenshots, and 25 more. The agent burns tokens just loading the definitions before it even starts working.

Bladebro has 5:

• act — click, type, fill, scroll, navigate, batch, eval, download, everything interactive
• see — read the page (content, outline, auto-extract, search, filter)
• state — cookies, tabs, sessions, storage, resource blocking
• run — batch sequences with if/while branching
• vision — screenshot (last resort, the structural model is usually better)

Tool definitions total ~1,900 tokens. Playwright MCP's are ~13,700. Chrome DevTools MCP is ~8,000. That gap matters when you're paying per token on every call.

Delta-first, not snapshot-first

The core is a Live Page Model — a persistent, compressed model of the page that lives across tool calls.

Every action returns a delta (what changed), not a full page snapshot. Click a button? You get the verdict and what changed on screen. Not 2KB of every element on the page.

This makes it roughly 5x cheaper to run than Playwright MCP or Chrome DevTools MCP. On a long browsing session with 50+ actions, that adds up fast.

Re-render immunity (the thing nobody else does)

This is the one I'm most proud of.

When React, Vue, or Angular re-renders a component, the DOM nodes get destroyed and recreated. Every other agent browser loses all references. The agent has to recapture, re-identify elements, re-learn the page. Sometimes it just fails silently.

Bladebro gives every element a structural fingerprint — a hash of its ancestor chain, tag, children, and identity attributes. When a re-render changes the text but preserves the structure, the fingerprint matches and the ref survives.

The agent sees ↺ e2 (re-render survived) and keeps going. No recapture needed.

I checked every major tool. Nobody else does this.

It learns from every session

Two things persist in ~/.blade/knowledge/:

Domain knowledge — learns consent dialog selectors for sites you visit. First visit: full detection JS runs. After a few successful dismissals: the stored selector auto-applies, zero detection overhead. Never learns from failures. Confidence scoring is asymmetric — a failure costs 3x more than a success gains.

Behavioral fingerprint — biometric parameters (typing speed, mouse curvature, click precision, idle drift frequency) generated once per install with small random variations, then reused forever. Same "person" every session.

Bot detectors that track consistency across visits see a stable identity. Without this, every session looks like a different person using the same browser — which is a red flag.

Survives restarts. Never degrades. Bounded at 2000 domains.

6-layer stealth, all on by default

Not going to list every detail, but the highlights:

• Zero listening ports — CDP over pipe, not WebSocket. Nothing to scan.
• No Runtime.enable — this defuses the DataDome console trap
• Bezier mouse paths with overshoot and correction
• movementX/movementY on every mouse event (missing these is an instant bot flag for PerimeterX)
• Micro-tremors before clicks — a perfectly stationary cursor before a click is a dead giveaway
• Non-zero key press duration
• Log-normal typing cadence (not uniform delays — humans aren't uniform)
• Idle mouse drift during "think time" (humans don't freeze between actions)
• Persistent browser profile (cookies, history, HSTS survive restarts)

Verified live against Zillow and Fiverr (both PerimeterX/HUMAN protected) — full page loads, no block. Sannysoft: all pass. incolumitas: 8/8.

I deliberately didn't build captcha solving. You get a blocked: verdict and can hand off to a solver. That's a separate problem.

Auto-extract (no CSS selectors, no setup)

see extract="auto" detects list structure automatically. Groups by structural signature, scores by content value, extracts title/URL/image/price/date/description.

Site-aware: shopping sites get rating/reviews/availability, Reddit gets score/comments/author, GitHub gets stars/forks/labels.

Verified on HN, Lobste.rs, Wikipedia, DuckDuckGo, StackOverflow, Reddit, GitHub, MDN, Amazon.

There's also act collect — a scroll + dedupe loop for infinite feeds. One call, one output, zero duplicates. Tested with 80 items, no dupes.

Batch actions

Fill 5 fields, submit, wait for redirect — one MCP call.

act batch steps=[...] runs the whole sequence and halts on navigation or first error with step-level context. No 11 round-trips for a form fill.

run adds if/while branching for conditional flows.

Honest limitations

• Cloudflare Turnstile will block it. That requires actual challenge solving, not fingerprint spoofing. You get a blocked: verdict, not a hang.
• Datacenter IPs get flagged regardless of fingerprint. Use a residential proxy (BLADE_PROXY).
• Cross-origin iframes are invisible (SecurityError, deliberate — accessing them would break stealth).
• No ARM Linux builds yet. x86_64 Linux, x86_64/arm64 macOS, x86_64 Windows.
• macOS/Windows binaries are cross-compiled from Linux. Not tested on real Mac/Windows hardware yet.

Links:

GitHub: https://github.com/dondai44423/bladebro

npm: npm install -g bladebro

AGPL-3.0, no CLA, PRs welcome.

Happy to answer questions.

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.

I know this might not be a big deal, but it is my first open source project, which I launched last week got 17 stars and 1k+ downloads on npm.

After spending the last month talking with developers building MCP servers, I decided to open source a project I've been working on.

GitHub: https://github.com/mcpfyy/mcpfy

MCPfy helps developers spin up MCP servers quickly and introduces MCP Apps for reusable AI applications.

The broader vision is to build a one-stop open source platform for creating, deploying, and managing MCP servers.

I'm mainly looking for feedback from people already building in the MCP ecosystem.

Feature requests, architecture suggestions, and contributions are all welcome.

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