First Class MCP Agents and Tools

[Disturbing]

Context

Agent SDK is leveraging AI SDK’s Tools to enable LLMs to do custom tasks or operations. The Model Context Protocol (MCPs) is becoming a standard for how LLMs can communicate with each other for the same use cases that tools enable LLMs to discover functionality that it can invoke. We should consider enabling Agents created with the Agent SDK to both:

• Expose itself as an MCP so that others can utilize the agent through this protocol.
• Define a standard for bootstrapping MCPs as Tools for the agent to connect to and leverage in its operations.

Definition of a tool in MCP

{
  name: string;          // Unique identifier for the tool
  description?: string;  // Human-readable description
  inputSchema: {         // JSON Schema for the tool's parameters
    type: "object",
    properties: { ... }  // Tool-specific parameters
  }
}

Definition of an Tools using AI SDK

tools: {
 name: tool({
      description: 'Get the weather in a location',
      parameters: // Zod or JSON Schema of tool's parameters 
      execute: // Args from params above + History of messages
  }),
  ...
}

Standard Server Sent Events MCP Example
We already have a solution from cloudflare with Workers MCP which allows servers to serve API endpoints as standard MCP Servers via JSDdoc standard which makes it intuitive for users to not have to handle bootstrapping MCP Servers.

export class ExampleWorkerMCP extends WorkerEntrypoint<Env> {
  /**
   * Generates a random number. This is extra random because it had to travel all the way to
   * your nearest Cloudflare PoP to be calculated which... something something lava lamps?
   *
   * @return {string} A message containing a super duper random number
   * */
  async getRandomNumber() {
    return `Your random number is ${Math.random()}`
  }
  // ...etc
}

Problem

Agent SDK needs a way to bootstrap itself as an MCP Server and easily depend on existing MCP Servers as Tools to perform its desired functionality. This will enable Cloudflare Agents to participate in the growing MCP standard, decouple reusable Agent Tools that can be reused across multiple agents, help support multi-tenancy and the separation/security of state.

Coupling agents with mandatory tools, such as Email or Scheduling, may increase the complexity of each feature to consider a stateful component and multi-tenancy. Additionally, these features may not need to be used at all and we should consider how we want optional tools to be considered, configured and leveraged in the ecosystem of Cloudflare AI Agents. Cloudflare Agent developers should be able to easily configure what functionality is needed by registering and configuring MCPs as Tools. Contributors to this project should have a clear pathway on how to contribute custom functionality for the ecosytem.

Possible solutions

The following options are unbiased in their order of importance and represent potential solutions that may help solve the above problem.

MCP Server Bootstrapping

Leveraging the available tools array created from the server and setup a Stdio and/or SSE Transport service to accept incoming messages and their responses.

Assuming MCP typescript-sdk potentially can work on Cloudflare Workers, a standard service can iterate through the given tools of the Agent and register them as follows:

// Create an MCP server sudo code
const server = new McpServer({
  name: "Demo",
  version: "1.0.0"
});

// Register all tools that are used within the agent sdk.
for (tool : tools) {
  server.tool(tool);
}

// Should really be a fetch example for cloudflare workers...
app.get("/sse", (req, res) => {
  transport = new SSEServerTransport("/messages", res);
  server.connect(transport);
});

MCP Client Bootstrapping

Create a standard Tool that takes a live MCP Server SSE Endpoint for indexing and generating its available commands. MCP servers are providing three different types of potential endpoints to help understand how to use it:

• Prompts: A list of example templates of messages that the LLM can use
• Resources: The ability to query data (ie: a database, PDF, images, etc.) to acquire information.
• Tools: Is functionality (Create, Update, Delete) that the MCP server does for the LLM.

Due to AI SDK that we're using today does not supporting Prompts and Resources, we can convert Prompts to help enrich descriptions for the Tools and Resources. The Resources can be applied as Tools in the AI SDK standard, and Tools will convert seamlessly since they share the same schema today.

Optimizing the description size is debatable to save costs and adhere to context windows.

export class McpToolFactory {

