MCP: A Common Interface for AI Tools

Model Context Protocol (MCP) is an open standard that gives LLMs a universal way to talk to services and applications. Anthropic announced it in late November 2024, and the analogy the project site uses is apt: think of MCP as a USB-C port for AI applications — a standardized connection between AI models and the data sources or tools they need.

Architecturally, MCP splits into a few roles:

  • MCP hosts: the programs (like Claude) where models operate and interact with services
  • MCP clients: components inside the host that initiate requests and talk to servers
  • MCP servers: lightweight programs that expose the capabilities of a given service
  • Local data sources: files, databases, and local services the server can reach
  • Remote services: external internet-connected systems accessed via APIs

The workflow is straightforward: if you ask Claude to post to a Slack channel, Slack's MCP server advertises tools like "list channels," "post messages," and "reply to thread." Once the client knows what tools exist, it can invoke them and finish your request.

From One Sentence to a Deployed Worker

Pairing MCP with Cloudflare Workers makes this concrete. A user can ask Claude to deploy a Cloudflare Worker, and the assistant — through an MCP server — can handle the whole operation, producing a live site from a single request. That same pattern extends well beyond deployment: build your own MCP server on Workers and your users can drive your application directly from an LLM.

The workers-mcp tooling does the translation between your code and the MCP standard, so you don't have to maintain that plumbing yourself. After you scaffold a Worker and install the tooling, the template handles the hard parts. The ProxyToSelf logic wires your Worker to respond as an MCP server without complex routing or schema definitions.

The template also leans on JSDoc for tool definition. A method like sayHello is annotated with comments describing what it does, its arguments, and its return value. Those comments aren't just for human readers — they generate the documentation the AI assistant can understand.

Adding Real Capabilities: Image Generation

The payoff comes when you add custom functionality. Instead of standing up server infrastructure and defining request schemas, you write the code. To give Claude image generation via Workers AI, update the Worker and redeploy:

import { WorkerEntrypoint } from 'cloudflare:workers'
import { ProxyToSelf } from 'workers-mcp'

export default class ClaudeImagegen extends WorkerEntrypoint<Env> {
 /**
   * Generate an image using the flux-1-schnell model.
   * @param prompt {string} A text description of the image you want to generate.
   * @param steps {number} The number of diffusion steps; higher values can improve quality but take longer.
   */
  async generateImage(prompt: string, steps: number): Promise<string> {
    const response = await this.env.AI.run('@cf/black-forest-labs/flux-1-schnell', {
      prompt,
      steps,
    });
        // Convert from base64 string
        const binaryString = atob(response.image);
        // Create byte representation
        const img = Uint8Array.from(binaryString, (m) => m.codePointAt(0)!);
        
        return new Response(img, {
          headers: {
            'Content-Type': 'image/jpeg',
          },
        });
      }
  /**
   * @ignore
   */
  async fetch(request: Request): Promise<Response> {
    return new ProxyToSelf(this).fetch(request)
  }
}

Once the Worker is live, Claude can use the new tool. The interaction stays conversational: "Hey! Can you create an image of a lava lamp wall that lives in San Francisco?"

That pattern opens up a range of possibilities:

  • Have Claude send follow-up emails using Email Routing
  • Capture and share website previews via Browser Automation
  • Persist sessions or user data with Durable Objects
  • Query and update a D1 database
  • Call any existing Worker directly

The Complexity It Removes

Building an MCP server without Cloudflare's tooling means initializing a server instance, defining explicit schemas for every interaction, handling request routing, formatting responses, writing action handlers, and configuring communication. A reference implementation of that approach requires a substantial amount of code:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({ name: "example-server", version: "1.0.0" }, {
  capabilities: { resources: {} }
});

server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [{ uri: "file:///example.txt", name: "Example Resource" }]
  };
});

server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  if (request.params.uri === "file:///example.txt") {
    return {
      contents: [{
        uri: "file:///example.txt",
        mimeType: "text/plain",
        text: "This is the content of the example resource."
      }]
    };
  }
  throw new Error("Resource not found");
});

const transport = new StdioServerTransport();
await server.connect(transport);

It works, but it demands familiarity with the protocol and a lot of setup for each action. On Workers, that boilerplate disappears — the platform handles the MCP overhead so you can spin up a server and focus on the capabilities themselves. It's part of a broader effort to simplify developer workflows, and it gives LLM-based agents a much lower-friction path to interacting with real services.