Vibe-MCP

Inspiration

After building an early internal version of Codex sites at work using a github template, cloudflare workers and a cursor integration, I felt some nice validation when Codex sites did release. But something still didn't feel right, whilst my non-engineering colleagues were able to build tools and dashboards more easily things still felt like they weren't really taking advantage of the efficiency that AI brings us, and were just using AI to replicate our old methodologies. So I set about solving it in a way that was as seamless as Codex sites, but kept users in their chats and allowed them to use the power of their models to use whatever it is they needed building.

What it does

It's a single authenticated MCP server that dynamically routes users requests to their related tools, which are held as code snippets in a SQLite DB and executed in a Cloudflare dynamic worker. Tool execution takes advantage of the codemode theory where the model also writes JS to call the tools, to avoid context bloat of many tools being created. The models can then use that same MCP to write new tools, publish and grant access to them.

How we built it

It's entirely written with Codex using typescript, effect-ts and the Cloudflare Wrangler runtime as well as the Cloudflare infrastructure stack. It utilises all the cleverness available in the workers stack like dynamic workers for executing code snippets, durable objects for providing the tool projects with persistent storage, and codemode for getting round some of MCPs drawbacks.

The great thing about building an AI native tool is that you can just hook up codex to your local dev server MCP endpoint and get it to dogfood the app natively as it builds it, so the iterative feedback loop was really fast. It would make a change, call the newly changed areas of the app and see how they responded, then inspected the logs with openlogs.

Challenges we ran into

MCP is a fairly static interface, many clients implement it differently, getting the tools to become available to everyone who had access to them immediately was challenging. Most clients cache the list of tools on startup and then won't refresh them until a new chat is opened or the connector is refreshed. So to get round this instead of having each created tool be an actual MCP tool, it was broken down to have more generic tools like "build","catalog" and "execute" And these tools dynamically load whatever may be available to that specific authenticated user.

Accomplishments that we're proud of

Having a functioning product that actually allows users to build, share and use custom tools instantly. The product, while still a very early version accomplishes the core challenge it set out to solve.

What we learned

In it's current state this tool may not be the most efficient, there needs to be a more refined approach to returning instructions back to the client on how to use the tool and subsequent built tools. As a user they are likely to struggle more than usual if they run into issues with a service like this.

What's next for Vibe-MCP

Refinement mostly - ensuring the tool descriptions are refined enough to improve the reliability of the models creating the new tools and using existing tools. Connectors - Whilst CRUD operations between colleagues is great, this really becomes powerful once you add a connector layer, allowing the tools to search through linear tasks, message to slack etc. Background jobs - Whilst the CRON functionality does exist currently in the app it is relatively untested, expanding on it is important.

Built With

• cloudflare
• codemode
• d1
• dynamic-workers
• effect
• mcp