   function async new(url: String): Tools[] {
       // Query & Index MCP server Prompts, 
       // Query & Index Resource Endpoints
       // Query & Index Tools

       return // Generate tools for reading Resources & 
   }
}

export class McpTool implements Tool {
  private tool: Tool
  constructor(tool: Tool) {
    this.tool = tool;
  }

  // Wrap Tool Defintions
 function async execute (... args} => ({
   result: client.callTool(tool.Name, args);
 })
}

Configuration Option A: Config File

Create a configuration file that gets parsed that includes a list of MCP servers

• Pros:
  • Clear file of mcp server definitions that exposes the feature and functionality to developers in a clear way
  • Allow for future proofing flexibility and options of how the MCP servers are used
  • Able to support Stdio, Sse and potentially custom transport handlers.
• Cons
  • Separate file that needs to be considered and parsed.
  • Multiple flavors (ts, jsonc, toml) formats to be considered

Example mcpconfig.json:

{
  "servers": [
    {"url":"http://localhost:8080/sse"},
    {"command":"./server","args":["--option","value"]}
  }
}

Configuration Option B: Environment Variables

To keep things simple and use existing wrangler and .env files, we could consider a comma separated array for a list of MCP servers to bootstrap.

• Pro
  • Uses standard files that exist already
• Con
  • Not able to easily support Stdio Transport

Example .env file:

MCP_SERVERS=http://localhost:8080/sse,http://agent.coop.com/sse

Configuration Option C: Statically Typed

You can consider statically registering MCP Servers in Typescript. This may make it harder to quickly update

• Pros:
  • Flexibility in dynamically creating tools for MCP servers on demand
• Cons:
  • Not easily able to config per-environment setups.

const mcpToolFactory = new McpToolFactory();
const tool = mcpToolFactory.createTool(“http://localhost:8080/sse”)

Summary

Allowing MCP servers to enable the flexibility of potentially stateless agents and decoupling state for multi-tenancy. Users or folks who leverage Cloudflare Platform for Platforms can consider deploying individually configured and contextually bound agents per tenant which improves overall security and potentially even optimizes LLMs to perform better for their owner’s needs. D1, Vectorize, KV and other serverless cloud native primitives that Cloudflare provides us allows this solution to scale cost effectively versus having to consider optimizing tenants and states within single stores or instances.

Thoughts?

All is welcomed!

• Feedback on the problem itself - is its something we all care about?
• Feedback or questions about the options listed here.
• New proposed solutions.

[elithrar]

A couple of early pieces of feedback:

Due to AI SDK that we're using today does not supporting Prompts and Resources…

The agents SDK doesn’t depend on the AI SDK directly: you can use MCP directly or write your own. The example application agents-starter does because it’s meant to be a practical example and the AI SDK is widely used.

Assuming MCP typescript-sdk potentially can work on Cloudflare Workers

It does! You should try it!

Agent SDK needs a way to bootstrap itself as an MCP Server and easily depend on existing MCP Servers as Tools to perform its desired functionality

I don’t quite get that in this RFC. Can you show a more complete example of the following? Specifically taking into account:

• Not all Agents will want to expose APIs over MCP, since not all Agents may need to communicate over MCP
• Some Agents will want to just act as an MCP client - how will this work? How do we make a client (that may talk to multiple servers!) feel part of the framework without adding a ton of default complexity?
• MCP server: some Agents may wish to expose themselves over MCP, and/or as a “multiplexer” (an MCP server that combined others/chains calls).

What’s in here right now isn’t really fleshed out and I would suggest prototyping something to test it out. Start narrow!

[Disturbing]

I'll get to prototyping it for more real code examples @elithrar

But it would be helpful, as a project, to align on the vision of how MCPs or even functionality should exist. For example, in the roadmap we have email, and we already have things like schedules baked into the agent. I would imagine those as MCPs / Tools themselves and my interests is most definitely helping create an OSS serverless tool catalog as things continue to move forward.

Next steps for me would be:

1. Show example option above on how to configure MCPs
2. Show how to optionally expose agent as an MCP
3. Showcase how something like the "Schedular" can be an MCP or Tool (both options - ideally configurable by choice)