Beta. MCP servers are available now, but the surface is still settling — expect changes.
Connect a Server
Go to Actions and add a server from the MCP servers section — either pick one from the preset gallery (OpenCX, Slack, HubSpot, Intercom, Linear, Notion, Stripe) or add a custom URL.1
Enter the server URL
A Streamable HTTP or SSE endpoint, e.g.
https://mcp.example.com/mcp. OpenCX probes it to detect how it authenticates.2
Choose who connects
Select Our team — one shared account to connect from Actions, or Each user — their own account to let signed-in widget customers connect individually. Ownership is fixed when the server is created.
3
Authenticate
For a shared account, authenticate here. For personal accounts, follow Widget connections to authenticate your customers and let them connect inside the widget.
- OAuth — if the server advertises OAuth (discovery + dynamic client registration), OpenCX opens its authorization page. Approve, and you’re redirected back connected. Tokens are refreshed automatically and kept out of the widget. Personal connections can optionally be reused by your backend.
- Request headers — if the server expects a static credential instead (an API key, a bearer token), enter it as a header. Values are encrypted at rest and never displayed again; reference a named secret instead of pasting a raw value so the credential lives in one place.
Slack’s MCP server supports neither automatic path, so it uses a pre-registered OAuth client instead of discovery.
4
Review and enable
Once connected, OpenCX lists every tool the server publishes. The server is enabled by default — flip it off to keep the connection and its tool list without letting agents call anything.
Personal accounts in the widget
Enable a personal server in Actions, then authenticate each customer through your backend. The widget asks the customer to connect only when a request needs access, and continues after authorization. Customers manage their own connections and saved approvals from Connections in the widget session list. Shared team connections are managed in Actions. For personal servers, use Capabilities in the server’s add or edit dialog to describe the actions it supports. This helps the agent request a connection for relevant tasks before it can see the customer’s authorized tools. Include useful limits, keep the description aligned with enabled actions, and leave out credentials and customer data. This description is guidance, not a guarantee of access; tools are checked after the customer connects. See Widget connections for setup and widget authentication for account binding and optional restrictions.Per-Tool Control
Open a connected server’s detail page to see its live tool catalog, grouped by what each tool does — write, fetch, or other. Switch individual tools off, or a whole group at once.- The catalog is re-read from the server (
tools/list) every time you open the page, so a tool the vendor adds later shows up already enabled. - Switching a tool off stores it in a disabled set on your connection — it stays off even after the vendor’s catalog changes, until you turn it back on.
- Write tools default to visible/open in the list since they’re the ones worth auditing before an agent gets to call them; fetch tools default collapsed.
How Agents Call MCP Tools
Once enabled, an MCP server’s tools are available to the AI agent exactly like any other action — the agent decides whether a tool matches the customer’s request, same as for HTTP actions. Tool names are namespaced as<server>__<tool> so two servers can each expose a tool with the same raw name (e.g. two different search tools) without colliding. If a server is unreachable when the agent tries to list its tools, that server’s tools are omitted without breaking the whole tool list; its detail page reports the failure reason inline.
Troubleshooting
Related Documentation
AI Actions
How actions fit alongside integration and system tools.
Authentication
Named secrets, global variables, and header auth for actions.
OpenAPI Import
The other way to bulk-add actions, from your own OpenAPI spec.
Troubleshooting
General action failures — import errors, 401s, AI not calling.