Connect External MCP Servers
ACP can act as an MCP client — connecting to external MCP servers and consuming their tools. Every tool from an external server goes through ACP’s full governance pipeline: identity verification, scope enforcement, content scanning, rate limiting, and audit logging.
This means you can connect any MCP-compatible tool server — your own, third-party, or open-source — and get governance for free.
What you need
- An ACP Cloud workspace (sign up)
- An external MCP server with a reachable URL (Streamable HTTP or SSE transport)
Step 1: Register the MCP server
In the ACP dashboard, go to Connectors → MCP Servers → Add Server.
| Field | Value |
|---|---|
| Name | A descriptive name (e.g. internal-docs) |
| Server ID | A short identifier (e.g. docs) — used in tool namespacing |
| URL | The MCP server’s endpoint URL |
| Transport | Streamable HTTP or SSE |
| Auth header | (Optional) Bearer token or API key for the external server |
Via the API
curl -X POST \
-H "Authorization: Bearer gsk_myworkspace_a1b2c3d4e5f6" \
-H "Content-Type: application/json" \
https://api.makeagents.run/myworkspace/api/v1/mcp-servers \
-d '{
"name": "Internal Documentation",
"serverId": "docs",
"url": "https://docs-mcp.internal.acme.com",
"transport": "streamable-http",
"authHeader": "Bearer internal-token-here"
}'
Step 2: Understand tool namespacing
When ACP connects to an external MCP server, it discovers the server’s tools and namespaces them:
mcp.{serverId}.{toolName}
For example, if your docs server exposes tools called search and getPage, they appear in ACP as:
mcp.docs.searchmcp.docs.getPage
This prevents name collisions between tools from different servers. Your users see all tools from all connected servers — namespaced and governed.
Step 3: Configure scopes for external tools
External MCP server tools are governed like any other tool. In Policies → Tool Scopes:
{
"mcp.docs.search": ["docs:read"],
"mcp.docs.getPage": ["docs:read"],
"mcp.jira.createIssue": ["jira:write"],
"mcp.jira.listIssues": ["jira:read"]
}
Users need the required scopes in their JWT to call external tools. No scope = no access.
Step 4: Connect from your AI client
Your users don’t need to know about the external MCP servers. They connect to your ACP workspace endpoint as usual:
{
"mcpServers": {
"my-company": {
"url": "https://api.makeagents.run/your-slug",
"transport": "streamable-http"
}
}
}
ACP merges tools from all sources — built-in connectors, external MCP servers, and agent-defined tools — into a single tool list. The user sees everything they have permission to use.
How it works under the hood
Connection pooling
ACP maintains a connection pool to each external MCP server. Connections are reused across requests to avoid the overhead of reconnecting on every tool call. Idle connections are cleaned up after 5 minutes.
This means the first tool call to an external server may take slightly longer (connection setup), but subsequent calls are fast.
SSRF protection
ACP blocks connections to private IP ranges:
localhost/127.0.0.0/810.0.0.0/8172.16.0.0/12192.168.0.0/16169.254.0.0/16(link-local / cloud metadata)metadata.google.internal
This prevents a malicious MCP server URL from being used to probe your internal network. The check runs before any connection is established.
Tool discovery
When a connection is established, ACP calls the MCP server’s tools/list method to discover available tools. Tools are cached for the lifetime of the connection. If the external server adds or removes tools, reconnecting refreshes the tool list.
Governance pipeline
Every call to an external MCP server tool goes through the same 7-layer governance pipeline as built-in tools:
- Immutable rules — SSN, credit card, SSRF pattern scanning
- Delegation check — Agent-to-agent trust chain (if applicable)
- Scope enforcement — User’s JWT scopes vs. tool requirements
- ABAC rules — Attribute-based access control
- Rate limits — Per-user rate limiting
- Plan limits — Subscription tier enforcement
- Content scanning — PII detection on inputs and outputs
The external server never sees the user’s JWT or identity. ACP handles auth with the external server using the configured auth header. Identity stays inside ACP.
Plan limits
| Limit | Free | Pro | Enterprise |
|---|---|---|---|
| External MCP servers | 0 | 3 | 10 |
| Tools per server | — | Unlimited | Unlimited |
| Connection pool size | — | Per-server | Per-server |
Free plans cannot connect external MCP servers. Upgrade to Pro to enable this feature.
Example: Connect a Jira MCP server
- Deploy a Jira MCP server (e.g.,
@modelcontextprotocol/server-jira) - Register it in ACP:
curl -X POST \
-H "Authorization: Bearer gsk_myworkspace_a1b2c3d4e5f6" \
-H "Content-Type: application/json" \
https://api.makeagents.run/myworkspace/api/v1/mcp-servers \
-d '{
"name": "Jira",
"serverId": "jira",
"url": "https://jira-mcp.internal.acme.com",
"transport": "streamable-http",
"authHeader": "Bearer jira-service-token"
}'
- Configure scopes:
{
"mcp.jira.listIssues": ["jira:read"],
"mcp.jira.createIssue": ["jira:write"],
"mcp.jira.updateIssue": ["jira:write"]
}
- Your users can now ask Claude: “Create a Jira ticket for the login bug” — and it goes through identity verification, scope checks, content scanning, and audit logging.
Troubleshooting
“Connection refused” The external MCP server URL is unreachable from ACP’s network. Ensure the server is publicly accessible or whitelisted for ACP’s IP range.
“SSRF protection: private IP blocked” The MCP server URL resolves to a private IP address. External MCP servers must be accessible via public URLs.
“Plan limit: maxMcpServers exceeded” Your plan doesn’t support the number of external servers you’ve configured. Upgrade to Pro (3 servers) or Enterprise (10 servers).
“Tool not found: mcp.xyz.toolName” The external MCP server may not expose that tool, or the connection needs to be refreshed. Check the server’s tool list and try reconnecting.
Back to guides · Build agents with the API → · Set up Auth0 →