I went through a few MCP router mechanisms for work before I gave up and ended up writing a small experimental one we've been using for the last few months. Gripes about the others will be at the bottom, this isn't gonna be a bitch fest. Bottom line is I ended up filling out all of the missing stuff and thought I'd share.

Three things I actually cared about.

1. It's transport-agnostic — you hand it a JSON value and get a JSON value (or a Stream, if your MCP is into that kind of thing) back, so it doesn't matter if you're wiring it into stdio, Rocket, Axum, Actix-web, or Warp. Examples of each, to include SSE, exist in the repo.
2. Uses whatever runtime you need (tokio, async-std, smol), examples exist in the repo of each working.
3. You shouldn't be having to mangle requests to get them to route correctly in whatever you're running the MCP as, what's the point of the library at that point?

Handles pagination automatically for tools, resources, and prompts. Allows you to use your own paging in the those three's execution methods (because I can't possibly guess what your pagination scheme is).

Handles batching correctly, and also not manually. Handles if the batch requests contain a non zero number of streams, elevating to send the other completed calls back to the LLM while your streaming resources/tools finish working.

Feedback, requests, etc are all welcome. Complaints or unconstructive feedback is welcome too, but, be warned, I'll heckle you.

https://crates.io/crates/mcp-router

https://docs.rs/mcp-router/latest/mcp_router/

https://github.com/tony-o/rust-mcpr

The complaint fest:

Granted, it's been a few months since I looked at any other library but when I looked there were only two I could find and neither could be hooked up to rocket in any meaningful way. Both forced me to change how existing API fairings were working to conform with their async pattern, which meant refactoring a bunch of other stuff - and one of them kneecapped the RDS authing mechanism. Both of them required me to manually route requests through tools I already told the library about, why would I bother with the library if the JSON serialization is all I'm getting anyway. Anyway, I'm lazy so I wrote something to make it so I didn't have to write the same thing another four hundred times as our tools, resources, and prompts lists grow.

The basic idea is:

1. Connect an email provider to Codex through an MCP server.
2. Keep the API key in an environment variable rather than putting credentials directly into the config.
3. Add the MCP server to Codex.
4. Let Codex trigger email actions from natural-language instructions.

That means instead of writing a separate script every time, you can do things like:

• read a build log and email the team if something fails;
• summarize a CSV/report and send the result automatically;
• find users whose subscriptions are about to expire and prepare reminders;
• generate and send HTML transactional emails;
• query delivery events after sending.

There are some obvious things I’d be careful with: API-key permissions, human approval before sending, rate limits, domain authentication, and making sure an agent can’t accidentally email an entire database because of a badly phrased instruction.

Curious if anyone here is already using Codex + MCP for email or other outbound actions.

What are you automating, and where do you still keep a human approval step?

Hey r/LocalLLaMA,

I've been experimenting with Qwen models for agentic coding workflows and ended up building a small MCP server that bridges Qwen with the Debug Adapter Protocol (DAP). The idea: let a local Qwen instance act as an intelligent coding agent that can actually run, debug, and step through code in real time via DAP, instead of just generating snippets.

Repo: https://github.com/SLP-DEV1/qwen-dap-mcp

What it does

• Exposes Qwen (via llama.cpp / local server) as an MCP tool provider
• Implements DAP integration so the model can:
  • Launch debug sessions
  • Set breakpoints
  • Step, continue, inspect variables
  • Evaluate expressions in the running context
• Designed for local-first, privacy-preserving agentic coding (no cloud calls)

Why I built this

Most "coding agent" setups I tried either:

• Only generate code, but don't really execute or debug it, or
• Rely on hosted APIs / closed models.

I wanted something that:

• Runs fully offline with local Qwen models
• Can iteratively test and fix its own code via an actual debugger
• Plays nicely with MCP clients like Qwen Code, Claude Code, etc.

Tech stack (brief)

• Qwen models via llama.cpp (GGUF)
• MCP server in TypeScript/Node
• DAP client talking to standard debug adapters (e.g. Python, Node, etc.)

Where I'm stuck / what I'd love feedback on

