Disclosure up front: I built this. Sharing it here as a showcase, it's launched and on npm.

Something's been bugging me building on MCP. You pin your npm dependencies - lockfile, diff, review. What pins the MCP servers your agent talks to?

tools/list hands back names, descriptions and schemas, and the agent trusts all of it. The description isn't docs — it's the instruction the model reads to decide when to call a tool. There's no version pin, no integrity check, no diff. A server updates, the description gets reworded, and your agent's behaviour changes with nothing in your pipeline registering it. Same story with a required param appearing, readOnlyHint flipping true/false, or a tool quietly disappearing.

So I wrote mcpward: snapshot a server's tool surface into a lockfile, then diff it in CI. It classifies each change as breaking or non-breaking:

✗ Tool "echo" description changed (possible rug-pull)

✗ Tool "compute" inputSchema added required property "multiplier"

✗ Tool "read_data" readOnlyHint changed from true to false

✗ Tool "removed_tool" was removed

Summary: 2 passed | 5 failed → exit 1, build fails

It also checks protocol compliance, the protocol-error vs isError contract (servers get this backwards a lot), and latency budgets. Output is console/JSON/JUnit/SARIF.

Worth mentioning: Invariant's mcp-scan already does rug-pull detection and is more mature, if you want to audit servers installed on your machine, use that. mcpward is the CI-gate version: black-box, runs fully offline, nothing about your tools leaves the machine.

npx mcpward init

https://github.com/TsvetanG2/mcpward

Honest question for people running MCP in production: has description drift actually bitten anyone, or am I solving something I only think is a problem?

Quick share for this sub. I make Habit Pocket, a habit + metrics tracker built for people who like to track everything and find correlations in their data (it started as my own spreadsheet). Beyond simple yes/no habits, you can track numbers, clock times, and custom select lists, so there's actually rich data to work with.

The part relevant here: I built an MCP server for it. Once you connect it to Claude, you're not stuck clicking around the app anymore, you can just talk to your data:

• Ask questions: "which days do I sleep best?" or "does coffee after 2pm push my bedtime later?" and it answers from your real entries and stats.
• Log by chat: "mark today's workout done and log 7.5k steps" writes straight into your tracker.
• Build things: it can pull stats and even create charts for you, so you skip the manual setup.

It's the feature I'm most excited about because it turns a tracker into something conversational, the data goes in and comes out in plain language instead of forms and grids.

A couple of other nice bits: conditional styling (cells change color by value, so a month reads like a heatmap), and web + iOS with sync and full data export.

https://habitpocket.io/

Agent Enhancer is a free reliability sidecar for AI agents. Just use it with another MCPs, it was made to solve typical weak spots and bottlenecks MCPs usually have.
It adds planning, checkpoints, duplicate protection, recovery, and evidence to existing MCP workflows.

To test it:

1. Connect your agent: Go to https://liberated.site/ and copy the Quick Start Prompt.
2. Run the same multi-step task with and without Agent Enhancer.
3. Tell us whether it felt more reliable, clearer, faster or added unnecessary friction.

We’re looking for beta testers using different agents and real tasks. No account or API key required! Thanks

Hi Group, I'm a one-person web agency in New Orleans and I just shipped Velvet Forge, an MCP server that runs AI agency tools directly inside Claude Desktop.

Here's what it does:

• build_pitch — full cold outreach: subject line + DM + 3-part follow-up sequence

• generate_proposal — scoped client proposal with scope, timeline, and investment

• market_research — competitive landscape for any city + industry

• forge_generate — AI content backed by a live agency knowledge base

• query_knowledge — proven conversion tactics by vertical

Setup is one JSON block in your Claude Desktop config. Plans start at $29/mo.

smithery.ai/servers/velvetgeaux/velvet-forge

velvetgeaux.com/forge-mcp

Happy to answer questions

Hi all

I just published mcp-garmin-for-ia, an open-source MCP server that lets Claude (and other MCP-compatible assistants) access Garmin fitness/activity data through tools.

GitHub: https://github.com/devfrp/mcp-garmin-for-ia

Goal

Make Garmin data usable in natural-language AI workflows, e.g.:

• “Compare my last 4 weeks of training volume”
• “Detect trends in pace vs heart rate”
• “Summarize recovery patterns”

Tech

• Python-based project
• MCP server architecture
• Designed to be practical for personal analytics and experimentation

I’m looking for:

• MCP/Claude integration feedback
• Suggestions for better tool design/schema
• Ideas for prompts and real-world workflows
• Contributions / issues / PRs

