Managing Runtime Fabric with the Anypoint MCP

The Anypoint MCP (Model Context Protocol) server exposes a set of AI-callable tools that connect Cursor directly to Anypoint Platform. For Runtime Fabric (RTF), this means the full cluster lifecycle (creation, application deployment, upgrades, and teardown) can be triggered from a natural language prompt inside your IDE.

This guide covers RTF management via the MCP. For manual Helm-based installation see Runtime Fabric Setup, and for direct API usage see Runtime Fabric API.

How the MCP fits into RTF operations

graph LR
  Cursor -->|MCP tool call| AnypointPlatform
  AnypointPlatform -->|registers fabric| ControlPlane
  AnypointPlatform -->|returns Helm config| Cursor
  Cursor -->|helm upgrade --install| KubernetesCluster
  KubernetesCluster -->|RTF agent connects| ControlPlane

The create_install_runtime_fabric tool does two things in one call: it registers a new fabric target in Anypoint Platform and then executes the Helm installation against your currently configured kubectl context. All subsequent operations (deploy, update, upgrade, delete) go through the same MCP connection.

Prerequisites

Before using the MCP tools for RTF:

• Cursor with the MuleSoft Anypoint MCP server configured and connected
• Anypoint Platform credentials with the Runtime Fabric Administrator permission
• A Kubernetes cluster already running (EKS, GKE, AKS, OpenShift, Rancher, or Tanzu), with kubectl pointing at it
• Helm 3 installed locally
• A valid Mule license .lic file, base64-encoded

Encode the license file:

1
2
3
4
5
# macOS / Linux
base64 -b0 -i license.lic

# Windows PowerShell
[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte))

Creating a Runtime Fabric cluster

The create_install_runtime_fabric tool registers the fabric in Anypoint and runs the Helm chart installation in a single step.

Supported Kubernetes vendors

Prompt Cursor to create the fabric:

Create a new Runtime Fabric called "prod-rtf" in the "Production" environment,
using my EKS cluster. Install it in the "rtf" namespace.
Mule license (base64): <paste encoded license here>

The MCP call maps to these parameters:

Once the tool completes, the fabric appears in Runtime Manager > Runtime Fabrics with status Active. Allow up to 5 minutes for the agent pods to reach a running state.

Verify from kubectl:

1
kubectl -n rtf get pods

All agent pods (resource-cache, cluster-ops, persistence-gateway, am-log-forwarder) should show Running.

Deploying a Mule application to RTF

The deploy_mule_application tool deploys from a local Maven project or an Exchange asset.

From a local project:

Deploy my application from ./my-api-project to the "Production" environment,
targeting the "prod-rtf" fabric. Enable high availability with a minimum of 2 replicas.

From Anypoint Exchange:

Deploy the asset "my-org/order-api/1.2.0" from Exchange to the "Production" environment
on "prod-rtf". Enable secure deployment.

When highAvailability is true, RTF enforces enforceDeployingReplicasAcrossNodes automatically, ensuring no two replicas land on the same Kubernetes node.

Listing and monitoring applications

Use the list_applications tool to inspect deployed applications, metrics, and recent logs.

Basic listing:

List all applications in the "Production" environment.

With CPU and heap metrics:

List applications in "Production" with CPU and heap metrics for the last hour.

With recent error logs:

List applications in "Production" with error logs for the last 30 minutes.

Results are sorted by last update time, most recent first.

Updating an application

The update_mule_application tool modifies a deployed application without redeployment from scratch. Provide the applicationId and environmentId returned by list_applications.

Scale replicas:

Update application "abc123" in environment "env456" to 3 replicas.

Change deployment model to rolling:

Update application "abc123" in environment "env456" to use rolling deployment model.

Enable autoscaling:

Update application "abc123" in environment "env456" to enable autoscaling
with minimum 2 and maximum 5 replicas.

Bump the runtime version:

Update application "abc123" in environment "env456" to Mule runtime 4.9.4:2e-java17.

Key parameters for RTF-specific updates:

Prefer rolling deployment for production workloads. The recreate model causes downtime because all existing replicas are terminated before the new version starts.

Upgrading the RTF agent

The upgrade_runtime_fabric tool updates the RTF Helm chart to a newer agent version in place.

Prompt:

Upgrade the Runtime Fabric in namespace "rtf" to agent version "2.9.0".

The tool runs helm upgrade against the existing release. Monitor the rollout:

1
2
kubectl -n rtf rollout status deployment/resource-cache
kubectl -n rtf rollout status deployment/cluster-ops

Always check the RTF release notes before upgrading. Breaking changes between major versions may require values.yaml updates that the MCP tool does not perform automatically.

Deleting a Runtime Fabric

The delete_runtime_fabric tool deregisters the fabric from Anypoint Platform and optionally cleans up the Kubernetes namespace.

Safe delete (applications must be removed first):

Delete the Runtime Fabric with ID "fabric-id-123".

Force delete with cluster cleanup:

Delete Runtime Fabric "fabric-id-123" and clean up the Kubernetes namespace "rtf".
Force delete even if applications are still running.

Find the fabricId by asking: “List all Runtime Fabrics in my organisation.” The MCP will return the fabric IDs from GET /organizations/{orgId}/fabrics.

What to avoid

Do not run create_install_runtime_fabric against a namespace that already has an RTF agent. The tool issues a fresh Helm install. Running it twice in the same namespace creates duplicate releases and corrupts the agent state. Always delete the existing fabric first.

Do not upgrade without checking the current agent version first. Downgrading is not supported. Ask the MCP to list your fabrics and inspect the version field before specifying agentVersion.

Do not force-delete a fabric with running applications in production. The force: true flag bypasses the application check. Applications lose their deployment target and enter a failed state in Anypoint Platform. Remove or redeploy applications to another fabric before deleting.

Do not leave cleanupCluster: false after deregistration in shared clusters. RTF installs CRDs and cluster-scoped resources. Without cleanup, these resources remain and interfere with future RTF installations in the same cluster. Always pair deregistration with cleanupCluster: true when tearing down a permanent environment.

Do not use recreate deployment model for zero-downtime services. The recreate strategy terminates all running replicas before starting new ones, causing a gap in service availability. Reserve it for stateful applications that cannot tolerate concurrent old-and-new versions.