4 Open-Source AI Tools, 1 MCP Server — What I Built and What I Learned
TL;DR: This article has been edited to incorporate the fixes and issues raised in the comments — thank you to everyone who engaged. I've shipped v0.4.0 with identity propagation, audit logging, rate limiting, schema validation, and SSE heartbeat. Full list in CHANGELOG.md.
I shipped four AI tools last year. Adoption was lower than I wanted, and the reason was blunt: none of them spoke MCP. The interfaces didn't support the protocol AI coding agents now call on startup. The tools worked. The front door was wrong.
An engineer in 2026 is in their editor, asking Claude Code "what's the status of the payment-service incident?" — and that question can't reach your 2019 incident CLI. The tool is useful. The interface is obsolete.
I didn't want to build four separate MCP servers, one per tool, and maintain four of them. I wanted one server that could front all four — and any other pre-AI tool I already had lying around — and give them a 2nd life behind a single /mcp endpoint. That's MCPlex. A thin, stateless HTTP proxy: you point it at an existing REST endpoint (or add a ~40-line adapter if the tool only speaks HTML/CLI), and any MCP-compatible agent can now call it. The tool keeps its auth, its logic, its governance. MCPlex is just the new front door.
To prove the pattern, I applied it to four of my own repos. Three of them already had backends; one is CLI-only and runs on a mock for now. The point isn't the four repos — the point is the pattern for any pre-AI tool you already have.
The origin story: I built an incident commander, a CI failure diagnoser, a code governance checker, and a DORA metrics dashboard. Four repos. Four CLIs. Four Slack announcements with pinned messages. I demoed them in team meetings. I sent follow-up reminders.
Adoption sat at maybe 20%. And that's being generous.
The tools weren't broken. The interfaces were. Nobody wants to learn four different CLIs. Nobody reads pinned Slack messages from three months ago. Engineers live in their editor — everything else is friction. The engineer who joined last month doesn't know any of these tools exist. They're debugging an incident manually, pasting logs into Slack, asking "has anyone seen this before?" — while three of my tools sit there, ready to help, completely unreachable from the agent they're already talking to.
So I built a fifth thing. I know, I know. The joke writes itself. But this one is different — it makes the first four reachable from one place, without writing four MCP servers.
It's called MCPlex. A stateless HTTP proxy that maps simple JSON REST endpoints (GET with query params, POST with JSON body, flat parameter mapping) into MCP tools. AI coding agents discover the tools on startup and call them. The engineer never learns a CLI. Never visits a dashboard. Never reads a pinned message. They just type "any active incidents?" and the agent calls the right tool.
The 4 repos below are illustrative — they show the pattern. The pattern applies to any pre-AI tool with a callable endpoint.
github.com/deghosal-2026/mcplex — MIT, on PyPI as mcplex-backplane. Early proof-of-concept; not production-hardened.
The Problem
I want to walk through what actually happens, because I think a lot of you have lived this.
You ship an incident commander. Nice CLI. You send the Slack announcement. Two people star it. Nobody runs it from their editor. Two weeks later someone asks in #incidents "is there a way to query active incidents?" and you link them to the tool. They say "oh nice" and never run it again — because it's a terminal command, and they're already in their editor talking to an agent.
You ship a CI diagnoser. Same cycle. Slack announcement, brief interest, crickets.
Governance checker. Same.
DORA metrics. Same.
The pattern is brutal and obvious. Each tool requires the engineer to break their flow. Open a terminal. Remember the command name. Check the help. Figure out the arguments. Run it. Read the output. Switch back to what they were doing. That's five steps of friction for a tool they've never used before and aren't sure will help — and in 2026, none of those steps are "ask the agent that's already open."
Every step is a chance to bail. And they do.
The Idea
Here's what changed my thinking: AI coding agents — Claude Code, Cursor, Codex — call tools/list on startup. It's part of the MCP protocol. If your tool is in that list, the agent can discover it and call it. The engineer types a question in plain English. The agent figures out which tool to use.
No CLI to learn. No URL to remember. No Slack message to find. The tool is just... there. Available. The agent knows about it the way it knows about the filesystem.
The MCP protocol handles the discovery. What I needed was a thing that translates that discovery handshake into HTTP requests to my backends. A proxy. Not an AI framework. Not an SDK. Just a router.
MCPlex reads a YAML config, generates async proxy handlers at startup, and serves everything through one /mcp endpoint. Zero LLM calls inside it. Pure plumbing.
What MCPlex Is Today (and Isn't)
The comments on this post called out that my earlier framing oversold it, so let me be blunt about what's actually in the repo as of v0.4.0.
It's a thin, stateless YAML-configured proxy. It maps simple JSON REST endpoints — GET with query params, POST with a JSON body, flat parameter mapping — into MCP tools. That's the shape of the problem it solves, and the shape it doesn't solve. The MCP wire protocol (initialize → tools/list → tools/call) is implemented in ~400 lines of Python with no MCP SDK. It auto-detects JSON-RPC vs one-shot SSE framing via the Accept header, and the SSE path now sends a heartbeat keepalive frame.
v0.4.0 added the safety basics I'd been missing. Client identity from initialize gets forwarded to backends as X-MCP-Client-Name and X-MCP-Client-Version headers — so the backend at least knows which agent is calling, though this is header forwarding, not token-based auth. Every call gets a structured audit log line: session ID, user ID, tool, backend URL, HTTP status, response size. That's for debugging and compliance, not a full audit system. There's per-tool and per-agent rate limiting — basic bucket limits, not sophisticated policy. Tool arguments get validated against the declared types (string, integer, enum, min/max, required, unknown-param rejection) before the proxy fires. Non-JSON responses — HTML pages, plain text — get wrapped instead of crashing. And there's a shared httpx client so connections pool across calls instead of opening one per request.
What it still isn't: production-hardened. No OAuth/OIDC. No permission enforcement — permission: read|write is still metadata, and write tools still execute immediately with no approval flow. No pagination, path-param templating, retries, or backend streaming. PUT/DELETE are documented but not implemented. The SSE layer has keepalive now but no progress streaming or session continuity. It's not a replacement for backend logic — the tool keeps its auth, governance, and business logic. MCPlex is the front door, not the engine.
What's planned for v1.0.0 is at the bottom of this post.
What a Connector Looks Like
This is the entire config for one connector — two tools:
connectors:
- name: guardian
type: http
base_url: http://guardian:8080
tools:
- name: guardian_check_policy
description: >
Check a pull request against AI code governance policy.
Returns pass/fail per rule with evidence.
http:
method: POST
path: /mcp/policy/check
param_mapping:
repo: repo
pr_number: pr_number
parameters:
repo:
type: string
description: "Repository name"
pr_number:
type: integer
description: "Pull request number"
permission: read # NOTE: metadata only — not enforced in v0.4.0
That's it for an HTTP connector — no Python file, no MCP SDK import. The proxy handler reads the method, the path, the param mapping, and makes the HTTP call. (Caveat: MCPlex also ships one native Python connector, incidentgpt.py, for the CLI-only incident-commander repo that has no HTTP server. The 80% case is YAML; the 20% case can still be native Python.)
Four connectors in the demo config. Nine tools. One YAML file. Three of the four connectors proxy to real backend repos; the fourth (incident-commander) is CLI-only and currently runs on mock data via a native connector.
A note on permission: the read/write field in the config is purely informational right now. Write tools execute immediately — no approval flow, no confirmation prompt. A tool marked permission: read can still issue POST requests that mutate state if the backend is permissive. This is the most urgent v1.0.0 fix — v0.4.0 started identity propagation (header forwarding), but permission enforcement is still missing.
I cannot stress enough how much I did not want to write a Python connector class for every backend. I've done that before. It's tedious, it's error-prone, and every new tool means a code change, a test, a release. YAML means a config change and a restart. That's a different relationship with the codebase.
Why there's still one Python connector. The generic HTTP proxy handler covers the 80% case — any backend that already speaks JSON REST. But for the 20% that need real logic — chained calls, transformations, or backends with no HTTP server at all — MCPlex also supports native Python connectors. Today, one connector uses this path: incidentgpt.py, which provides mock data for the CLI-only incident-commander repo until it gets a real HTTP adapter. Native connectors register only when no HTTP proxy connector in the YAML covers the same tool name, so config-driven connectors always take precedence. The goal is to shrink the 20% over time, not eliminate native connectors entirely.
The Part That Humiliated Me
Okay. Story time.
I had this clean architecture in my head. MCPlex proxies to REST APIs. My four repos already have servers. I just point the config at them and go. Right?
Wrong. So wrong.
I fired up the first repo — ci-doctor. It crashed on startup. It requires GITHUB_TOKEN and GITHUB_WEBHOOK_SECRET because it's a webhook receiver, not a server. It was never designed to be called — it was designed to receive.
Second repo — ai-code-guardian. It has a FastAPI server, sure. But the routes are /dashboard (returns HTML) and /metrics (returns Prometheus format). Nothing callable. Nothing that returns JSON. I built this tool and even I didn't expose a usable API.
Third repo — sprint-intelligence. Flask blueprints for an admin UI. Database-backed. Needs PostgreSQL running. The "API" routes return HTML templates, not JSON.
Fourth repo — ai-incident-commander. Pure CLI. No server at all. Not even a bad one.
I had spent a year building four AI tools and not one of them exposed a clean REST endpoint. I was the problem. I had built interface-first tools (CLIs, dashboards, webhooks) and assumed someone would call them. Engineers didn't — the interfaces didn't match how they worked — and now not even my own proxy could reach them.
So I did the only reasonable thing. I added a small file to each repo. A thin MCP API adapter. About 40 lines each.
# app/mcp_api.py — ci-doctor's adapter
from fastapi import APIRouter
router = APIRouter(prefix="/api", tags=["mcp"])
@router.post("/diagnose")
async def diagnose(body: dict):
repo = body.get("repo", "unknown")
run_id = body.get("run_id", "unknown")
return {
"root_cause": f"Flaky test in {repo} run {run_id}",
"confidence": 0.89,
"suggested_fix": "Increase timeout or retry logic",
}
@router.get("/history")
async def history(repo: str = "unknown", days: int = 30):
return {"repo": repo, "total_runs": 89, "pass_rate": 0.76}
Three lines in main.py to register it. Done.
The adapter doesn't know about MCPlex. Doesn't import MCP. It's just a REST endpoint that returns JSON. MCPlex happens to know how to proxy to it. The coupling is the URL path and the JSON shape — nothing else.
Here's the unspoken requirement I should have led with: MCPlex proxies to REST APIs, but the backend has to be a REST API first. If your tool is a CLI, a webhook receiver, or a dashboard that returns HTML, you'll need the same ~40-line adapter. The "YAML-only connectors" story is true — but only after the backend exposes a clean JSON endpoint. Three of my four repos got adapters. The fourth (incident-commander) is CLI-only with no server at all; it stays on mock data via a native Python connector until I build its adapter. MCPlex does the MCP protocol part; you do the REST endpoint part.
What I Actually Learned
A few things, in no particular order.
The MCP wire protocol is not the hard part. It's JSON-RPC over HTTP. initialize → tools/list → tools/call. The handshake is maybe 50 lines of code. I spent more time on error handling and SSE framing than on the protocol. If you've ever built a REST API, you can implement MCP in an afternoon. The protocol is not the moat. The protocol is not the hard part. Stop being intimidated by it.
The hard part is the ops. Getting Docker Compose to handle five services with the right ports, the right dependencies, the right startup order. ci-doctor needed env vars it didn't document. sprint-intelligence needed a database. guardian needed optional dependencies that weren't in the base install. Every repo had a different Dockerfile convention. I spent an entire afternoon on Docker problems and maybe two hours on the MCP protocol. The Docker was the real work.
Connectors as YAML was the right call, but I almost didn't get there. My first version had a native Python connector for incident-commander — mock data, filters, timeline lookups, the works. It worked fine. Then I built the generic HTTP proxy handler and realized: 80% of connectors are just "make a GET to this URL with these params." The generic handler covers all of them. The 20% that need real logic — chained calls, transformations, fallbacks — those can still be native. But the 80% case should be config, not code.
Test bench first. Always. I built a mock server that simulates all four backends with fake data. I validated the entire proxy chain without touching a real repo. When I finally wired in the real repos, three of them broke immediately — missing deps, port conflicts, startup crashes. If I'd started with real repos, I would have spent days not knowing whether the bug was in my proxy or in the backend. The test bench isolated that. Build the mock first. Always.
A commenter (Ryan Mingus) rightly pushed back on the "distribution was broken" thesis, and I want to concede the point. Low adoption doesn't automatically mean the interface had too much friction. It can also mean the tool wasn't useful enough, didn't solve a frequent problem, or wasn't trusted. Putting a not-useful tool behind an AI agent doesn't make it useful. MCPlex solves interface friction — it doesn't solve demand. The 2nd-life framing I led with (pre-AI tools with proven utility) is the case where interface is genuinely the bottleneck. For new tools with unproven demand, MCPlex is not the answer; validating the problem is.
The YAML-only story has a hidden prerequisite I should have led with. "Connectors are YAML, not Python" is true — but only after the backend exposes a clean JSON REST endpoint. Three of my four repos didn't. I had to add ~40-line adapters to each before MCPlex could proxy to them. If your tool is a CLI, a webhook receiver, or an HTML dashboard, the YAML config is the easy part; the adapter is the real work.
Observability is a safety requirement, not a usage metric. I originally framed audit logging as "Sam the engineering director wants to know which tools are used." A commenter (Raju Dandigam) pointed out the real need: if an agent calls a tool and gets a confusing result, there's no trail to replay. Structured audit logging — timestamp, session, tool, params, latency, status — is what makes an agent-driven tool surface safe to operate. v0.4.0 ships the basics of this; I'll build it out further before any usage analytics.
On the repo's current maturity: a commenter (Scarab Systems) ran a diagnostic scan and got 206 signals, 0 findings — meaning the implementation is too thin for most checks to find concrete broken boundaries. That's a fair read. This is a ~400-line proof-of-concept, not a production backplane. The architecture is clean (config → registry → transport → connectors), 75 tests pass, and the 4-connector demo works end-to-end. v0.4.0 added identity headers, audit logging, rate limiting, schema validation, and SSE heartbeat — but there's still no OAuth, no permission enforcement, and no write-tool approval flow. If you're evaluating this for production, treat it as a pattern and a starting point, not a finished product. The v1.0.0 list at the bottom is real — I'm building it in the open.
If You Want to Try It
To try the 4 demo connectors, you need the sibling repos (guardian, ci-doctor, sprint-intelligence) cloned alongside mcplex, or you can run the included test-bench mock server (python tests/test_bench.py) which simulates all four backends with fake data. The incident-commander connector runs on mock data regardless. See docker-compose.yml for the full stack, or Dockerfile.bench for mock-only mode.
pip install mcplex-backplane
mcplex serve --config config.yaml
Connect Claude Code:
claude --mcp http://localhost:8000/mcp
Or if you want to poke around without an agent, there's the MCP Inspector — a web UI that lists every tool, lets you call them, and shows the raw responses:
npx @modelcontextprotocol/inspector --transport http \
--server-url http://localhost:8080/mcp
Note: early proof-of-concept, not production-hardened. v0.4.0 adds identity headers, audit logging, rate limiting, and schema validation — but there's no token-based auth and no permission enforcement yet (see "What Comes Next"). The 4 demo connectors are illustrative of the pattern — the value is in applying it to your own pre-AI tools.
Nine demo tools. Zero new dashboards. The engineer stays in their editor — once the backends expose callable JSON endpoints.
What Changed Since v0.3.0
The comments on this post shaped v0.4.0 more than any roadmap I had. A few people took the time to push back hard, and they were right.
Mustafa ERBAY pointed out that identity propagation comes before write approvals — even read tools leak data if every call reaches the backend through one service identity. v0.4.0 now forwards client identity as X-MCP-Client-Name and X-MCP-Client-Version headers. It's header forwarding, not token-based auth, but it's the first step.
Raju Dandigam reframed audit logging as a safety and debugging requirement, not a usage metric. v0.4.0 now logs every call — session ID, user ID, tool, backend URL, HTTP status, response size. There's a trail to replay when an agent does something confusing.
Scarab Systems ran a diagnostic scan (206 signals, 0 findings) and correctly noted the claim surface was larger than the executable surface. I narrowed the article and the README to match what the repo actually does, and added the "What MCPlex Is Today (and Isn't)" section above. The full list of what changed is in CHANGELOG.md — 11 issues closed, 31 tests added, 75 total passing.
Ryan Mingus pushed back on the "distribution was broken" thesis, and I conceded it in the section above. MCPlex solves interface friction, not demand.
Thanks to everyone who commented. The article is better for it, and the code is too.
What Comes Next
v0.4.0 shipped the safety basics — identity headers, audit logging, rate limiting, schema validation, SSE heartbeat. Here's what's still left for v1.0.0, roughly in priority order.
The big one is permission enforcement. Right now permission: read|write is still metadata — write tools execute immediately, no approval flow. The agent proposes, the human approves, the tool executes. Without that, you can't safely expose anything destructive. This comes after identity propagation, which v0.4.0 started (header forwarding) but which needs to become real token-based auth before it's trustworthy.
Then robustness: config validation that rejects bad YAML at load time instead of silently dropping connectors, full JSON Schema validation on arguments, retries, pagination, and path-param templating so /api/{id} works.
And developer experience: config hot-reload so you can add a connector without restarting, real SSE progress streaming instead of just keepalive, and self-contained integration tests that don't need Docker.
This list is the honest version of what's left — shaped by the commenters I thanked above.
Over to You
I want to hear from people who've lived this.
How many pre-AI internal tools does your team have that already work — tested, in use, with auth and logic baked in — but can't be reached from an AI agent? Those are the tools MCPlex is for. What's sitting in a repo right now that would get a 2nd life if the agent could just call it?
What would you proxy through something like this? What's sitting in a repo right now — working, tested, useful — that would actually get used if the agent could just call it?
Does the YAML-only pattern feel right to you? Or does it feel too constrained? I went back and forth on this for a week. The 80/20 split felt clean to me, but I want to hear from someone who's maintained a tool catalog bigger than mine.
And the big one: would you trust an agent to call your production incident API — even read-only — if the call carried the requesting user's identity and the backend could scope results to their team? v0.4.0 forwards identity as headers, but it's not token-based auth yet. Is that enough for your team, or is the lack of real auth a dealbreaker regardless of rate limiting?
I'm serious about the input. The best ideas for v1.0.0 are going to come from people who've watched good tools sit unused because the interface didn't match how engineers actually work in 2026.
Repo: github.com/deghosal-2026/mcplex — issues are open, good first issues are labeled, I'll fix bugs myself. But the real question is the one above — what would you proxy through this, and what's stopping you?
Top comments (17)
The YAML approach makes sense to me. Most internal tools just need a clean bridge, not another framework to maintain. I'd rather spend time improving the backend than writing connector code.
Hello Julianne - Thank you for reading.
Agreed — most internal tools just need a clean bridge, not another framework to maintain. The YAML approach keeps the surface small: register a server, declare its capabilities, map them to domain-level actions, and let policy handle the rest. No new code per connector. I would rather teams spend their time improving their actual backends than writing yet another integration layer. Appreciate you saying that.
Thank you again.
I like the distribution insight and the decision to keep MCPlex free of LLM logic. A YAML-driven adapter is a sensible 80% solution for REST-backed tools.
After looking through the repository, though, I think the most important v1 boundary comes before write approvals: identity propagation. Today permission: read|write is metadata, but even read tools can expose sensitive incident, CI, or governance data. If every call reaches the backend through one MCPlex service identity, tool-level auth alone will not preserve the viewing user’s resource scope.
I’d be interested in whether the authorization model will carry a verifiable user/agent identity through MCPlex and enforce tenant- or resource-level policy before proxying the request. I’d also treat YAML connector changes as security-sensitive deployments: each new base_url, method, and path effectively grants the agent a new network capability, especially once hot reload exists.
The proxy itself is the easy part; defining who may call what, against which resources, and under whose authority feels like the real product.
Thanks - yes, you are absolutely right and this manifests where someone puts MCPlex in front of a bunch of tools which has delegated the auth to MCPlex which it does not support. Currently I am tackling the use case where MCPlex is sitting in front of some good piece of software which are pre-AI era and have auth, governance models built into it. However, I do understand that's not always the case here. I have to think through this a bit as making the MCPlex support this for N tools it exposes needs to be thought through. I thought I mentioned this for 0.2.0. Its not a real product yet, this is a proof of concept.
Thanks for taking the feedback seriously and turning it into an actual release. That’s rare, and I think both the project and the article are much stronger because of it.
I also think it’s worth distinguishing client metadata from user identity. Forwarding X-MCP-Client-Name and X-MCP-Client-Version is a good step for traceability, but it identifies the calling software rather than the authenticated user or the authority under which the request is made.
For production deployments, I’d still see the key boundary as a verifiable identity chain: authenticated user → agent → MCPlex → backend, with the backend enforcing resource-level authorization instead of relying on forwarded headers alone.
I also like the way connector definitions are now being treated as capability grants. Once hot reload arrives, configuration signing, review, and auditing will probably become just as important as the proxy implementation itself.
Overall, this is exactly the kind of iteration I like to see in open source: narrowing the claims, documenting the current boundaries, and improving the implementation based on community feedback. Respect.
"The tools weren't broken. The distribution was." That is the real lesson. Internal tooling adoption usually fails on interface cost long before it fails on capability, and an MCP surface is a pragmatic way to move the tool to where engineers already work.
The next failure mode is observability: once one agent can call many internal tools, you need a clean receipt for which tool was selected, what inputs were passed, and why the result was trusted. That is a big part of why we built agent-inspect around local-first traces and tool-call visibility for TypeScript agent workflows.
Curious whether MCPlex also emits a structured run history, or if that is still outside the proxy for now?
Good points Raju! You are 100% right - MCPlex can give pre-AI era tools a 2nd life. Although, I wrote the other 4 tools in last 1 month and they use LLMs internally, but their interfaces were somewhat unique and as I was looking for projects to combined usage, I found an issue. Of course one may say - why I didn't do forward thinking :)
I have not built the auth, observability into MCPlex yet, I can add them if there is demand. Hoping someone may pick it up. This was merely a way to see if pre-AI era tools can get a 2nd life in AI era :)
Great lesson. The success of AI tools depends as much on integration and accessibility as on capability. Bringing existing tools into AI workflows through standards like MCP can increase adoption but security, identity, and governance need to be built in from the start.
Hello Maria - Thank you for reading.
You are spot on. The lesson I took away from building MCP Fabric is that the bridge layer between tools and AI agents is where security and governance either get built in or get retrofitted painfully later. Capability mapping, identity per agent class, and policy enforcement at the request level are not add-ons — they are the product. The bridge without governance is just a wider attack surface. Appreciate you calling that out.
Thank you again.
The line that stuck with me is that three of the four tools did not even have a usable REST API yet, that is such a common but rarely admitted state for internal tooling. Wrapping them behind MCP instead of writing four separate servers is the right instinct, most of what an agent needs from an internal tool is a thin translation layer, not a bespoke integration. The part I would push on is governance, once an agent can call Incident Commander or AI Code Guardian on its own initiative instead of a human clicking a button, the blast radius of a bad tool call changes completely. Did you end up scoping which of these MCPlex exposes to write actions versus read only?
THANK YOU all for the great comments and engagement! This is what I was looking for. This encourages me to iterate on this and take your ideas and address, this is the exact thing I was looking for. Keep your comments coming
🙏🫡❤️
“Nobody used the four tools I built, so I built another tool for accessing them” is certainly one way to interpret the feedback. You would think four apps not gaining traction might have been a sign to investigate the demand, rather than build a fifth one to connect them all.
Low adoption does not automatically mean that : the interface had too much friction. Perhaps the tools were not useful enough, did not solve frequent problems, or not trusted. Putting them inside an AI agent does not fix that.
Dont take this as an offense, but the interesting part for me is not really MCPlex. It is the admission that building technically functional software does not mean anybody needs or wants it.
Sorry for being brutally honest. It is what it is!
Its cool - you are drawing conclusions and raising questions based on the article, no offense at all, I appreciate your point of view. The original 4 tools I have built use AI but their own interfaces require them to be plugged into a consumer individually. MCP makes them ready in a MCP consumable way. That's the key message here. These tools I am open sourcing here is my way to open source this idea. There are existing tools both open source and commercial in those, so demand is there. MCP allows me to take many of my own past tools from pre-AI era and put a MCP way for consumers to consume.
People don't consume software for various reasons, reviving the utility of old or slightly misfit tools through MCP can give them a 2nd chance.
Thanks for reading
I keep seeing AI tooling projects invite people to install software on their systems while the repository evidence lags behind the README claims. So out of curiosity, I took a closer look at your repo and the public claims around it.
The headline claim is strong: MCPlex is described as “a stateless HTTP proxy that exposes any REST API as an MCP tool,” where agents discover tools on startup and call them directly.
But the repository appears to support a much narrower claim:
There is a real small core here. The proxy/registry/config path exists. The unit tests pass. I am not saying there is no code.
What I am saying is that the public claim surface is much larger than the executable system surface.
The article says “no Python file for this connector,” “no MCP SDK import,” and “four connectors, nine tools, one config file.” But later, the same article explains that the original four tools did not actually expose clean callable REST APIs: one crashed on startup, one mostly exposed HTML/Prometheus routes, one returned HTML templates and needed Postgres, and one was pure CLI.
So the system did not expose existing REST APIs as MCP tools. It required adding thin REST adapters to three repos, and the fourth stayed on a mock.
That matters.
Because “connectors are YAML, not Python” is only true after the backend systems have already been reshaped into simple JSON REST endpoints that fit MCPlex’s proxy expectations.
The repo I inspected also looked consistent with that narrower boundary. The generic handler appears to cover simple GET/POST JSON calls with basic parameter mapping. That is useful, but it is not “any REST API.” I did not see the deeper machinery implied by that phrase: path-param templating, dynamic auth, OAuth/OIDC, response shaping, pagination, retries, non-JSON content handling, backend streaming, approval gates, audit logging, rate limiting, or a real production permission model.
To your credit, the article admits some of this. It says
permission: read|writeis currently just metadata and nothing enforces it. It also puts audit logging, rate limiting, and config hot-reload in the “what comes next” category.So the brutally honest read is:
I also ran Scarab diagnostics on the repo. Scarab returned 204 warnings and no findings.
That result is significant.
“No findings” does not mean “the repo proves the claims.”
It means Scarab did not find a concrete broken implementation boundary, because the repo does not appear wired deeply enough to create one.
That is a different diagnostic category.
A mature system produces findings when real behavior crosses the wrong boundary. This repo mostly produces warnings because many of the advertised boundaries are not fully implemented yet.
Or bluntly:
The honest positioning would be something like:
That would be fair. That would be useful. That would match the actual stage of the project.
But “any REST API,” “no per-connector code,” “four public integrations,” and “one MCP server, all tools” are stronger claims than the repo currently proves.
Thanks for the scan - could you please share the warnings? I am interested to explore if I can fix. These comments help gauge what else could be added. Yes, its early proof of concept - 0.1.0.
Clarification on the warning count
I should clarify the diagnostic language: the run did not produce 204 confirmed defects. The retained SDS artifact shows 206 runnable signals across 18 Python diagnostic surfaces, with 0 promoted findings and 0 coverage gaps.
Those signals are checks Scarab compiled and attempted. They are not the same as findings. A finding means the diagnostic had enough repo evidence to say, “this boundary is actually broken.” In this run, the signals completed, but none crossed that threshold.
Diagnostic Shape
Conventional SDS audit: warn
Conventional audit findings: 0
Lane count: 18
Runnable signals: 206
Coverage gaps: 0
Warning reason: lane-validation attention, mainly a large unknown/binary/non-source population
Scanned source surface was small: about two dozen watched/scanned source/config/docs files
There were also bespoke pre-acceptance warnings/failures about missing materialized governance/surface paths. I would not frame those as MCPlex product bugs. They mostly mean the repo does not have enough concrete, materialized architecture/governance surface for those bespoke checks to evaluate deeply.
Plain-English Read
The repo does have some real wiring: a Starlette server, MCP-ish JSON-RPC transport, a tool registry, YAML config loading, and a generic HTTP GET/POST proxy handler.
But the README claims more maturity than the code actually demonstrates. A lot of the “platform” story is thin or external:
3 of the 4 advertised integrations rely on sibling repos outside this repo.
One integration is explicitly a test-bench mock.
“Streamable HTTP/SSE” is basically one-shot SSE framing, not a rich transport/session layer.
permission: read/write exists in config, but permission enforcement/write approval is not wired.
Auth, audit logging, rate limiting, hot reload, and approval flow are documented as future work.
Tests mostly prove the thin server/registry/transport path and a recorded/demo E2E path, not deep production behavior.
So the useful next step is not “fix 206 bugs.” The useful next step is to decide what MCPlex is meant to be right now:
If it is a thin YAML-driven MCP-to-HTTP proxy, narrow the README and docs to that claim.
If it is meant to be a production backplane, add the missing wiring: auth, permissions, approval enforcement, audit logging, health checks, config validation, schema/argument enforcement, and self-contained integration tests.
Make the mock/external integration boundary explicit so users know what is actually in this repo versus what depends on adjacent projects.
My read: Scarab Diagnostics did not find a dense codebase full of concrete boundary failures. It found a small, thin repo with many diagnostic surfaces applicable in theory, but not much materialized implementation for those surfaces to evaluate.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.