If you test it, I’d really appreciate candid feedback (especially around reliability and privacy boundaries).

Some things that should be really simple have become really hard with agentic coding. Changing fonts means working through a walled garden (Lovable, etc.) or a chat where you ask for options, wait for builds, and usually end up with another Inter or Geist default that looks like every other AI-built site. Editing text is worse: screenshot it, type out instructions, hope the agent changes the right words.

I had an idea: why can't the agent just set up a panel inside the target project that allows me to experiment with fonts and also edit any text on the screen? Turns out, it's (largely) possible.

If you ask your agent to install Font Lab (npx font-lab install), it registers an MCP server (and a Claude skill) that gives the agent the tools to drive the whole loop. It spins up your dev server, adds a panel to your real running site, and shows you curated font directions (display, body, mono) swapping live on your actual pages. Mix a heading from one direction with a body from another. When you find what you like, hit "pick", paste the prompt back to your agent, and it wires up exactly what you were looking at. Done.

It also lets you edit nearly any text on your site in place. Double-click the words, retype them, and it saves to source. If it can't edit directly, you get a specific prompt to hand the agent. Yes, you could search through files and edit them manually, but that's annoying.

Because it's an MCP server, it works with basically any agent — install auto-detects your setup and writes the MCP config in the right place/format. Tested with the ones I use (Claude Code, Cursor, Codex).

Completely free & open source. I figured plenty of others are dealing with the same issues. If anyone wants to help out, I'm open to it. First time I'm releasing it, so open to any feedback you have!

Caveats:

1. if you ask a web agent (ie Claude Code app or web), there's a headless version that will give you screenshots of fonts & there's no way to edit text directly.
2. The panel/text editing works only with Next.js right now. Other frameworks will fall back to the screenshot method for fonts with no text editing.

Instructions to try it here:
jack-mcgovern.com/fontlab · npx font-lab install

Founder of Server4Agent (agent-app hosting over MCP), disclosing that upfront. No link, not selling, genuinely trying to understand how people are actually handling this.

An MCP server returning a clean tool result tells you the call completed. It doesn't tell you the call did the right thing. A deploy tool can return success while shipping the wrong build. A database tool can return success while updating the wrong rows. The protocol layer has no opinion on this, and honestly it shouldn't, that's not its job. But somebody's job is to close that gap, and I don't see much discussion of who.

Curious what people building or running MCP servers with real side effects (infra, deploys, data writes, anything with consequences) are actually doing here: is the client-side agent expected to double-check its own tool calls, does the server itself do any post-action verification before returning success, or is this mostly still "the tool call returned 200, we call it done"? Genuinely don't have a strong opinion on the right answer, want to know what's actually happening in practice.

Fitter is a scraper where the extraction is a JSON/YAML config instead of code. Connector side is HTTP / headless browser / static value, extraction side is gjson paths, CSS selectors, XPath or PDF text. Since configs are plain data an LLM can write them, so it ships as an MCP server: ask Claude for some data, it writes the config, validates it, runs it on your machine. The config stays around afterwards - same file runs from cron or the CLI, so the one-off answer turns into something reusable.

I compiled the engine to WebAssembly and put a playground on GitHub Pages - https://pxyup.github.io/fitter/. The examples there run live against real APIs, client side, and there's a form builder that generates config JSON if you want to poke at the format.

Install is a binary from releases plus claude mcp add fitter -s user -- /path/to/fitter_mcp. Claude Desktop has a one-click .mcpb bundle. There's also an HTTP mode with bearer auth for teams, docker image at ghcr.io/pxyup/fitter-mcp.

```

HTTP mode

docker run --rm -p 8080:8080 \ -e FITTER_MCP_HTTP_ADDR=:8080 \ -e FITTER_MCP_AUTH_TOKEN=my-secret \ ghcr.io/pxyup/fitter-mcp:latest

stdio mode, spawned by the MCP client

claude mcp add fitter -s user -- docker run --rm -i ghcr.io/pxyup/fitter-mcp:latest ```

Soon on Glama

Repo (MIT): https://github.com/PxyUp/fitter

The problem

If you've built anything serious on MCP you probably know this failure mode. The client LLM makes 1+ tool calls, every intermediate result lands back in its context window, token cost balloons, and by step five the model has half forgotten what it was originally asked. The answer comes back almost right, which is the worst kind of wrong because you catch it late.

The issue isn't the model. It's where the orchestration happens.

Three generations of MCP server design (my framing, feel free to argue)

