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...
For further actions, you may consider blocking this person and/or reporting abuse
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.