MCP Connector 0.1.0-BETA - Examples - Mule 4

These are some examples of how to use existing APIs to build agents using MCP Connector.

Create an MCP Server and Tools

These examples show you the process of creating an MCP server within your Mule app and defining two distinct tools that the MCP server will expose: one for retrieving a dynamic list of approved vendors with their product categories, and another for initiating the creation of purchase orders with specified details.

These examples illustrate the concept of MCP tools as invocable Remote Procedure Calls (RPCs).

Create the MCP Server Configuration

This example demonstrates how to configure an MCP server within your Mule application using the Server-Sent Events (SSE) transport. This configuration builds upon an existing HTTP Listener configuration, allowing your Mule instance to serve both MCP endpoints and traditional HTTP-based APIs simultaneously on the same port.

<http:listener-config name="HTTP_Listener_config">
	<http:listener-connection host="localhost" 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>xml

Write a Tool That Provides a List of Vendors

This example illustrates how to create an MCP tool that retrieves a dynamic list of approved vendors from an external system (in this case, SAP Concur). The example demonstrates how to use the <mcp:tool-listener> to define a callable tool and how to process the data to provide the agent with relevant vendor information, including their assigned product category from the Custom19 field.

<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>xml
Expand content

1	The tool is implemented through a Mule flow that’s triggered through the `<mcp:tool-listener>`.
2	The `<mcp:description>` provides a natural language explanation of the tool’s purpose, enabling the LLM to understand when to use it.
3	The `<mcp:parameters-schema>` defines the input arguments for the tool. In this simple example, it’s an empty JSON schema indicating no input parameters are required.
4	The `<mcp:responses>` section defines the output of the tool. Here, it specifies that the tool returns a text response containing the raw JSON payload produced by the flow.

This flow first retrieves a list of vendors from SAP Concur using the dedicated connector, then transforms the data using DataWeave to filter for approved vendors and map the relevant fields, including the product category from the custom field. The resulting JSON output provides the LLM with the necessary information to select a vendor.

Write a Tool That Creates the Purchase Order

This example demonstrates the creation of an MCP tool that allows an agent to initiate the creation of a purchase order in SAP Concur. The example highlights how to define input parameters for a tool using a JSON schema, including natural language descriptions for each parameter to help the LLM in understanding and populating the required information.

<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": "Name for the purchase order."
    },
     "description": {
		"type": "string",
      	"description": "Purchase order description."
     },
     "vendorCode": {
     	"type": "string",
      	"description": "Code that identifies the vendor."
     },
     "itemDescription": {
     	"type": "string",
      	"description": "Description of the item purchased in this order."
     },
     "price": {
     	"type": "number",
     	"description": "Monetary amount of the purchase order."
	 },
	 "currency": {
	 	"type": "string",
	 	"description": "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>xml
Expand content

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

Configure the MCP Client to Use Third-Party MCP Servers

The previous examples showed you how to write a tool that draws from existing Anypoint Connectors.

You can also use third-party MCP servers that are already implemented and ready to use. These examples show you how you can integrate your Mule applications with existing third-party MCP servers by configuring the MCP Client and using the Call Tool operation.

Here is an example of the MCP Client configured with the Google Maps MCP server deployed to Heroku:

<mcp:client-config name="MCP_Client" clientName="Mule MCP Connector" clientVersion="1.0.0">
		<mcp:sse-client-connection serverUrl="http://google-maps-mcp-sse-f5ebe64f8456.herokuapp.com">
		</mcp:sse-client-connection>
</mcp:client-config>xml

The ability to configure the client connection unlocks third-party MCP servers and opens the door to application networks.

After the MCP Client configuration is defined, you can use the Call tool (mcp-call-tool) operation to invoke specific tools exposed by the MCP server. The Call Tool operation dynamically retrieves the metadata (including available tools and their arguments) from the target MCP server, providing DataSense auto-completion within your Mule flow.

This example builds a simple weather tool to return the forecast at a particular coordinate:

<http:request-config basePath="/v1" name="HTTP_Request_configuration">
        <http:request-connection host="api.open-meteo.com" protocol="HTTPS"></http:request-connection>
    </http:request-config>

<flow name="getWeatherByCoordinatesToolFlow">
        <mcp:tool-listener config-ref="MCP_Server" name="get-weather-by-coordinates">
            <mcp:description>Provides the weather at given coordinates expressed as latitude and longitude></mcp:description>
            <mcp:parameters-schema><![CDATA[{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "latitude": {
      "type": "number",
      "description": "The latitude component of a location's coordinates"
    },
    "longitude": {
      "type": "number",
      "description": "The longitude component of a location's coordinates"
    }
  },
  "required": ["latitude", "longitude"]
}]]></mcp:parameters-schema>
            <mcp:responses>
				<mcp:text-tool-response-content text="#['Current temperature at location is $(payload.current.temperature_2m)']" />
            </mcp:responses>
        </mcp:tool-listener>
		<http:request config-ref="HTTP_Request_configuration" method="GET" path="/forecast">
            <http:query-params><![CDATA[#[output application/java
				---
				{
					latitude : payload.latitude,
					longitude : payload.longitude,
					current: 'temperature_2m'
				}]]]></http:query-params>
        </http:request>
    </flow>xml
Expand content

This tool uses the OpenMeteo API to return the forecast at a particular coordinate.

To handle weather lookups by address instead of coordinates, you can compose a new MCP tool that leverages the Google Maps MCP Server (configured earlier) to get coordinates and then uses the get-weather-by-coordinates tool (which internally calls the OpenMeteo API):

<flow name="getWeatherByAddressToolFlow">
  <mcp:tool-listener doc:name="Call Tool Listener" config-ref="MCP_Server" name="get-weather-by-address">
   <mcp:description>Provides the weather at a specific address</mcp:description>
  <mcp:parameters-schema ><![CDATA[{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "The address we want to learn the weather for"
    }
  },
  "required": ["address"]
}]]></mcp:parameters-schema>
    <mcp:responses >
    <mcp:text-tool-response-content text="#[payload.contents[0].text]" />
</mcp:responses>
 </mcp:tool-listener>
 <mcp:call-tool config-ref="MCP_GMaps_Client" toolName="maps_geocode">
	<mcp:arguments ><![CDATA[#[output application/java
---
{
	address: payload.address
}]]]>
</mcp:arguments>
 </mcp:call-tool>
 <mcp:call-tool config-ref="MCP_Client" toolName="get-weather-by-coordinates">
    <mcp:arguments ><![CDATA[#[output application/java
---
{
	latitude: read(payload.contents[0].text!, 'json').location.lat as Number,
	longitude: read(payload.contents[0].text!, 'json').location.lng as Number
}]]]>
</mcp:arguments>
 </mcp:call-tool>
</flow>xml
Expand content

In this example, the composition is written manually rather than feeding the LLM with all the tools individually because:

The LLM must have access to all the MCP servers.
The LLM must be able to securely authenticate to all of the MCP servers.
When the LLM is in charge of the orchestration, things like governance and tracing become complicated.

In some use cases, letting the LLM be in charge of the entire orchestration makes sense, but in others, a manual composition is preferable.