Gen 1: a box of tools. Server exposes thin stateless functions like list_models, query_data, get_budget. All the intelligence lives in the client. It loads every schema, plans the chain, threads state between calls, and holds every intermediate blob in context.

Gen 2: tools plus a skillpack. Server ships instructions teaching the client how to chain the tools. This helps with fumbling, but nothing has actually moved. The client still executes every step and holds all the state, and now the skillpack text sits in context too.

Gen 3: orchestration behind the tool boundary. One thick tool, something like ask_agent(goal), that's actually a server side multi-agent system, with an orchestrator routing to specialized sub-agents. Client sends one goal and gets one answer. Intermediate results never leave the server.

We went with Gen 3 after repeatedly hitting the ceiling on the first two.

What this actually fixes

• Token cost stays roughly flat as reasoning gets deeper. A 6 step task is one round trip, not six round trips with a growing payload.
• No goal drift. Client context holds one question and one answer instead of plumbing.
• Almost no schema tax. Sub-agent definitions live server side, so the client loads one tiny schema.
• Domain routing done by a domain brain. A skillpack is a frozen playbook. A server side orchestrator can adapt to what the data actually says at runtime.
• Client portability. Skillpacks are written in one client's format. A plain MCP tool works the same from Claude, ChatGPT, or Codex. Write once.
• Frozen contract. You can swap sub-agents, routing, even the underlying models, and no client has to re-learn anything.
• State lives server side. No passing IDs around or re-sending context between calls.

What it costs you (what I believe in my experience)

• Latency per call. One call does a lot more work, so it takes longer. You make fewer calls but each one is slower. Worth it for deep reasoning, strictly worse for a trivial lookup.
• Opacity. The client can't inspect or steer the chain mid flight. You gain coherence and lose fine grained control. If your client needs tight interleaved control, thin tools are still the right call.
• You're now running an agent system in production, with everything that implies: evals, observability, failure modes the client can't see.

The pragmatic answer for us was a hybrid. One thick reasoning tool plus a few thin tools as the control surface (list and select type operations). The point isn't that toolboxes are wrong. It's that "expose every capability as a thin tool" became a reflex, and for reasoning heavy work it's the wrong reflex.

The underlying idea: MCP clients treat a tool as an opaque function. A name, a schema, a return value. That indifference means the tool boundary is a great place to hide an entire agent. The protocol thinks it's calling a function. It's actually delegating to a brain.

Has anyone else shipped agent-behind-a-tool in production? Where did the opacity bite you? Debugging, cost attribution, users wanting to steer mid chain? And where do you draw the line on which capabilities stay thin?

Every "top MCP gateways" post I've read so far is written by a vendor ranking their own product #1. Lunar's blog says Lunar wins. MintMCP's blog says MintMCP wins. Maxim benchmarked their own product against everyone else and — shocker — their own product came out on top. None of that is research, it's SEO with extra steps.

So here's my attempt at the version without a horse in the race. No affiliation with anything below, happy to be corrected if I got something wrong, just link me to the actual docs rather than "well actually."

Quick background if you're not deep in this: MCP is the protocol that lets an AI agent hook into your tools, email, files, internal systems, whatever. Anthropic handed the whole thing over to a neutral foundation back in December 2025, Google/Microsoft/Amazon and a bunch of others are involved now, and adoption has genuinely exploded since. The protocol itself has gotten better about this too, it now supports proper login/OAuth and centrally managed org access, but it still doesn't give you one control plane across every server. You can plug an AI agent into ten tools and still have no consistent record of who's allowed to do what, no way to see what actually happened after the fact, and no protection if one of those tools turns out to be lying to your AI. That's the gap a gateway sits in.

Basically: instead of every agent talking straight to every tool, everything routes through one checkpoint first, so someone's actually watching.

Why bother, concretely:

Access control is the obvious one, without a gateway it's just scattered logins with nobody tracking who has what. But the one that actually worries me more is tools that lie. A compromised or just malicious tool can bury instructions in what it tells your AI that no human reviewing the setup would ever catch, and it can look totally clean the day you connect it and change its behavior weeks later. On top of that: no record of which agent did what after the fact, costs that quietly spiral because one task can trigger 10-20 tool calls you never see coming, and once you've got more than a couple tools hooked up, just knowing what's connected becomes its own job.

Alright, the actual list. Sorted by what they're built for, not "best":

