Reading Time: 12 minutes

MuleSoft’s Anypoint Platform now supports Model Context Protocol (MCP) in Beta, enabling organizations to seamlessly connect AI agents to enterprise systems and data, accelerating their journey to AI readiness.

Understanding Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. 

MCP is a new standard that enables LLMs and agent applications to communicate with each other and preexisting systems in a standardized way. While techniques like Retrieval-Augmented Generation (RAG) can help increase an LLM’s knowledge beyond its training data, MCP opens the door to external systems’ live data and executing actions. This is all accomplished through a standardized protocol layer. 

While traditional API styles like REST define ground rules and conventions, they also leave quite a bit of room for opinionated design choices. 

For instance, while one team at Acme Inc. might choose to model their REST APIs to closely resemble their entity model and define CRUD style operations, the team at Acme Airlines might choose to design it to minimize the number of requests. Therefore, one single PUT to the /reservation endpoint might not only change the reserved seats, but also add extra luggage and move the reservation to an entirely new flight.

Both approaches are valid, and developers have always desired this freedom. But in a world whereAPIs are now consumed by AI agents, those freedoms introduce some challenges:

  • Open semantics can make agent actions hard to govern and control
  • LLMs need access to the API specs, and they must be annotated with metadata the LLMs can reason with
  • Proliferation of custom solutions leads to complexity, which hurts scalability

The release of MuleSoft MCP Support (Beta) addresses these challenges, making it possible to write Mule applications that can act as both MCP server and client. In this guide, we’ll take you through the basics of getting started with MCP in Anypoint Platform. 

Build your first MCP server in 4 steps

Imagine we want to write an agent that creates purchase orders in SAP Concur. The agent needs to select from a list of approved vendors. In this custom implementation, each vendor is assigned with a “product category” mapped in a custom field called “Custom19”.

How can we feed an agent with a live list of vendors and their assigned categories while keeping the LLM decoupled from Concur and its nuances like authentication, custom field setup, and more?

For that, MCP defines the concept of tools, which are old-fashioned Remote Procedure Calls (RPC) that take a list of input arguments and produce a result.

Let’s see how to do this in four steps with Mule.

1. Create an MCP server configuration 

This configuration implements an MCP server using the SSE transport on top of an existing <http:listener-config>. With this, we not only get all of the configuration options of the Http connector, we can also write applications that serve both MCP and traditional APIs in the same port.

<http:listener-config name="HTTP_Listener_config">
	<http:listener-connection host="0.0.0.0" port="${https.port}" />
</http:listener-config>
	
<mcp:server-config name="MCP_Server"serverName="Mule MCP Server" serverVersion="1.0.0">
		<mcp:sse-server-connection listenerConfig="HTTP_Listener_config" sseEndpointPath="/sse" messagesPath="/message" />
</mcp:server-config>

2. Write a “Get Vendors” tool

Next, let’s write a tool that provides vendors:

<flow name="vendorsTool" >
 <mcp:tool-listener config-ref="MCP_Server" name="get-vendors"> (1)
	<mcp:description>Get all approved vendors</mcp:description> (2)
	<mcp:parameters-schema ><![CDATA[{ (3)
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {},
  "required": []
}]]></mcp:parameters-schema>
<mcp:responses> (4)
	<mcp:text-tool-response-content text="#[payload.^raw]" />
	</mcp:responses>
  </mcp:tool-listener>

  <flow-ref name="getTokenFlow" target="token"/>
  <mule-sap-concur-connector:get-vendors config-ref="SAP_Concur_Config"/>
  <ee:transform>
	<ee:message >
<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
payload.Vendor filter ($.Approved == "true") map {
	id: $.ID,
	name: $.VendorName,
	country: $.Country,
	city: $.City,
	productCategories: $.Custom19		
}
]]></ee:set-payload>
	</ee:message>
   </ee:transform>
</flow> 

Let’s break it down:

  • The tool is implemented through a flow triggered through the <mcp:tool-listener>.
  • The tool includes a description that allows the LLM to determine when to use it.
  • Being a very simple tool, this one doesn’t take any input arguments, but per MCP standards it still requires a JSON schema to define that.
  • The tool produces a text response, which in this case is the JSON produced by the flow. The connector also supports other types of responses like images and binary objects.

Then we move to the implementation, which uses the off-the-shelf SAP Concur connector to get the vendors, and a DataWeave (DW) transformation to filter by approved status and map the custom field to a product categories field.

This is enough for the LLM to access the live data in Concur and to select an appropriate vendor based on city, product category, and other criteria, without the need for additional custom logic.

3. Write a “Create purchase order” tool

Now, let’s write another tool that creates the purchase order:

<flow name="purchaseOrderTool">
  <mcp:tool-listener config-ref="MCP_Server" name="create-concur-purchase-order">
<mcp:description></mcp:description>
	<mcp:parameters-schema ><![CDATA[{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
  	"name": {
      "type": "string",
      "description": "The name for the purchase order"
    },
     "description": {
		"type": "string",
      	"description": "The purchase order description"
     },
     "vendorCode": {
     	"type": "string",
      	"description": "The code that identifies the vendor we're purchasing from"
     },
     "itemDescription": {
     	"type": "string",
      	"description": "The description of the item purchased in this order"
     },
     "price": {
     	"type": "number",
     	"description": "The purchase order monetary amount"     
	 },
	 "currency": {
	 	"type": "string",
	 	"description": "The currency code for the purchase order monetary amount"
    }
  },
  "required": ["name", "description", "vendorCode", "itemDescription", "price", "currency"]
}]]></mcp:parameters-schema>
  <mcp:responses >
<mcp:text-tool-response-content text="#['Created Order $(payload.PurchaseOrderNumber)']" />
  </mcp:responses>
</mcp:tool-listener>
		
<flow-ref name="getTokenFlow" target="token"/>
<mule-sap-concur-connector:create-purchase-order config-ref="SAP_Concur_Config">
	<mule-sap-concur-connector:create-purchase-order-request-data ><![CDATA[#[output application/json
---
{
	Name: payload.name,
	CurrencyCode: payload.currency,
	Description: payload.description,
	VendorCode: payload.vendorCode,
	LineItem: {
		Description: payload.itemDescription,
		ApprovedLineItemAmount: payload.price as String,
		TotalPrice: payload.price as String
	}
}]]]></mule-sap-concur-connector:create-purchase-order-request-data>
		</mule-sap-concur-connector:create-purchase-order>
	</flow>

This tool is a bit more complex. First, it does take input arguments defined in the JSON schema. Note how each of those arguments includes a natural language description. This is the magic sauce that will allow the LLM to map the values and consume it. 

The flow then uses the connector to create the order, and returns a single text line including the order’s ID. There’s no need for a formatted response.

4. Use it with an LLM

For this example, we connected these tools with Anthropic’s Claude and asked it about vendors in the Malaga area and then asked it to create the purchase order. Watch the product demo to see it in action.

MCP’s role in enabling intelligent agents

MuleSoft’s API-led architecture has allowed companies to unlock value and boost productivity by connecting disparate systems and data sources. MuleSoft MCP support multiplies the value of that investment by making those APIs accessible to LLMs and agents.

MCP is the bridge between the two worlds. MuleSoft’s API-led approach brings organization and structure to your APIs and integrations, while MCP unlocks those APIs to help enable new agentic experiences across any organization. 

Stay tuned as we continue to discuss how to secure your Mule-powered MCP servers.