Universal Tools For AI
Announcing the extensible MCP Server: mcpx & mcp.run: its "app store" & registry for servlets. Search, install & manage secure & portable tools for AI, wherever it goes - desktop, mobile, edge, server, etc.
A few weeks ago, Anthropic announced the Model Context Protocol (MCP). They describe it as:
[...] a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments.
While this is an accurate depiction of its utility, I feel that it significantly undersells what there is yet to come from MCP and its implementers.
In my view, what Docker (containers) did to the world of cloud computing, MCP will do to the world of AI-enabled systems.
Both Docker and MCP provide machines with a standard way to encapsulate code, and instructions about how to run it. The point where these clearly diverge, (aside from being packaging technology vs. a protocol) is that AI applications are already finding their way into many more environments than where containers are optimal software packages.
AI deployment diversity has already surpassed that of the cloud. MCP gives us a way to deliver and integrate our software with AI systems everywhere!
AI applications, agents, and everything in-between need deterministic execution in order to achieve enriched capabilities beyond probabilistic outputs from today's models. A programmer can empower a model with deterministic execution by creating tools and supplying them to the model.
So, part of what we're announcing today is the concept of a portable Wasm servlet, an executable code artifact that is dynamically & securely installed into an MCP Server. These Wasm servlets intercept MCP Server calls and enable you to pack tons of new tools into a single MCP Server.
More on this below, but briefly: Wasm servlets are loaded into our extensible
MCP Server: mcpx, and are managed by the
corresponding registry and control plane: mcp.run.
If any of the predictions prove true about the impact of AI on software, then it is reasonable to expect a multitude of software to implement at least one side of this new protocol.
MCP Adoptionโ
Since the announcement, developers around the world have created and implemented MCP servers and clients at an astonishing pace; from simple calculators and web scrapers, to full integrations for platforms like Cloudflare and Browserbase, and to data sources like Obsidian and Notion.
Anthropic certainly had its flagship product, Claude Desktop, in mind as an MCP Client implementation, a beneficiary to access these new capabilities connecting it to the outside world. But, to go beyond their own interest, opening up the protocol has paved the way for many other MCP Client implementations to also leverage all the same Server implementations and share these incredible new capabilities.
So, whether you use Claude Desktop, Sourcegraph Cody, Continue.dev, or any other AI application implementing MCP, you can install an MCP Server and start working with these MCP tools from the comfort of a chat, IDE, etc.
Want to manage your Cloudflare Workers and Databases?
โ Install the Cloudflare MCP Server.
Want to automate browsing the web from Claude?
โ Install the Browserbase MCP Server.
Want to use your latest notes from your meetings and summarize a follow-up email?
โ Install the Obsidian MCP Server.
Exciting as this is, there is a bit of a low ceiling to hit when every new tool is an additional full-fledged MCP Server to download and spawn.
The Problemโ
Since every one of these MCP Servers is a standalone executable with complete system access on your precious local machine, security and resource management alarms should be sounding very loudly.
As the sprawl continues, every bit of code, every library, app, database and API
will have an MCP Server implementation. Executables may work when n is small,
you can keep track of what you've installed, you can update them, you can
observe them, you can review their code. But when n grows to something big,
10, 50, 100, 1000; what happens then?
The appetite for these tools is only going to increase, and at some point soon, things are going to get messy.
The Solutionโ
Today we're excited to share two new pieces of this MCP puzzle: mcpx (the
extensible, dynamically updatable MCP Server) and
mcp.run (a corresponding control plane and registry)
for MCP-compatible "servlets" (executable code that can be loaded into mcpx).
Together, these provide a secure, portable means of tool use, leveraging MCP
to remain open and broadly accessible. If you build your MCP Server as a
"servlet" on mcp.run, it will be usable in the most
contexts possible.
How?โ
All mcpx servlets are actually WebAssembly modules under the hood. This means
that they can run on any platform, on any operating system, processor, web
browser, or device. How long will it be until the first MCP Client application
is running on a mobile phone? At that point your native MCP Server
implementation becomes far less useful.
MCP Servers over HTTP / SSEโ
Can we call these tools via HTTP APIs? Yes, the protocol already specifies a transport to call MCP Servers over a network. But it's not implemented in Claude Desktop or any MCP Client I've come across. For now, you will likely be using the local transport, where both the MCP Client and Server are on your own device.
Installed servlets are ready to be called over the network. Soon you'll be able to call any servlet using that transport in addition to downloading & executing it locally.
Portabilityโ
One major differentiator and benefit to choosing mcp.run
and targeting your MCP servers to mcpx servlets is portability. AI
applications are going to live in every corner of the world, in all the systems
we interact with today. The tools these apps make calls to must be able to run
wherever they are needed - in many cases, fully local to the model or other core
AI application.
If you're working on an MCP Server, ask yourself if your current implementation can easily run inside a database? In a browser? In a web app? In a Cloudflare Worker? On an IoT device? On a mobile phone? mcp.run servlets can!
We're not far from seeing models and AI applications run in all those places too.
By publishing MCP servlets, you are future-proofing your work and ensuring that wherever AI goes, your tools can too.
mcpxโ
To solve the sprawling MCP Server problem, mcpx is instead a dynamic,
re-programmable server. You install it once, and then via
mcp.run you can install new tools without ever touching
the client configuration again.
We're calling the tools/prompts/resources (as defined by the protocol),
"servlets" which are managed and executed by mcpx. Any servlet installed to
mcpx is immediately available to use by any MCP Client, and can even be
discovered dynamically at runtime by a MCP Client.
You can think of mcpx kind of like npm or pip, and
mcp.run as the registry and control plane to manage your
servlets.
mcp.runโ
We all like to share, right? To share servlets, we need a place to keep them. mcp.run is a publishing destination for your MCP servlets. Today, your servlets are public, but soon we will have the ability to selectively assign access or keep them private at your discretion.
As mentioned above, currently servlets are installed locally and executed by a client on your machine. In the future, we plan on enabling servlets to run in more environments, such as expanding mcp.run to act as a serverless environment to remotely execute your tools and return the results over HTTP.
You may even be able to call them yourself, outside the context of an MCP Client as a webhook or general HTTP endpoint!
Early Accessโ
Last week, mcpx and mcp.run won Anthropic's MCP
Hackathon in San Francisco! This signaled to our team that we should add the
remaining polish and stability to take these components into production and
share them with you.
Today, we're inviting everyone to join us. So, please head to the
Quickstart page for instructions on how to install mcpx and start
installing and publishing servlets!
Here's a quick list of things you should try out:
- have Claude Desktop log you in to mcp.run
- get Claude to search for a tool in the registry (it will realize it needs new tools on its own!)
- install and configure a tool on mcp.run, then call it from Claude (no new MCP Server needed)
- publish a servlet, compiling your library or app to WebAssembly (reach out if you need help!)
As things are still very early, we expect you to hit rough edges here and there. Things are pretty streamlined, but please reach out if you run into anything too weird. Your feedback (good and bad) is welcomed and appreciated.
We're very excited about how MCP is going to impact software integration, and want to make it as widely adopted and supported as possible -- if you're interested in implementing MCP and need help, please reach out.