The Developer’s Guide to Headless MuleSoft

Reading Time: 18 minutes

If you’ve been building on MuleSoft for a while, you know the drill: log in to Anypoint Platform, click through Exchange, navigate to API Manager, switch to Runtime Manager. The platform APIs and CLIs have always existed, but accessing that power programmatically still required knowing exactly which APIs to call, how they are chained together, and how to authenticate across domains. In other words, it was possible, just not easy, and not accessible to an AI agent.

That’s what’s changing. By exposing the platform as an MCP server, MuleSoft makes its entire control plane accessible through AI agents, dramatically lowering the bar for who can interact with it and how fast. The full platform lifecycle (API and AI management, policy enforcement, runtime deployment, governance, monitoring) can now be reached via:

MCP (Model Context Protocol) servers for AI agents and LLM-native tools
REST APIs across every platform domain (access management, API lifecycle, gateway, config, messaging, security)
Pre-built Skills encoding multi-step platform workflows in machine-readable format
Terraform Provider for declarative, version-controlled infrastructure provisioning
A natural language agent embedded directly in the platform UI

This isn’t a thin API wrapper on top of the GUI. The Platform MCP Server exposes the same operational surface that powers the visual console. Agents can do everything a human can, through the same authorization model, the same audit trail, and the same policy enforcement.

Prerequisites

Before you dive in, make sure you have:

An Anypoint Platform account with at least one environment configured
A Connected App (Client ID + Client Secret) created under Access Management → Connected Apps with the appropriate scopes
For MCP Server: an MCP-compatible client (Cursor, VS Code with the MCP extension, Windsurf, Claude Desktop, or Claude Code)
For Terraform: Terraform CLI v1.5+ and your Connected App credentials ready as environment variables

For more information, see the full documentation.

How to connect the MCP server to your IDE

The MuleSoft Platform MCP Server is a remote MCP server that any MCP-compatible client can connect to. Once connected, you can query your API catalog, deploy applications, apply policies, and pull monitoring data, all without leaving your IDE.

Cursor / VS Code setup

Add the following to your .cursor/mcp.json or VS Code MCP config file:

{
  "mcpServers": {
    "mulesoft-platform": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "https://omni.mulesoft.com/mcp",
        "--static-oauth-client-info",
        "{\"client_id\":\"YOUR_CLIENT_ID\",\"client_secret\":\"YOUR_CLIENT_SECRET\"}"
      ]
    }
  }
}

Replace YOUR_CLIENT_ID and YOUR_CLIENT_SECRET with your Connected App credentials.

Verifying the connection

Once connected, your MCP client should list available MuleSoft tools. Run a quick test prompt:

"List all APIs in my production environment."

A successful response returns a list of API instances from your org. If you get a permissions-related error when attempting to authenticate, add these permissions to your connected app:

Background access
Profile
Identity
Email

What makes this more than a chat interface

Your MuleSoft identity and access controls apply regardless of which surface you’re coming from. There’s no elevated access through the AI tool, no shadow path around policies. Connecting your IDE is just the start. The real power comes from building agents that understand the platform’s full dependency chain.

How to use the Developer Hub to build platform-aware agents

One of the trickier problems in building AI agents that operate on complex platforms is context: how does an agent know that protecting an API with a policy requires chaining calls across Access Management, API Manager, Exchange, and Omni Gateway? And how does it know the right order of steps and resolve proper org IDs and environment IDs along the way?

The MuleSoft Developer Hub is built to solve exactly that by providing documentations and examples agents and humans need to successfully use all the tools. It’s structured around four asset types:

Asset type	What it is	Who uses it
API Specs	Full OpenAPI coverage of every platform domain	Developers building integrations and agents
Skills	Multi-step workflow recipes with chained inputs/outputs	AI agents executing platform workflows
MCP Servers	Standardized MCP interface to the platform	Any MCP-compatible agent or tool
Terraform Provider	Declarative IaC for reproducible provisioning	Platform/DevOps engineers

For human developers, there’s a live playground. Authenticate with your MuleSoft credentials and test calls directly. No third-party testing application needed.

MuleSoft for Slack: incident response without context-switching

