[ObnoxiousProxy]

I'm actually working on an MCP control plane and looking for anyone who might have a use case for this / would be down to chat about it. We're gonna release it open source once we polish it in the next few weeks. Would you be up to connect?

You can check out our super rough version here, been building it for the past two weeks: gateway.aci.dev

[CuriouslyC]

A MCP gateway is a useful tool, I have a prototype of something similar I built but I'm not super enthusiastic about working on it (bigger fish to fry). One thing I'd suggest is to have a meta-mcp that an agenct can query to search for the best tool for a given job, that it can then inject into its context. Currently we're all manually injecting tools but it's a pain in the ass, we tend to pollute context with tools agents don't need (which makes them worse at calling the tools they do) and whatnot.

What I was talking about here is different though. My agent (Smith) has an inversion of control architecture where rather than running as a process on a system and directly calling tools on that system, it emits intents to a queue, and an executor service that watches that queue and analyzes those intents, validates them, schedules them and emits results back to an async queue the agent is watching. This is more secure and easier to scale. This architecture could be built out to support safe multiple agents simultaneously driving your desktop pretty easily (from a conceptual standpoint, it's a lot of work to make it robust). I would be totally down to collaborate with someone on how they could build a system like this on top of my architecture.

[ObnoxiousProxy]

Our gateway lets team members bundle together configured MCPs into a unified MCP server with only two tools -- search and execute, basically a meta-mcp!

Very interesting! What kind of use cases are you using your agent (Smith) for? Is it primarily coding, or quite varied across the board?

[CuriouslyC]

Right now I'm 100% coding focused, that's the big show in terms of agents. Orchestrating current agent tools is clunky, they're low performance, they lack fine grained extensibility to really modify their behavior on a dynamic task based basis (CC's hooks are the "best" option and they're really weak), the security model around them is flawed, there's a laundry list of issues with them.

The agent itself is designed to be very general, every trace action has hooks that can transform the payload using custom javascript, so you can totally change the agent's behavior dynamically, and the system prompts are all composed from handlebars templates that you can mix/match. The security model makes it great for enterprise deployment because instead of installing agent software on systems or giving agents limited shell access to hosts, you install a small secure binary that basically never changes on hosts, and a single orchestrator service can be a control plane for your entire enterprise. Then every action your agent takes is linked into the same reactive distributed system, so you can trigger other actions based on it besides just fulfillment of intent.

[A4ET8a8uTh0_v2]

Interesting, for once 'Matrix's 'programs hacking programs' vision kinda starts to make some sense. Maybe it was really just way ahead of its time, but became popular for reasons similar to Cowboy Bepop ( different timeline, but familiar tech from 90s ).

[ManuelKiessling]

Do you see any useful synergies with something like https://mcp-as-a-service.com / https://github.com/orgs/dx-tooling/repositories?q=maas-

If yes, drop me a line, here or at [e-mail]

[block_dagger]

Looks interesting. Once an org configures their MCP servers on the gateway, what is the config process like for Cursor?

[ObnoxiousProxy]

Members can then bundle the various MCP servers together into a single unified MCP server that contains just two tools -- search and execute, so it doesn't overload context windows. The team members then get a remote MCP server URL for the unified MCP server bundle to bring into Cursor!