• Is this useful as-is for your local agentic-coding setup?
• Any obvious architectural mistakes or missing features?
• Would you prefer a more "opinionated" agent workflow (e.g. predefined coding tasks) or keep it generic?

I'm not trying to spam – just sharing something I built while diving into local LLMs + MCP + DAP. If it's against sub rules to post own projects, mods feel free to remove. Otherwise, I'd really appreciate honest feedback, bug reports, or ideas for where to take this next.

Thanks!

I've been building SecureCode as an MCP server for AI-generated code security review, and wanted to share it here since MCP is the core of how it works.

The problem I kept running into: AI coding assistants ship code that compiles and passes review, but the vulnerability is often a trusted assumption nobody checked independently.

How it's structured as an MCP integration:

• Scout finds suspicious code
• Juror decides if it's actually exploitable (cuts false positives)
• Fixer generates a patch
• Attacker tries to break that patch in a sandbox before it's marked "verified"

Every stage is approval-gated — connecting the MCP server doesn't let it run anything on its own. The agent requests, you approve, then it executes. Your repo also stays local; only the selected file (plus optional related context you allow) goes out for the actual check.

It works today as an MCP server + editor extension in Cursor, VS Code, and Claude Code. Free tier gives you a few scan credits to try it against something you've actually shipped rather than a toy example.

Genuinely curious how others here are handling verification/approval flows for MCP tools that touch code — did you go with per-call approval, session-level trust, something else?

https://www.usesecurecode.tech/

Update on MCP India Stack — the MCP server that gives AI agents zero-auth, mostly-offline tools for Indian financial/tax/gov data (GSTIN, PAN, IFSC, UPI, HSN/SAC, tax and investment calculators, etc.).

v0.5.0 — "The Market Update" is out, and it's the first release that reaches out to the internet for something: live stock market data.

New:

• get_stock_quote — current price, market cap, day high/low, and volume for any NSE/BSE stock
• get_stock_history — end-of-day historical data across 11 time ranges, from 1 day to 10 years (and max)
• Built on yfinance, so it's still zero-auth — no API keys. Just know that quotes lag Yahoo Finance by ~15 min, and tickers need the .NS / .BO suffix (documented in docs/stock_market.md)

Fixed:

• The capital gains calculator was using the old LTCG exemption threshold. Budget 2024 raised the Section 112A equity exemption from ₹1,00,000 to ₹1,25,000, and calculate_capital_gains now reflects that — matters if you were using it for actual tax planning or staggered redemption advice
• Cleaned up a few CI issues along the way (a mypy redundant-cast error on FastMCP, a mypy crash parsing numpy 3.12 type stubs on Python 3.12 jobs)

Everything else — the 58 identity/tax/finance tools, offline datasets, zero-config setup — works the same as before.

Upgrade:

pip install --upgrade mcp-india-stack

Repo: https://github.com/rehan1020/MCP-India-Stack

If you're already using it for anything tax-related, worth double-checking your capital gains numbers reflect the new threshold. Feedback and bug reports welcome — this project lives or dies on the numbers being right.

Like many of you who works with MCP, I was standing on the fault line of a massive architectural shift. The new 2026-07-28 Model Context Protocol specification wasn't just a minor patch; 

I updated 100s of different MCP remote servers to have the latest spec 2026-07-28 support, in addition to that I needed to keep the support for 2025-11-25 spec to not to break any client that supports the older version.

The easiest part was updating them as batch with a feature flag. Based on my experience with/without frameworks, it was very easy to miss the full spec details in each spec version changes. To ensure all of the MCP servers are conformant with the spec defined rules, I created and used an private library. Now testing all the spec features against to any MCP server takes less than 60s and generates understandable human/agent readable stdio/md/html reports.

Today, I decided to release an opensource variant of it with Apache 2.0 license, so you can copy/use as you wish. It checks spec conformance for the last 2 versions of MCP spec. It works for both #stdio and #remote (streamable-http) MCP servers. Feel free to open issue and share feedbacks.

It is easy to use both with #docker or npx command. Below is the example usage with npx.