Alerts often land in email or SMS, but your team works in Slack. The MuleSoft for Slack integration closes that gap with three capabilities:

Native alerts routed directly to Slack channels or DMs, filterable by type, severity, and delivery method, covering APIs, MCPs, agents, and LLMs
Platform MCP Server in Slackbot: ask Slackbot questions about your MuleSoft environment, surface assets, and take action via structured cards
MuleSoft Agent for Slack (limited availability): full natural language platform interaction from within Slack

The practical workflow: alert fires in your #platform-ops channel → someone asks Slackbot to pull related service details and check governance policies → team coordinates and asks the agent to execute the fix. No tab-switching, no context loss.

Setup: Talk to your MuleSoft Account Manager to get access to MuleSoft for Slack. Afterwards, ask your Slack Administrator to install the MuleSoft Slack app, then connect the Platform MCP Server through Slackbot’s Integrations tab.

Example prompts

The following prompts demonstrate what you can do once the Platform MCP Server is connected to your IDE, Slack, or an AI agent. Use them as-is or adapt them to your environment.

Governance and policy:

“List all APIs in my production environment that don’t have a rate-limiting policy applied.”
“Which APIs in staging are missing OWASP API Security validation?”
“Show me all MCP servers that have no governance policy attached.”
“What policies are currently applied to [API name] across all environments?”

Cost and usage:

“Show me the top 5 LLM consumers by token spend this week.”
“Which MCP tool descriptions are flagged as cost-inflating?”
“Compare token usage between our production and staging LLM proxies this month.”

Discovery and inventory:

“What agents are registered but haven’t been synced in the last 30 days?”
“List all MCP servers discovered from Amazon Bedrock AgentCore that aren’t yet governed.”
“Which APIs in Exchange have no associated agent or MCP tool?”

Deployment and operations:

“Deploy the latest version of [API name] to the production environment.”
“What changed in [API name]’s configuration in the last 24 hours?”
“Show me all failed deployments in the past week and their error reasons.”

Incident response:

“An alert fired on [API name]. What are the current error rates and last policy changes?”
“Which APIs have had SLA breaches in the last 7 days?”
“Pull all notifications from the last hour for the customer-data environment.”

How to manage MuleSoft infrastructure with Terraform

The MuleSoft Terraform Provider lets you manage your entire MuleSoft stack (APIs, MCP servers, gateways, and policies) as version-controlled infrastructure code. This prevents configuration drift as MCP servers and AI agents proliferate alongside traditional APIs. Check out sample codes in the appendix below.

The unified governance model

The thread running through all of these capabilities is a single control model. Whether access comes from:

A developer in Cursor via the MCP Server
A CI/CD pipeline via the REST APIs
An AI agent using Skills from the Developer Hub
A terraform apply in your GitOps workflow
A teammate asking a question in Slack

MuleSoft’s permission model, policies, and audit trail apply uniformly. Security teams enforce in one place. One authorization model. One audit trail. One surface to secure.

Where to start

If you want to…	Start here
Use MuleSoft from your IDE or Claude	Headless MuleSoft / Platform MCP Server
Build agents that operate on the platform	MuleSoft Developer Hub
Manage MuleSoft infrastructure as code	Terraform Provider
Get platform alerts + actions in Slack	MuleSoft for Slack
Use natural language in the platform UI	MuleSoft Agent
Understand the full platform direction	MuleSoft Meets Developers Where They Work

Terraform Provider sample code

Here are a few sample codes you can try out.

Provider setup

terraform {
  required_providers {
    anypoint = {
      source  = "mulesoft-anypoint/anypoint"
      version = "~> 1.0"
    }
  }
}

provider "anypoint" {
  client_id     = var.anypoint_client_id
  client_secret = var.anypoint_client_secret
}

Store credentials as environment variables rather than hardcoding them:

export ANYPOINT_CLIENT_ID=your_client_id
export ANYPOINT_CLIENT_SECRET=your_client_secret

Create a gateway

resource "anypoint_managed_omni_gateway" "my_gateway" {
  name           = "my-gateway"
  environment_id = var.environment_id
  target_id      = var.target_id
}

Register an API instance behind the gateway

