I'm building a API product and I'm looking at adding MCP support so that AI agents can interact with my platform. (Just playing around with the idea right now, let's see where it ends up. )
I'm trying to decide what the right architecture is for a production, multi-tenant MCP implementation.
AI seems to suggest the same thing, but I need something more intuitive.
Any ideas?
MCP gets several important things right, particularly standardized integrations, authentication and transactional actions.
But should agents also depend on runtime MCP calls to gather substantial context across applications?
We tested this across 20 scenarios using the same agent harness, model, prompts and machines:
The filesystem implementation was Locality, which I work on.
The most revealing trace involved identifying product-launch risks across Slack, Linear, Notion and a Git repository.
The MCP agent gathered the evidence iteratively:
The filesystem agent used parallel rg and file operations across the same sources. The equivalent stage took roughly 0.3 seconds.
Across 60 paired runs, the filesystem setup reduced LLM costs by 27% and end-to-end latency by 32%. Its answers were preferred in 70% of the blind comparisons.
Our takeaway is a separation of responsibilities:
Locality keeps permitted application data synchronized and exposes it as files. The agent can then search, filter and combine context through one interface instead of traversing multiple application-specific tools during execution.
This isn’t necessarily an argument against MCP as a protocol. It is an argument against using runtime tool calls as the primary context-retrieval layer for broad, read-heavy work. Interestingly, MCP already supports file:// resources, but most integrations still expose context through tool calls rather than a filesystem-like resource layer.
The benchmark focused on cross-application research and synthesis rather than transactional actions.
For people building MCP servers and agent infrastructure: does this separation match what you’re seeing - MCP for actions and another layer for context?
Went through the "which MCP do you actually use" threads on r/ClaudeAI and r/mcp, plus YouTube, X and a bunch of random articles that kept popping up, trying to separate what people actually run from what's just noise in the directory (20k+ servers on glama.ai, most abandoned). Grouped it into categories, chart's attached
Code & Dev Infrastructure
Communication & Productivity
Docs, Context & Search
Data & Observability
Business, CRM & Payments
Niche & Specialized
GitHub, Context7 and Postgres are the permanent fixtures for anything dev-related. Linear and Sentry showed up constantly too, people plugging error traces and issue tracking straight into the agent instead of tab-switching. A few I wasn't familiar with before this but look interesting: Home Assistant for homelab automation and Atomic Mail
What's in your stack that didn't make it onto here?
Hey everyone! observation from working in authorization: Identity programs have been putting serious work into agent authentication over the last couple of years, service accounts done properly, OAuth scopes tightened, secret rotation, short-lived tokens. The authN side isn't fully solved (it never is) but it's where most of the effort has been going..
The part getting less air-time is what happens after the agent is authenticated, when it's acting on a workflow and something starts looking off. The default plan there is still "if it misbehaves, kill the agent."
That stops working the moment the agent is wired into something real. Pulling the switch creates a secondary incident, halted workflows, paused queues, downstream teams scrambling. So the agent keeps running at full access while the team figures out what's wrong, because the standard toolkit doesn't have a middle setting.
A colleague of mine was talking to a CISO about this and the framing that CISO used was dimmer switch, not kill switch. The dimmer lives in the authZ layer at runtime, which is the part identity stacks haven't extended into yet for non-human principals.
In practice the dimmer looks like read-only on certain data first. Sensitive tools dropped next. Higher approval thresholds for anything above a certain size. Each adjustment is reversible and logged. If the agent turns out to be fine, restrictions fade back. if not, you keep tightening until access is at zero, but you got there deliberately and with a record
mechanism isn't new - per-action policy enforcement at runtime has been around for years for human users. What's newer for AI agents specifically is wiring it to the agent's identity, current task, and intent at runtime, so you can narrow scope without redeploying or stopping the agent mid-task.
My team and I (work at Cerbos) wrote up the full framing here: https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance
Now i'm curious to know how identity programs you all are seeing / part of, are organizing this. Is agent authorization landing inside the iam team, security ops, the application teams, or sitting in no man's land between them? If you're open to sharing - please do!
Usual caveat, none of this replaces human review of policy. Tooling makes the revocation mechanical. Humans still own the call on where the boundaries should sit :)
Disclosure up front: I work on the team behind StatsHawk, a sports-stats MCP server (+ REST API). I'm posting this because the session genuinely surprised me, it's the cleanest example I've hit of an MCP doing analysis.
I wanted a matchup card for last night's slate. I had an obvious angle: Kevin Gausman (splitter guy) vs Munetaka Murakami (who'd been chasing splitters). Asked Claude, connected to the MCP. What happened:
Take 1: Gausman's splitter eats Murakami. Claude pulled Murakami's strikeout splits and Gausman's K rate:
get_player_props(Murakami, "so")→ 1.43 K/g, but only 1.32 vs RHP; cooling to 1.1 over last 10
get_player_props(Gausman, "pitching.so")→ 5.46 K/start, UNDER 6.5 in 65% of starts, 5.0 last 5
Dead. Gausman isn't missing bats this year, and Murakami strikes out less vs righties. The premise was stale.
Take 2: Corbin Carroll (LHB) downgrades vs a lefty starter (Ranger Suárez). The lineup-card platoon read. Claude pulled it:
get_player_props(Carroll, "total_bases")→ vs LHP: 2.83/g vs RHP: 1.55/g
get_player_props(Suárez, "pitching.so")→ 3.2 K/start last 5, down from 5.1
Flipped again. Carroll is a reverse-split lefty, he crushes lefties, and the lefty he's facing has lost his swing-and-miss. The "platoon disadvantage" is actually a plus spot.
The point isn't any single number. It's that the model could keep pulling normalized splits and reason across them until the true story fell out, two hypotheses tested and discarded in one conversation. Every get_player_props call comes back with season / recent / home-away / platoon context already shaped, so the model reasons over structured splits instead of raw rows.
What it is: one normalized schema across MLB / NBA / NFL / NHL / NCAA / soccer with stable IDs, its own ingest (box scores, pitch-level play-by-play), transparent pricing, and a real free tier.
Honest limitations: samples get small, Carroll's vs-LHP split is 12 games, and I'd flag that on any card. It won't invent an edge; it'll tell you when the obvious take is wrong, which is the useful part. Coverage depth varies by sport (there's a capabilities call so the model knows what's actually there before it assumes). To reproduce this yourself: the raw box/play-by-play lines are on the free tier, so you can rebuild these splits by hand, the one-call prop/hit-rate card I used is a paid convenience, not a gate on the data.
The takeaway isn't a pick, it's that a model with structured splits in front of it will talk you out of the lazy take before you commit to it. That's the use case I keep coming back to.
Server + free tier: https://statshawk.ai, genuinely after feedback from people who've built MCP data servers, especially on the normalization layer.
I've been experimenting with an MCP auth proxy that sits between the MCP client and server and handles the OAuth/token lifecycle on behalf of the client.
The basic idea:
MCP Client → Auth Proxy → MCP Server
The proxy would handle things like:
The goal is that an MCP client shouldn't need to repeatedly deal with expired credentials or implement provider-specific refresh logic.
I'm considering making it open-source and self-hostable, rather than another hosted auth service.
I'm asking before building too much:
Is this actually a problem you're experiencing with MCP?
Particularly interested in people using Cursor, Claude, VS Code/Copilot, or custom MCP clients.
How are you currently handling token expiration and refresh? And what would make a proxy like this useful enough for you to actually deploy?
I'm more interested in hearing about existing pain/workarounds than getting "yes, I'd use it" answers.
If you instrument an MCP server with OTel, you get a clean trace of what happened inside the server. But it's an orphan — it doesn't connect to the agent trace that called it. You end up with two disconnected trees and no way to answer "which agent turn caused this slow tool call."
The fix is W3C traceparent propagation through the MCP request, so the server span becomes a child of the agent span. Shipped that in opentel-mcp v0.11.0.
Also in this release:
Still the only Node library I know of that catches CallToolResult.isError=true inside an HTTP 200 and marks the span as ERROR rather than success. That one silently ruins error-rate dashboards.
npm: https://www.npmjs.com/package/opentel-mcp
Docs and setup: https://opentel-mcp-site.pages.dev/
Happy to answer anything about the tracing model — the two-axis ToolOutcome × ObservationIntegrity contract in particular took a few iterations to get right.
I've seen a bunch of people talking about the same problem with MCP: orphaned child processes that don't die when they're supposed to. it's not just one person's issue either, the TypeScript SDK has an open issue where closing the transport doesn't kill the process tree, Codex CLI has one about orphaned npx-spawned MCP servers piling up over time, context7-mcp has one where the process just doesn't exit when its parent dies. all different projects, same root cause: something like npx forks the real server as its own child, and killing the wrapper's PID doesn't touch it.
I looked for a small library that just handled this and couldn't find one. I pulled this out of a bigger project I'm working on because it felt like something worth having on its own: https://github.com/ImDeadWeight/stdio-supervisor
what it does:
no protocol opinion, no daemonizing, no CLI. just the part where you spawn and keep a handful of stdio children alive without it silently breaking on you.
MIT. let me know if you find anything wrong with it.
Edit: a word
Edit: Now imports execFile, fs, path, and StringDecoder from Node. Also imports crossSpawn.
Create a free MCP server for your website or organization. It allows direct integration with any other LLM or agent.
Disclosure first: I build authorization tooling for agents, so I have an obvious bias and I have deliberately left my own product off this list. Everything below is from public docs, and I have flagged the places I could not confirm something rather than guessing.
I kept seeing the same question in threads here and in r/LLMDevs ("which gateway should I use", "is OPA overkill", "how do I stop the agent doing something dumb with a valid credential"), and every comparison I could find sorts these tools by protocol support and deployment model. That is not the axis that matters. Nearly all of them gate tool calls. What separates them is what the policy decision gets to look at when it says yes or no.
Three tiers, roughly.
Tier 1: the decision sees the tool identity only.
Kong's MCP Tool ACLs are explicit about this. Consumers get a filtered subset of tools based on identity, default-deny, and the gateway intercepts tools/list so a client never sees what it cannot call. Clean model, well documented, and access is binary per tool. Their docs describe no parameter-level evaluation.
Permit's MCP Gateway sits here too, with a trust-level classification (read / write / destructive) layered on top, plus a consent flow and human-in-the-loop. Their overview says it plainly: the gateway authorizes tool calls "based on identity and policy, not on the content or intent of prompts."
This tier is genuinely useful and it is not nothing. It also cannot express the rule most people actually want, which is not "may this agent call refund" but "may this agent call refund, for this customer, under this amount."
Tier 2: the decision sees the arguments, via code you write.
Docker's MCP Gateway interceptors are the clearest example. A "before" interceptor receives the full tool call as JSON, tool name and arguments, on stdin, and can block it. You can run them as exec scripts, containers, or an HTTP service. That is argument-level enforcement, but expressed as code rather than policy, so you own the correctness and the testing.
DashClaw is in this territory as well, open source, positioned as an approval and policy layer that intercepts risky actions before they run with remote approve or block.
Tier 3: policy-language rules over the call.
agentgateway (Linux Foundation, Apache 2.0) is the most interesting one architecturally. MCP and A2A native, CEL-based authorization rules evaluated against MCP method invocations rather than HTTP requests.
Here is where I have to be honest about the limits of my research: I could not confirm from the docs I could reach whether CEL rules there have the tool call's arguments in scope, or only the method and identity. Their MCP authz page points to a config reference for available CEL variables that I did not get to. If someone here has written an argument-conditional rule in agentgateway, I would genuinely like to see it, because it decides which tier the project belongs in.
Cedar and OPA keep coming up in these threads and are worth separating out. They are decision engines, not gateways. They will happily evaluate whatever you pass them, so which tier you land in depends entirely on what your enforcement point puts in the request, not on the engine.
The thing none of them do.
Every tool above authorizes one call at a time. The failure that survives per-call authorization is a sequence of individually allowed calls that adds up to something you would have denied. Read customer, read billing, write to an allowed external destination: three passes, one exfiltration. Argument-level policy does not catch it, because each call is genuinely fine on its own.
I have not found anything that evaluates accumulation across a session against a declared purpose. If it exists I would like to be corrected.
Two questions worth asking any vendor in this space, including me:
Those two sort the field faster than any feature matrix.
I have deliberately left out a few products that came up in threads but that I could not find public documentation for, since I am not going to describe something I cannot verify. If you are running one of these in production, especially at any scale, I am more interested in where it broke than in what the docs claim.
I'm a Research Engineer at a YC startup, and we ship features pretty fast. I usually run Claude Code, Cursor, Codex, and OpenCode in parallel, developing multiple features, one at a time.
The problem i noticed was that my agents had no coordination, and often confused mutual work, even when working in separate worktrees. As if they had no idea the others existed
So, I built MUON, it's a local app + mcp + cli, a mutual shared brain my agents can plug into. it drives the CLIs you already have and orchestrates them together for multi-feature execution workflows.
I'm still building it. Right now I use MUON to work on MUON, which is a weird but useful dogfood loop.
If anyone wants to poke at it, contributions are welcome. The thing I'm trying to get right is a coordination graph: shared memory and context so agents actually understand what the others (and I) already decided.
OSS Repository : https://github.com/Sweetdevil144/muon
Website : https://getmuon.com/
Docs : https://docs.getmuon.com
Product Demo : https://www.youtube.com/watch?v=oab6vByr1Jg
I've always been an open-source person, so the code is public and readable. License is Polyform Noncommercial. However, there's an extra grant on top - you can use it for your own work, including your day job, on your own machines. What it doesn't cover is turning it into the company's shared brain for a whole team (Enterprise only)
Disclosure up front: I built this. It's free, MIT, and shipped (npm: rungraph).
Claude Code and Codex CLI write full session transcripts to disk, and rungraph reconstructs them into interactive run graphs. The MCP server is the part this sub might find interesting: npx rungraph mcp --install gives your agent tools over its own history. list_runs, get_graph, find_nodes, get_detail, focus_nodes, get_current_view, open_visualization.
The design problem was context size. A real 176-node run is about 20k tokens as a full graph, 13.5k in the compact projection, and 1.1k through find_nodes. Narrowing beats projecting, so the tool descriptions steer agents to find_nodes first, then get_detail for one node's actual error text.
The fun tool is focus_nodes. You ask Claude in your own terminal "why did the Edit on token.js keep failing", it answers there, and the dashboard you have open lights up the exact nodes the answer is about, then returns a deep link that restores the same highlight against that dashboard (or a bundle the recipient has open). Honest limitation: with no dashboard watching, the call still succeeds and just reports that the highlight was skipped. The read tools parse straight from disk, so they work with no server running at all.
Implementation note for the protocol nerds: the JSON-RPC transport is hand-rolled over stdio because the package has zero runtime dependencies, which keeps the npx install tiny. If more than one dashboard is live (yours, plus a bundle someone sent you), list_runs merges them and every other tool routes by run id.
Live Demo: https://fayzan123.github.io/rungraph/
Repo: https://github.com/fayzan123/rungraph
If you wire it into a client other than Claude Code, I'd like to hear whether the tool descriptions hold up
I kept hitting the same wall running coding agents across a few machines — a
WSL box, a laptop, a VM. Each Claude Code session was its own island. I could
not see what any of them were doing without SSHing in, and none of them shared
any context with each other.
So I built SiloLink. It is a small local daemon that does two things:
The result is that each remote Claude Code session is bound to a conversation
thread. You send a message to the thread and a session spawns on that machine
(tmux), picks up the message, and replies into the thread. You can drive it from
a web UI, Slack, Discord, or SMS. Session dies, remote_load_context restores
the prior history on restart.
Things that turned out to matter more than expected:
Source: https://github.com/portablemind-ai/silolink (MIT)
Install: npm install -g @dsiloed/silo-link
Disclosure: the server side it talks to is Portablemind (https://app.portablemind.ai),
my commercial platform — that is where the conversations, files, and shared agent
memory live. The daemon
itself is MIT and the MCP interface is documented, so it is usable as a reference
for anyone building a similar bridge.
Happy to answer anything about the MCP-server-plus-WebSocket shape — deciding
what belongs in MCP tools vs. the socket was the least obvious part of the design.
Hey everyone!
Over the past year, as I tried to scale our agentic coding workflows and software factories at my company, I kept hitting the same set of problems. So I built HAR to solve them.
Repo: github.com/os-factory/har
Getting a single coding agent to work in a repo is easy. Scaling to a real multi-agent workflow, where several run at once and where you verify and trust the output, is where it breaks down. A few things go wrong:
What HAR does
HAR is a CLI and an MCP server. It works with Claude Code, Cursor, Codex, or any MCP agent, and it closes each of those gaps:
All of this lives in one contract committed to your repo, which every agent reads the same way. It replaces the usual scatter of a README, a CLAUDE.md, editor rules, and CI config that drift apart. You start from a profile that matches your stack, your agent adapts it to the real repo, and you extend verification with plugins (like Playwright) or with any command you already run.
Give it a try and let me know what you think :)
Everyone tests the happy path on their MCP server. I did too, and it hid the problems that actually bite in a real client.
So I wrote a harness that drives the server over stdio the way Claude Code does, and deliberately broke things. Setup: 45 tools, protocol 2024-11-05.
The four cases worth asserting on, in rough order of how much pain they cause:
1. Missing credentials entirely. Should fail immediately with a message naming the variable. If it starts fine and only dies inside a tool call, the model will try to work around it, and you end up debugging the model instead of the server.
2. Bad credentials. Should surface a readable error. A raw stack trace here is worse than useless, because the model cannot tell an auth problem from a transport problem.
3. Unknown tool name. Should be rejected cleanly. Models hallucinate tool names more often than people expect, especially with 40+ tools listed.
4. Invalid params. Should come back as an error the model can act on. This is the one that decides whether the model self-corrects or gives up.
The other assertion I would not skip: on tools/list, check every tool has a non-empty description and a valid inputSchema. Boring, and it caught a real problem for me. Separately, if any tool is long-running and returns a job id rather than a result, make sure the description says so. Mine did not, in 43 of 45 tools.
Implementation notes if you build one: read stdout line by line on a background thread, parse each line as JSON, match responses by request id rather than assuming order, and give the poll loop a hard timeout so a hung server fails your test instead of hanging it.
Took an afternoon. I would not ship an MCP server without it now.
Disclosure: I build an SEO API for agents, and this was our own MCP server. Nothing to buy here, the failure-mode list is the point.
One interesting part of MCP Apps is that the UI doesn’t have to be a disposable interface generated for a single model response.
I’ve been experimenting with this from the Java side using Spring Boot, Spring AI and webforJ.
The architecture is roughly:
MCP host -> tool call -> Java application -> rendered view
A routed Java view is exposed as both an MCP tool and UI resource. The same route can still run as a normal application in the browser.
The more interesting part is what happens after the view opens.
Additional MCP tools can target the rendered view associated with the same MCP session. A tool call can therefore modify the state of the application the user is currently looking at rather than returning another detached result.
Communication also goes the other way. When the user interacts with the Java UI, the application can update the model context. For example, selecting rows or changing a filter can change what information is available to the model without adding another visible chat message.
That makes the interaction roughly:
prompt -> MCP tool -> Java view -> user interaction -> model context
For example, an invoice application can expose an operation that opens its invoice route with an overdue filter. Once open, another tool can change the same view to display an aging chart. The user can then manually change the selection and make only those selected invoices available for further analysis.
The application itself remains a Java application. Spring Boot runs it, Spring AI provides the MCP server integration, and webforJ handles the UI.
I work on webforJ, for disclosure. The implementation and API are documented here:
https://docs.webforj.com/docs/integrations/mcp-apps/overview
I’m curious what people think about this interaction model. In particular, whether sharing one live application state between the human UI and model feels more useful than having the model generate a separate UI/result each time.
The number of MCP servers is not the confusing part. The awkward bit is deciding who should own their configuration and permission boundaries once work moves between clients.
The client can own everything, which keeps each setup isolated. The repo can own it, which makes project context portable. Or the workspace can own it, which makes reuse easier but creates a much bigger surface to reason about.
holaOS makes that third option concrete in its official marketplace UI: the project documents one workspace where MCP servers, skills, and integrations can be reused. What the supplied README and UI do not establish is how finely those permissions can be scoped.
For people who switch MCP clients, where has this boundary worked best? What belongs with the repo, and what should never leave a client-specific config?
Hello i've used for a lot mcp-reddit-server, but now it doesnt work anymore, are there any good mcps for reddit?
I’ve been working on Dagflo, animated visual explanations for software teams!
Dagflo lets coding agents like Claude, Codex, and Cursor turn codebases, pull requests, systems, articles, diagrams, and algorithms into animated, step-by-step visualizations.
After four years working in GraphQL infrastructure at Meta, I've seen countless engineering hours (meetings, message threads, whiteboarding) wasted and bad decisions made because technical knowledge wasn't communicated clearly.
Coding agents can now understand entire codebases, but they still explain them through walls of text, broken ASCII art, or static Mermaid diagrams.
We're using static tools to explain dynamic systems.
That's why I built Dagflo. I wanted to actually see how technical systems work.
This has been a passion project for a year; I'm really excited to share it! I've made a couple of other posts in the subreddit to gauge interest; now it is finally ready!
Early access is live dagflo.com
Follow me on X for Dagflo updates: deepok102
PS: It's forever FREE, so give it a try!!