MCP and the emerging enterprise AI OS layer

How MCP calls for a new kind of enterprise infrastructure for the upcoming synthetic workforce era.

The Model Context Protocol (MCP) represents the standardization of how AI models interact with tools and data. At its core, MCP defines two fundamental operations: tools/list and tools/call. Tools are provided by "MCP servers" that expose these two capabilities. MCP servers are registered to and called by "MCP Clients", generally agent loops used by end-users (think Claude Desktop, Cursor, Dust agents, ...):

• tools/list is used by the client to discover the tools provided by an MCP server configured by the user (e.g. an MCP server to interact with Github) and make them available to the agents it executes.
• tools/call is called by the agent to actually use a tool as part of its agentic loop (e.g. create a new issue on Github).

While this protocol is utterly trivial, the impact of its adoption on the AI ecosystem is profound. MCP creates a clean separation between the client (the agent loop running the model) and the capabilities (actions the model can take). In its purest form, the impact of MCP is that it untangles the client (agent loop) from the capabilities— which just makes sense.

This untangling means AI clients can seamlessly access tools without having to maintain hundreds of integrations, while service providers can make their capabilities available across any MCP-compatible platform with a unique implementation.

State of MCP

MCP is still in its infancy. There are in particular two important aspects on which the community is working:

• transport: most MCP clients only support "local" MCP servers, that is, servers running locally on the user machine and communicating over a local transport (stdio, or local HTTP + SSE). The protocol is working on standardizing remote transports to enable "remote" MCP servers.
• authorization: because MCP servers were first envisioned to be run locally, authentication and authorization was not a priority but now that the community is working on supporting remote MCP servers, authorization becomes a core concern of the protocol. The gist of the proposal is to allow OAuth flows as part of the initial interaction with an MCP server.

Most of these limitations can be circumvented by running local relay servers to remote servers or (very neat) exposing authorization as a tool of the server (the tool returning an URL to redirect the user to authorize them to the underlying service provider). This means that the community has been able to explore the future but MCP has yet to reach its full potential as it is progressively becoming usable by more and more users.

The work-context reality check

One could envision a world where all SaaS products expose themselves as MCP servers and users authorize their use (in their name) to local agents directly through OAuth. This works in a B2C context but, in a B2B/work context, there are still obvious limitations: companies can't allow employees to freely OAuth into any SaaS product because it's crucial to them to control how data flows, particularly in the era of LLMs. They need to understand and control which data goes to what provider in what context and they also need to control which actions can be executed by humans only, vs humans confirming machines actions, vs machines only. As a result it's pretty safe to hypothesize the opposite: companies will need control and visibility on which actions and what data is exposed (how and to which agents) to enable broad deployment of MCP actions within their infrastructure. Control will be a key enabler of the adoption of the protocol in B2B context.

Additionally, SaaS platforms existing keyword search capabilities don't fit agents' needs well. Unlike humans who intuitively have the context "that this document lives somewhere in that part of the system," agents require pre-embedding and semantic search to navigate organizational knowledge as effectively, explaining their pervasiveness today. That core capability for agents will hardly be replaced by MCP servers directly provided by SaaS products.

These two forces present in a B2B context, call for the emerging need for companies for an AI OS layer. A layer that has access to company context and actions and presents a permission system compatible with agents. This is what we call at Dust the "best MCP server for you company"—an MCP-centric way to say that we are building the best company AI OS. The opportunity here is massive and yet only perceived by the tip of the market, making it such an exciting domain to build in, especially as standards are still being defined.

Building the infrastructure layer for Superhuman capabilities

This layer will be the foundation on which superhuman work capabilities are built. Every AI product or solution will run through these pipes because as models improve, the level of abstraction of the tasks AI agents tackle will increase. As that happens, they will absolutely need the full context and tools of the company, beyond their vertical. Take coding as an example. Fixing an issue in a large codebase isn't just about writing good code—it's about having the context of design docs, slack chatter, coding rules, and company preferences. All future agents (including coding agents) will require access to the broad company context, and this will happen through MCP and coherent AI OSs adopted and rolled out by companies to enable safely sharing data and capabilities with the myriad of agents composing their new synthetic workforce. Lack of AI OSes would lead to a highly scattered permission model that would otherwise be impossible to maintain.

The path forward

Whether MCP wins the protocol war or not is, in a sense, irrelevant. Given the simplicity of the protocol there is definitely space for O(1) protocols to be supported by clients and servers alike. What matters is the will of the ecosystem towards standardization and MCP is clearly the most obvious candidate today. At Dust, as part of our ambition to emerge as the de-facto AI OS, we are actively working on the following:

• Supporting remote MCP servers to extend Dust agents: this consist in letting our users extend the capabilities of Dust agents by exposing remote MCP servers we connect to. This will happen in the context of our existing permission system which is thought from the ground-up for agents and humans collaborating together.
• Exposing Dust as an MCP server to external clients: this consists in exposing Dust agents or more granular tools to external MCP compatible clients (e.g. Claude desktop/code, Goose or Cursor) so that employees can fully leverage and act on their company while giving visibility and control to admins.

Our current work-in-progress versions of Dust as MCP server running in Cursor and Claude already feels like a brave new world. We are excited to ship it to our users very soon to demonstrate the true potential of agents that can understand company context and safely act on its state.