resource "anypoint_api_instance" "orders_api" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  instance_label  = "orders-api"

  spec = {
    asset_id = var.orders_api_asset_id
    group_id = var.organization_id
    version  = var.orders_api_asset_version
  }

  endpoint = {
    base_path = "/orders/v1"
  }

  gateway_id   = anypoint_managed_omni_gateway.my_gateway.id
  upstream_uri = "http://orders-service.internal:8080"
}

Register an MCP Server

resource "anypoint_mcp_server" "inventory_mcp" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  instance_label  = "inventory-mcp-server"

  spec = {
    asset_id = var.inventory_mcp_asset_id
    group_id = var.organization_id
    version  = var.inventory_mcp_asset_version
  }

  endpoint = {
    base_path = "inventory-mcp/v1"
  }

  gateway_id   = anypoint_managed_omni_gateway.my_gateway.id
  upstream_uri = "http://inventory-service.internal:8080"
}

Full stack: Gateway + API + MCP server with policies in one apply

The effect is atomic, reproducible deployments. The entire environment (gateway, API, MCP server, and all security policies) stands up with a single terraform apply.

resource "anypoint_managed_omni_gateway" "customer_portal_gateway" {
  name           = "customer-portal-gateway"
  environment_id = var.environment_id
  target_id      = var.target_id
}

resource "anypoint_api_instance" "accounts_api" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  instance_label  = "accounts-api"

  spec = {
    asset_id = var.accounts_api_asset_id
    group_id = var.organization_id
    version  = var.accounts_api_asset_version
  }

  endpoint = {
    base_path = "/accounts/v1"
  }

  gateway_id   = anypoint_managed_omni_gateway.customer_portal_gateway.id
  upstream_uri = "http://accounts-service.internal:8080"
}

# Only authorized AI agents can call the API
resource "anypoint_api_policy_jwt_validation" "accounts_jwt" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  api_instance_id = anypoint_api_instance.accounts_api.id

  configuration = {
    jwt_origin                = "httpBearerAuthenticationHeader"
    signing_method            = "rsa"
    signing_key_length        = 256
    jwt_key_origin            = "jwks"
    jwks_url                  = var.jwks_url
    skip_client_id_validation = true
    validate_aud_claim        = true
    mandatory_exp_claim       = true
  }

  order = 1
}

resource "anypoint_api_policy_rate_limiting" "accounts_rate_limit" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  api_instance_id = anypoint_api_instance.accounts_api.id

  configuration = {
    rate_limits = [
      {
        maximum_requests            = 100
        time_period_in_milliseconds = 60000
      }
    ]
    expose_headers = false
    clusterizable  = true
  }

  order = 2
}

resource "anypoint_mcp_server" "customer_mcp" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  instance_label  = "customer-portal-mcp"

  spec = {
    asset_id = var.customer_mcp_asset_id
    group_id = var.organization_id
    version  = var.customer_mcp_asset_version
  }

  endpoint = {
    base_path = "customer-mcp/v1"
  }

  gateway_id   = anypoint_managed_omni_gateway.customer_portal_gateway.id
  upstream_uri = "http://customer-service-mcp.internal:8080"
}

# Only authorized AI agents can call the MCP server
resource "anypoint_api_policy_jwt_validation" "customer_mcp_jwt" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  api_instance_id = anypoint_mcp_server.customer_mcp.id

  configuration = {
    jwt_origin                = "httpBearerAuthenticationHeader"
    signing_method            = "rsa"
    signing_key_length        = 256
    jwt_key_origin            = "jwks"
    jwks_url                  = var.jwks_url
    skip_client_id_validation = true
    validate_aud_claim        = true
    mandatory_exp_claim       = true
  }

  order = 1
}

resource "anypoint_api_policy_mcp_pii_detector" "customer_mcp_pii" {
  organization_id = var.organization_id
  environment_id  = var.environment_id
  api_instance_id = anypoint_mcp_server.customer_mcp.id

  configuration = {
    entities = ["Email", "Phone Number"]
  }

  order = 2
}

Policy ordering matters: JWT validation runs first (order = 1) so unauthenticated requests are rejected before reaching downstream policies.

The Developer’s Guide to Headless MuleSoft

Share post