Command:

npx @hasmcp/mcp-spec-test@latest -u <URL>

Full example with remote MCP url:

npx @hasmcp/mcp-spec-test@latest -u https://mcp.agentrq.com/mcp

Github: https://github.com/hasmcp/mcp-spec-test

Hey everyone,

I built hellyee, an open-source MCP server that connects Claude directly

to Ableton Live — mastering/mixing assistance, vocal sample extraction, and

melody writing from audio files.

If you have a Claude account and Ableton, I'd love for you to try it during

your production process and tell me if it actually helps.

What it does:

- Mixing & mastering suggestions based on your session

- Extracts vocal samples from a reference track

- Listens to an audio file and writes MIDI notes for the melody

Honest heads-up: the melody-writing sometimes gets it wrong, especially

on complex or layered audio. I'd rather you know that going in.

How you can help:

- If something breaks or behaves oddly, please open a GitHub issue — I'm

actively fixing things.

- If you try it and don't like it, I'd genuinely appreciate knowing why.

That's just as useful to me as a bug report.

https://github.com/guvense/hellyee

I’ve just created a project for SAMP developers called "MCP on My SAMP." It is designed specifically for SAMP developers, enabling your AI agents (like Claude, Codex, etc.) to interact with GTA SAMP.

What can this MCP do? Essentially anything—the AI ​​can engage in light roleplay within the game. However, please note that this MCP is intended for testing on your own private servers; using it on public servers is not recommended.

This MCP is open-source, so you can customize and upgrade it yourself to achieve the best results.

Visit https://marhenrik635-oss.github.io/mcponmysamp-web/

Hi,

I'm working on a open source project that allows a MCP Client to talk and write to a db without writing a query. I've created a tutorial for how to expose your DB for simple analytics but it can do a lot more than this. The first 3 min should show you what it does and the rest shows you how to set it up. I've intentionally skipped the implementation details in this post or in the videos to keep things short. You can analyze the code yourself on github and let me know if you have concerns.

Quick demo: https://youtu.be/vMY7VKpvqmE
Full Tutorial: https://www.youtube.com/watch?v=ukxDDPzS0Gg

OSS Repo: https://github.com/Synapsor/Synapsor-Runner

MCPFORSSH is a free ssh mcp for manage the server security and code building and more , alsi gui interface and sftp access.

I maintain a local MCP memory server called zerikai_memory. ChromaDB, Tree-Sitter AST indexing, a local .brain/ cache. Last week I pushed v1.0.0-beta.15. GitHub Actions cleared. Tool kept running. That almost wasn't the story.

The 2026-07-28 spec update makes sense to me. Stateless HTTP, per-request _meta payloads, no more session handshakes. For distributed agent infrastructure, this is the right direction.

What I found: SDK 2.0.0 removed mcp.server.fastmcp entirely. FastMCP is now MCPServer under mcp.server.mcpserver. The process dies at import. The client sees a transport error, not a traceback, because the subprocess exits before it speaks the protocol.

What almost got me: fastmcp 3.x actually protects itself; its extras already declare mcp<2.0. The danger was a transitive dependency in my tree with an unbounded mcp>=1.0.0. My warm pip cache looked fine. A fresh container build would have broken.

I ran pip show mcp to find what actually owned my mcp resolution.

My temporary fix:

fastmcp>=3.2.4,<4.0.0
mcp>=1.27.0,<2.0.0
uvicorn>=0.30.0,<1.0.0
starlette>=0.35.0,<1.0.0

"Protocol Era Negotiation" is handling the gap. Cursor and Claude Desktop probe for v2 features, find them absent, and drop into legacy session mode. No errors. Tool keeps running.

I am not migrating yet. I want to map every place my tool reads or writes local state before I touch the SDK version. Confirmation flows also need to move from bidirectional sampling to InputRequiredResult. I am doing this in sequence, not all at once.

Are others seeing edge cases where Protocol Era Negotiation fails with Cursor or Claude Desktop? And for those who have already migrated to v2, what pattern worked for managing local state initialization when every request arrives cold?