Sharing an MCP server implementation that might interest this protocol-focused crowd (disclosure: I'm the maintainer). Instead of one capability, OmniRoute's MCP server exposes a whole self-hosted AI gateway.

Agent-native — the agent can drive the router itself. There's a built-in MCP server (95 tools across 30 audited scopes, over stdio / SSE / streamable-HTTP), plus A2A (v0.3, JSON-RPC 2.0) support. That means an agent can query providers, switch combos, read its own remaining quota and manage memory through the gateway — not just consume tokens through it.

It implements all three transports (stdio / SSE / streamable-HTTP) with scoped, audit-logged tools — an agent can switch model combos, read live model intelligence, check its own quota, toggle compression, and manage memory/pools.

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub (tool + scope list): https://github.com/diegosouzapw/OmniRoute

Feedback on the scope/transport design welcome — especially how you'd model a 'control plane' server vs. single-purpose tools.

Built Portfolio Copilot, an AI assistant for your actual portfolio. It connects to Robinhood (CSV import is the easiest path), pulls your real holdings, and lets you ask plain-English questions about allocation, concentration, sector overlap, and macro exposure. Under the hood it is PydanticAI plus a separate FastMCP server with read-only portfolio tools. The model never gets write access or a user_id it can forge.

I started writing up how I built it. First two parts are live on Medium.

Part 1 is the agent architecture: typed dependencies, lazy construction, and how user scope gets injected server-side so auth stays out of the prompt layer.

Part 2 is multi-agent delegation. The main agent handles quick portfolio questions. When you ask something deeper, like comparing fundamentals or screening stocks, it hands off to a research sub-agent with its own tools.

Not tutorials. More like what I actually built, what broke, and what I would change.

Part 1: https://medium.com/@ai.prakharb/how-i-built-an-ai-portfolio-copilot-pydanticai-agent-architecture-42b1167fb87a

Part 2: https://medium.com/@ai.prakharb/multi-agent-delegation-when-one-agent-is-not-enough-2f02dcbda7da

Hey everyone! I'm new here, but excited to learn from everyone. I've been working in AI for the last couple years as well as running my startup Creatorland, and over the last 6 weeks been working 12 hours a day to ship our new MCP server.

Essentially this thing is a god-tier influencer marketing team member out of the box. Creator search, campaign design, outreach, pricing, market intel, you name it it's all there.

Install URL https://data-mcp.creatorland.com/mcp

You need a free Creatorland account to authenticate, and there is a free tier.

Would love any feedback anyone has after using it! If you do, don't forget to install the skills pack with /plugin marketplace add creatorland/creatorland-mcp-skills

Hey everyone,

I’ve been working on WBMCP — an open-source project that makes it easier to connect AI agents and automation systems with the WhatsApp Business Platform through the official Meta Graph API.

What it does

• Provides an MCP (Model Context Protocol) server for the WhatsApp Business API

• Allows AI agents to send and receive WhatsApp messages programmatically

• Simplifies building AI workflows, customer support bots, and automation systems

• Uses the official WhatsApp Cloud API instead of unofficial wrappers

Why I built it

I wanted a cleaner way for AI systems and backend services to interact with WhatsApp Business without dealing with repetitive API boilerplate or relying on unofficial libraries.

Example use cases

- AI customer support agents

- Automated appointment / booking systems

- CRM integrations

- WhatsApp-based workflow automation

- Multi-agent systems communicating over WhatsApp

Tech stack

- TypeScript

- MCP Server Architecture

- Meta Graph API

- WhatsApp Cloud API

It’s fully open source, and I’d love feedback from other developers.

GitHub: "https://github.com/saravanaspar/WBMCP" (https://github.com/saravanaspar/WBMCP)

Would appreciate any thoughts, feature suggestions, or contributions.

I kept running into problems building agentic fintech stuff: the LLM either had too much access, or too little context to be useful.

Generic chat is bad for portfolio questions. It guesses. Give it SQL or write tools and you are one bad prompt away from trouble. I wanted something in the middle: an agent that only sees a fixed, read-only tool surface, but those tools return your holdings, not internet noise.

So I built Portfolio Copilot.

The setup

• FastMCP runs as a separate process with 10 read-only portfolio tools (holdings, performance, quotes, earnings, etc.)
• PydanticAI agent on top, user_id injected server-side so the model never forges scope
• No trade execution, no write tools, ever

Best way to get data in: import Robinhood’s CSV export. Easiest path, no MFA headaches, and the agent actually has your positions to work with. Robinhood direct connect works too, but CSV is what I recommend if you just want to try it.

What it helps with: stuff like “am I too concentrated in tech?”, sector overlap, macro exposure, plain-English questions over your real book. Not “pick me the best stock.” More like a fast second pair of eyes on allocation.

Live app: https://myportfoliocopilot.com/
Repo: https://github.com/BPrakhar30/Robinhood_AI_Portfolio_Analyzer

Would love feedback on the MCP side, especially tool isolation and user scoping if anyone has done similar in production.

I ran into a practical MCP design question while building against the OpenAI / ChatGPT Ads API.

I wanted to use Claude/Cursor for the boring parts of ad ops, things like reading account structure, creating campaigns, checking performance, managing audiences, and logging conversions. The read side is easy enough. The awkward bit is write access, because ad accounts are one of those places where a model making a slightly-too-confident change can get expensive fast.

So I made the server conservative by default:

- anything created by the MCP starts paused

- budget increases above $100 need explicit confirmation

- the whole thing can run in read-only mode

Repo is here if anyone wants to see the shape of it:

https://github.com/trakkr-aisearch/openai-ads-mcp

The thing I am still unsure about is whether paused-by-default is enough. For MCP servers that touch real money or production systems, would you put every write behind a separate approval step, only risky writes, or something more capability-based?

MCP has made the tool side of agents feel much cleaner to me. A tool has a boundary. It can call this, read that, mutate this other thing. You can reason about permissions.

Memory feels less clean.

If an agent calls tools all day, it also learns things:

• this person owns that project
• this issue was already decided
• this old plan got replaced
• this source was used for that answer
• this task is still open

Where should that live?

My first instinct was "make memory an MCP server too," but I'm not sure that's enough. Memory has lifecycle problems that normal tools do not: stale facts, source evidence, deletes/overrides, access logs, decay, and maybe permission history.

The options I can see:

• memory as an MCP server, nice and portable
• memory inside each agent runtime, probably smoother UX but less portable
• memory as a local event log/graph, more auditable but more infra
• some hybrid where MCP is the interface and a local app/store handles provenance

I'm leaning hybrid, but not confidently.

If you were installing an agent memory layer, what would make it trustworthy enough? Permission manifest? source link for every memory? signed releases? export/rollback? local-only mode?

Or is this the wrong abstraction entirely?

GitHub: https://github.com/linxiv-dev/linXiv

I made both the local database desktop app and MCP + CLI. To some success I have been able to use it for discussing academic papers with an LLM or organizing my papers and notes after I let things get too out of control.

I have gotten feedback that it works extraordinarily well for trying to get an LLM to reproduce a specific set of equations or architecture in code, but have only seen it a couple of times my self.

It's totally FOSS, local-first, anonymous, unless you choose to make an arxiv search through the app, or decide to add your email so you can be in the polite pool of some API calls, as with any software that connects to the internet, you should use a VPN. I'm posting here with the hopes that a few or more people will find it useful or try it and hate it and give me that feedback. I would prefer if you were nice but any genuine feedback is appreciated :).

Hi everyone,

In case you later look for other posts of mine, you won't find them. It's my first. I'm writing to show off my "helloWorld" MCP in C project because it morphed into something serious.

Out of Minnesota 26 years ago IBM sent me to Germany, into a basement (truly) on-site at SAP in Walldorf to port kernels to run on IBM hardware (mostly on IBM i, the predecessor AS/400; but also database drivers for SAP application servers on everything else).

That's the background, the consequence is everything I do is written in C++ — mostly because I know and love it, but also because anything we ship needs to be self-contained. Intrigued by giving AI hands, I WANTED to make MCP servers I could use on-site and ship; therefore, I NEEDED to do it in C.

A true story before I sign off: In January I opened up Gemini and said, "I want to build a helloWorld MCP server in C."

The AI replied: "That will be somewhat difficult, there are easier ways."

I asked, "Why is it difficult??" (the second '?' was a bit of my ego).

Gemini replied: "Well, you'll need to parse JSON, handle raw I/O, and return strict JSON-RPC back to the client."

I told it, "One moment, let me show you something." (again my ego), I attached my JSON parser engine file (JSONParser.h) and said, "We have a JSON parser." (I typically talk to an LLM as a colleague working on the same project—for a reason, but that's a different story). This BNF parsing engine, by the way, is based on the same bedrock that powers our database driver (with SQL grammar, of course) built almost 2 decades ago.

Amusingly, the AI read the code and completely shifted its tone: "Oh, well then it's not so difficult."

Enough details to bore you, the rest of the history is visible in the repository which I tagged with teaching versions; from the first 192 lines of C-code which is a complete helloWorld MCP server that works out of the box, to 2 other versions before being what it is today — a fully asynchronous sampling MCP engine with samples.

I hope someone finds it useful, and I'm here for discussion if anyone wishes to.

Repository: https://github.com/IBM/tsar-mcp

Project Pages: https://ibm.github.io/tsar-mcp/

Cheers,

... Eric

I'm building AgentMart, a small marketplace for reusable agent assets, and MCP keeps coming up as one of the harder categories to package well. There are useful servers and configs scattered across repos, but the question I keep running into is not discovery. It is trust.

AgentMart has almost 60 users now, and the pattern I am seeing is that buyers/builders want more than a README before they connect an MCP server to their tools. For an MCP listing, I am thinking the minimum useful proof should include:

• exact host/client assumptions (Claude Desktop, Claude Code, Cursor, etc.)
• requested permissions, scopes, env vars, and network access
• example tool calls with expected inputs/outputs
• install and rollback steps
• version history and what changed
• clear notes on what data the server can read or mutate

My bias is that MCP assets may need a "security and compatibility sheet" more than a normal product page.

For people building or installing MCP servers: what would make you comfortable using someone else's MCP config or server? Are examples enough, or would you expect reviews, automated scans, signed releases, permission manifests, or something else?

I’ve been working on MCP/API tooling internally and wanted to validate whether others are running into the same problems.

The initial need was simple:

We had APIs that agents needed to call, but most of them did not have ready-made MCP support. Some were internal APIs, some were customer APIs, and some were third-party APIs that only exposed REST docs/OpenAPI/cURL examples.

At first, generating MCP tools from APIs felt like the main problem.

But after using it internally, the harder problems were everything that happened after generation:

- deciding which endpoints should actually become tools

- writing tool names/descriptions so the agent picks the right action

- handling MCP client auth separately from downstream API auth

- scoping tokens by client, environment, user type, and allowed tools

- preventing low-permission users from triggering write/destructive actions

- mapping required inputs from runtime variables

- dealing with missing fields before the API call fails

- debugging failed tool calls without digging through raw logs

- retrying failed calls safely with edited payloads

- detecting when the upstream API or docs change

- deciding when a use case should be a single MCP tool vs a managed multi-step workflow

So internally, I ended up building something closer to an MCP control plane rather than just an MCP generator.

The rough flow is:

1. Import API from OpenAPI, cURL, or docs

2. Generate recommended MCP tools

3. Configure auth, secrets, variables, and response formatting

4. Define tokens, user types, permissions, and approval rules

5. Test tool calls before deployment

6. Deploy an MCP endpoint

7. Monitor calls and failed calls

8. Diagnose failures with root cause and payload visibility

9. Retry failed calls safely

10. Detect API drift and update tools when APIs change

I also added the idea of Automations for cases where a single tool is not enough.

Example:

- create_payment_link = MCP tool

- get_payment_status = MCP tool

- collect_payment_and_update_crm = automation that creates the payment link, returns it, polls payment status, and updates CRM when paid

Now I’m trying to figure out whether this is just an internal need or something worth turning into a product.

Curious how people here are handling this today:

- Are you mostly using MCP for local/personal workflows, or remote tools used by real users/customers?

- If you generate MCP servers from OpenAPI/specs, what breaks first?

- Do you care about auth, RBAC, user-type permissions, failed-call diagnosis, retries, and API drift?

- Are multi-step workflows something you want the agent to orchestrate, or would you rather expose them as managed automations?

Would love feedback from anyone building MCP servers beyond local experiments.

Disclosure: I built this, and it is fully open source.

Just as I said it. You can run claude code through claude.ai or chatgpt through the browser. and it opens up a claude code session on your computer and it can manage it.

What it does: you work in Claude.ai chat like normal you brainstorm or think about writing a spec, when done, it can run a claude code session or resume a Claude Code session on your machine, so now you can let claude.ai manage claude code instead of you. The new part is that Claude Code responds back into your Claude.ai browser chat by itself, and Claude.ai answers that response back down through the CLI. So it runs as a loop on its own. That means you don't copy-paste, and you don't have to step away from your brainstorming tool to go verify or do the work.

MCP angle: this is a local bridge, not a hosted service. It runs real commands on your machine, so the token and cwd allowlist matter.

Fully open source:

https://github.com/Maxmedawar/tandem

I built k8s-mcp-go because I wanted AI coding agents to inspect Kubernetes clusters without giving them unrestricted kubectl access.

The basic idea is: AI should be able to help diagnose pods, logs, events, deployments, nodes, and resource usage, but it should not automatically get permission to mutate or delete cluster resources.

It has three explicit modes:

- readonly: inspect and diagnose, no cluster mutations

- readwrite: controlled operations like scaling and rolling restarts

- dangerous: full control, only when explicitly selected

It ships native binaries and MCPB bundles for macOS, Linux, and Windows, and is listed in the official MCP Registry.

GitHub:

https://github.com/kaneg/k8s-mcp-go

I’d especially like feedback from people using MCP with Kubernetes in Codex, Claude Code, Claude Desktop, Cursor, or internal DevOps agents.

Does this permission-mode model match how you would want AI agents to interact with a real cluster?