Feature Request: Model Context Protocol (MCP) Server Wrapper for Cloudflare Computer Workspaces

[FreshMindAI]

Proposal

Summary

We propose creating a new package, @cloudflare/computer-mcp, which wraps a Cloudflare Computer workspace and exposes its virtual filesystem and execution runtimes as a fully compliant Model Context Protocol (MCP) Server. This provides a standardized, plug-and-play interface for external AI agents, local clients, and orchestration frameworks to securely mount, query, and execute commands at the edge.

Background and motivation

Currently, interacting with a Cloudflare Computer workspace from an external orchestration framework requires writing custom Worker bindings, bespoke HTTP wrappers, and manual RPC translation layers. There is no standardized way for an external AI agent to securely utilize the Durable Object virtual filesystem.

As the AI industry converges on the Model Context Protocol (MCP) standard for connecting models to data sources and tools, the lack of an MCP interface isolates Cloudflare Computer from complex multi-agent workflows. When building human-in-the-loop agentic systems for the software development life cycle (SDLC) or enterprise data integration, developers need a standardized way to give agents a remote, sandboxed working directory.

Who is affected:

• Developers building multi-agent orchestrations and autonomous loops who need remote, secure execution environments without managing custom endpoints.
• Engineers integrating external enterprise SaaS systems or databases who need a standardized edge-compute layer for data processing.
• Users of local agentic clients (like Claude Desktop or Cursor) who want to execute tasks on Cloudflare's edge rather than consuming local machine resources.

Goals

• Native MCP Support: Expose Cloudflare Computer's core capabilities (cf_workspace_read_file, cf_workspace_write_file, cf_workspace_exec) as standardized MCP tools.
• Global Edge Execution: Allow agents running in centralized cloud regions to execute tools closer to the user or data source across Cloudflare's edge, drastically reducing tool-call latency.
• Unified State Management: Provide a stateful, centralized Durable Object "hub" for multi-agent workflows instead of fragmented local directories.
• Flexible Architecture: Support remote MCP architectures (SSE/HTTP) allowing the server to seamlessly integrate with cloud-native workflows.

Example

1. The MCP Server Setup (Worker Entrypoint)

The developer instantiates the MCP server inside their Worker, binding it to the Durable Object workspace:

import { Workspace } from "@cloudflare/computer";
import { MCPServer } from "@cloudflare/computer-mcp";

export class ComputerAgentDO {
  // Each agent instance gets its own isolated filesystem in SQLite
  workspace = new Workspace({ storage: this.state.storage });
  
  // Initializes the MCP server, exposing the workspace APIs as tools
  mcp = new MCPServer(this.workspace);
  
  async fetch(request: Request) {
    // Routes incoming remote MCP protocol requests (via SSE or Streamable HTTP)
    return this.mcp.handleRequest(request);
  }
}

---

Contribution & Next Steps

I am interested in helping implement this feature if the team agrees with the proposed direction.

If the maintainers are open to this design, I would be happy to draft a prototype and open a PR for @cloudflare/computer-mcp (or work within a community package under guidance).

cc @aron-cf — would love to hear your thoughts on whether this fits the roadmap for Cloudflare Computer!

[FreshMindAI]

The Agent Workflow (Client Side)
Once deployed, an external agent (e.g., using LangChain) can connect to the Worker's SSE endpoint and seamlessly call the edge workspace tools.

from mcp import ClientSession, SSEClientTransport
from langchain_core.agents import AgentExecutor

# 1. Connect the agent to the Cloudflare Worker via MCP over SSE
transport = SSEClientTransport(url="[https://my-agent.workers.dev/mcp/sse](https://my-agent.workers.dev/mcp/sse)")

async with ClientSession(transport) as session:
    await session.initialize()
    
    # 2. Retrieve the dynamically exposed tools from the Cloudflare DO
    tools = await session.list_tools()
    
    # tools will automatically include:
    # - cf_workspace_write_file
    # - cf_workspace_read_file
    # - cf_workspace_exec

    # 3. The LLM Agent decides to write a data processing script
    await session.call_tool("cf_workspace_write_file", {
        "path": "/workspace/process.js",
        "content": "console.log('Processing enterprise data payload...');"
    })

    # 4. The LLM Agent executes the script securely on the edge Isolate
    result = await session.call_tool("cf_workspace_exec", {
        "command": "node process.js",
        "backend": "isolate-javascript"
    })
    
    print(result.text) # "Processing enterprise data payload..."

[aron-cf]

Hey, @FreshMindAI thanks so much for the suggestion. This is something we're actively working on right now. There's an early example here, that will merge shortly. We'd love feedback if you want to check it out.

#28

We're looking into refining the example and integrating this as a first class entry-point shortly.

/cc @scuffi

[FreshMindAI]

That is amazing to hear, @aron-cf! Thank you for the quick response.

I just took a deep dive into @scuffi's work in PR #28. Using an adapter to bridge the existing Vercel createAITools output into the McpServer registry is a remarkably clean approach. I also love the strict timeout settlement logic to prevent hung shell commands from locking up the DO.

Regarding your note on integrating this as a first-class entry-point—I would love to build this out and submit the PR for it.

If the team is open to the help, my proposal is to extract the core adapter logic from computer-mcp.ts and formally export it (e.g., as @cloudflare/computer/mcp or similar). This way, developers can spin up a compliant server instantly without duplicating the bridging logic:

import { createMcpServer } from "@cloudflare/computer/mcp";

// Inside the DO...
this.mcp = createMcpServer(this.workspace, { defaultBackend: "worker-shell" });

Let me know if I have the green light to draft this PR! I can build it directly on top of the #28 branch or wait until it merges to main—whichever fits your workflow best.