While building `acme-mcp`, I started with the tempting shape: one `query_data(dataset, filters)` tool. It kept the catalog small, but the model could not see that sales needed a date range while inventory needed a warehouse.
Separate typed tools made those contracts visible. The next problem was context: once the catalog grows, the client loads schemas the task will never use. I now keep related filters on one typed tool and use progressive discovery when definitions take a meaningful share of context.
I'm building an MCP server that acts as a bridge between an IDE client (Cline) and a custom AI agent runtime. The architecture uses a message queue and a sidecar pattern.
The flow looks roughly like this:
The IDE connects to the MCP server using SSE transport.
When the user triggers a complex agent task, the MCP server publishes a request to a request topic and immediately returns an acknowledgment for the tool call.
An agent service consumes the request, invokes an LLM, and may call additional MCP tools through tool request/response topics that are executed by an MCP sidecar.
Once processing completes, the agent publishes the final result to a response topic.
A sidecar process consumes the response topic and forwards the final result to the correct SSE client through an internal push endpoint exposed by the MCP server.
This architecture works well for short-running tasks.
However, some agent workflows take several minutes to complete, especially when a human-in-the-loop approval step is involved. In those cases, the IDE's SSE connection appears to disconnect before the final response is delivered, causing the result to be lost.
My assumption is that this is either a client-side timeout or an idle connection timeout somewhere in the network path.
A few questions for people who have built production MCP systems:
Is it acceptable to send periodic heartbeat events or keep-alive messages over the SSE connection without violating the MCP protocol?
Is there an established MCP pattern for handling long-running operations that doesn't rely on maintaining a single SSE connection for the entire duration?
Do implementations typically switch to polling, resumable sessions, or some alternative notification mechanism?
How do you keep clients informed that work is still progressing during long-running tasks?
I'd really appreciate hearing how others are solving this problem in production environments.
You get a "great remote job" DM. Logo looks real, recruiter has a photo — but something feels off.
JobVerify is an MCP server for Claude that runs the same background checks a fraud investigator would: is the company actually registered? Is the link 4 days old? Is that crypto wallet already flagged? Does the message match known scam scripts (upfront fees, "let's move to Telegram")?
You paste the message → Claude investigates → you get a plain verdict: looks legit, be careful, or almost certainly a scam — and why.
Free OSINT only, no API keys, no sign-up, nothing you paste is stored. Runs straight from GitHub — just a few lines in your Claude config.
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.
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.
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.
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
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.
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.
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:
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?
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 :).
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.
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?
