MCP
How to configure MCP Server connectors for all users or embedded chat users
Transport Types
Connectors support two MCP transport types:
- Streamable HTTP (
streamable_http) — default transport, uses HTTP requests with streaming responses - SSE (
sse) — Server-Sent Events, uses a persistent connection for server-to-client messages
Authentication Types
Connectors support three authentication types:
- Static Token — shared authentication token, available to all users. Configured via the Header field (e.g.,
Authorization: Bearer secretkey123) - OAuth 2.1 — each user authenticates with their own OAuth credentials
- JWT Passthrough — used by embedded chat, the decrypted JWT token is passed to the MCP server
Static Token
Configure a shared authentication token via the Header field (e.g., Authorization: Bearer secretkey123). This token is used for all requests to the MCP server.
OAuth 2.1
Each user authenticates individually and gets their own connection to the MCP server. OAuth tokens are stored per user — no credentials are shared between users, and one user cannot access another user's data through the connector.
When using OAuth 2.1 authentication, configure the following fields:
| Field | Description |
|---|---|
| OAuth Client ID | The client ID from your OAuth provider (only required if the server does not support Dynamic Client Registration) |
| OAuth Client Secret | The client secret from your OAuth provider (only required if the server does not support Dynamic Client Registration) |
| OAuth Scopes | Space-separated list of OAuth scopes to request (optional) |
The authorization and token URLs are automatically discovered from the MCP server's metadata endpoint. If the MCP server supports Dynamic Client Registration (RFC 7591), the client ID and secret are obtained automatically and do not need to be configured manually.
OAuth connectors also support custom Header fields (e.g., X-Custom-Header: value), which are sent alongside the OAuth token on every request to the MCP server.
JWT Passthrough
JWT Passthrough is used with embedded chat. The website signs and encrypts a JWT token, which the platform decrypts and passes to the MCP server for authentication.
Use the %{jwt_token} placeholder in the connector Header field (e.g., Authorization: Bearer %{jwt_token}). It will be replaced with the decrypted JWT token at runtime.
How It Works
Key Pair Distribution
Two RSA key pairs are required for secure JWT token exchange:
| Key Pair | Purpose | Website | Mitigate AI Platform | MCP Server |
|---|---|---|---|---|
| Signing Key Pair | Ensures token authenticity (RS256) | Private key (signs JWT) | Public key (verifies signature) | Public key (verifies signature) |
| Encryption Key Pair | Protects token confidentiality (RSA-OAEP, A256GCM) | Public key (encrypts JWT) | Private key (decrypts JWT) | - |
Configure Key Pairs
- Go to Admin → Workspaces
- Click Add Workspace
- Enter Name
- Click Save Workspace
- Click on Configure Embedded Chat and configure key pairs
Tool Caching
By default, the platform fetches the list of available tools from the MCP server on every chat interaction. For connectors with a large number of tools or slower servers, you can enable Tools Cache to store the tool list locally and avoid repeated lookups.
Enabling Tool Caching
- Go to Admin → Connectors → select a connector
- Edit the connector and enable the Tools Cache toggle
- Click Save
When caching is enabled, a "Cached" badge appears on the connector in the connectors index. To refresh the cached tools (e.g., after the MCP server adds new tools), click Refresh Tools on the connector detail page.
Tool Approval
By default, tool calls execute automatically. You can require user approval for specific tools before they run, adding a consent step to the chat flow.
On the connector detail page, the Tools table shows all available tools. For each tool, you can toggle:
- Auto Approve — When disabled, the user is prompted to approve or reject the tool call before it executes. When enabled, the tool runs without confirmation.
When a tool requires approval, the chat displays the tool name and arguments and asks the user to approve or reject the call. Approved calls execute normally; rejected calls return a rejection result to the assistant.
Deferred Tools
For connectors with many tools (dozens or hundreds), loading all of them into every conversation is inefficient. Deferred tools solve this by loading tools on-demand using semantic search.
On the connector detail page, toggle Deferred for individual tools. Deferred tools are not loaded into the conversation initially. Instead, when the assistant needs a tool, it uses a built-in tool_search to find relevant deferred tools by description. Matched tools are then loaded into the active conversation.
This keeps conversations lightweight while still giving the assistant access to the full tool catalog.
Connector Settings in Chat
Users can view and manage their connector connections directly from the chat interface. A settings icon in the chat header shows the connection status of each connector assigned to the workspace:
- Green indicator — Connected and ready to use
- Red indicator — Not connected (OAuth connectors only)
For OAuth connectors, users can connect or disconnect their account directly from this panel without leaving the chat.