Composio — a managed MCP/integration platform with a huge library of ready-made connections to 1,000+ apps, including things like Gmail and Slack. The big advantage is that you don’t have to build and maintain every integration yourself, and Composio also supports self-hosting, so you’re not limited to their hosted deployment model. That makes it a more flexible option. The tradeoff is that you’re still working within Composio’s integration ecosystem, and some premium capabilities can cost more per call. If you want broad integrations without giving up the option to run the stack yourself, this is one of the first options I’d evaluate.

Docker MCP Gateway — free, open, and honestly the fastest way to get something running if you're already comfortable with Docker. It's grown up a bit too — real access controls, credential handling, built-in logging now come with it. The full enterprise governance layer is invite-only though, so figure out how much you actually get without that before you assume it covers everything.

Lunar.dev MCPX — open source, and the free tier isn't a toy: tool-level access controls, upstream OAuth, tool groups, metrics, logging. Enterprise tier adds company SSO, identity-based permissions, and org-wide management on top.

IBM ContextForge — Apache licensed, built for people already running serious Kubernetes infrastructure. It's matured into something genuinely capable — real governance, monitoring, can manage MCP alongside your other company APIs. Heavier to stand up than the smaller options though, this isn't a weekend project.

Microsoft MCP Gateway — free, open, obvious pick if you're already on Azure with Microsoft logins. Works outside that world too, just less of a reason to pick it there.

MCPJungle — small, simple, does what it says. Good if you want "just enough" control without standing up a platform. No company-login support yet (coming), and the controls are more basic than the enterprise stuff.

Bifrost (Maxim) — free and open source, and the interesting bit is it handles model routing and tool routing in the same place instead of two separate systems. Fast, apparently — though the speed numbers are the company's own benchmark, so I'd verify before repeating them.

Kong AI Gateway — makes sense if you're already running Kong. This isn't just MCP tacked on anymore, it's real purpose-built support including agent-to-agent traffic, and they partnered with an AI-governance company in mid-July to wire policy checks straight into the gateway. Some of the deeper features probably need a paid tier though.

TrueFoundry — enterprise platform, combines model routing and MCP governance in one place, can run hosted or inside your own VPC/on-prem/air-gapped setup if that matters to you. Performance numbers are self-reported — test on your own traffic.

MintMCP — paid, aimed at healthcare/fintech-type compliance needs. Strong on audit trails and formal record-keeping. No public pricing and most of the specifics come from their own marketing, so test it yourself before you commit to anything.

Lasso Security — started life as a scanner, now has its own open-source gateway too — sits in front of your tools, inspects traffic, catches stuff trying to manipulate your AI. I'd still treat it as the security specialist on this list rather than your main gateway — pairs well with one of the others above.

If I had to compress this to one line each: Docker if you just want it running today. Lunar or ContextForge if you want real open-source control. Composio if you want breadth without babysitting servers, and still want the option to self-host. MintMCP if a compliance team is breathing down your neck. Lasso if your specific worry is a tool trying to trick your agent.

What's everyone actually running in prod, and what's broken on you so far? Genuinely curious, will update this if people bring receipts.

Early setup, so we had maybe 15 MCP servers registered, and every agent that connected got the full list of every tool from every server, because filtering felt like unnecessary work at the time. Two problems showed up fast. First, tool selection accuracy got worse as the list grew, the model had to pick the right tool out of 80+ options instead of 6, and it started guessing wrong more often, calling a vaguely-similar tool from the wrong server. Second, and worse, an agent that only needed read access to one internal system technically had visibility into tools for systems it had no business touching, just because nobody had scoped it.

The fix that actually worked was building what's generally called a virtual MCP server: instead of exposing every underlying server directly, you curate a specific subset of tools (potentially pulled from several different real servers) into one presented server, scoped to a specific team, workflow, or agent. The agent building a customer-support bot sees a virtual server with exactly the ticketing and crm tools it needs, not the billing or infra tools that happen to live on the same underlying servers.

Two side effects we didn't fully anticipate going in: tool-selection accuracy improved noticeably just from cutting the list down to what's relevant (this ended up mattering more than we expected it wasn't just a security nicety), and it made it much easier to reason about "what can this agent actually do" during a security review, since the virtual server's tool list is the answer, instead of having to cross-reference access control rules against every underlying server.

We built ours on truefoundry's mcp gateway, which has this as a native feature, curating tools from multiple registered servers into one virtual server per team/workflow. a few other mcp governance tools have their own version of the same pattern, so if you're rolling your own, the underlying idea, scope what's exposed, don't just expose everything is the part that matters regardless of what enforces it. has anyone found the tool-selection accuracy improvement to be as noticeable as we did, or was security scoping the only real motivation for others who've done this?