Fin MCP connectors

Fin can call tools on your MCP server through a custom MCP connector. This page describes how Intercom appears to your server and its authorization server, so you can allowlist it. For the IP ranges Fin calls from, see Intercom IP addresses.

When a teammate connects a custom MCP connector that uses OAuth, Intercom acts as a public OAuth client and completes the authorization code flow with PKCE, as described in the MCP authorization specification. Intercom identifies itself in one of two ways, in the order the specification gives:

• Client ID Metadata Document. Intercom uses a fixed client_id, the URL of a document that describes the client as defined in the Client ID Metadata Document draft, when all of the following hold: your authorization server metadata advertises client_id_metadata_document_supported: true, its issuer matches the URL the metadata was served for, and token_endpoint_auth_methods_supported (if present) includes none. The client_id is the same for every workspace in a region, so you can allowlist it. If any of these conditions is not met, Intercom falls back to Dynamic Client Registration.
• Dynamic Client Registration. Otherwise Intercom registers a new client with your server through Dynamic Client Registration each time a teammate connects or re-authorizes a connector, and the client_id is the one your server issues. Intercom sends no initial access token, so your registration endpoint must accept a public client with the redirect URI for the region.

The client_id and the redirect URI depend on the region the Intercom workspace is hosted in. The workspace URL tells you the region: app.intercom.com is US hosted, app.eu.intercom.com is EU hosted and app.au.intercom.com is AU hosted.

If you serve customers in more than one region, allowlist each region's pair separately. A region's client_id only ever presents its own redirect URI. The redirect URI is the same in both identification modes, so you can allowlist it today; only the client_id depends on the mode.

Each client_id URL serves the metadata document itself. It contains at least client_id (the URL), client_name (Intercom MCP Client), client_uri, redirect_uris (the redirect URI for its region), grant_types (authorization_code and refresh_token), response_types (code) and token_endpoint_auth_method (none), and may carry other fields registered for RFC 7591 such as logo_uri, policy_uri and tos_uri. Treat the fetched document as authoritative; it is served with a one-hour cache lifetime.

• Discovery. Your MCP server should publish OAuth 2.0 Protected Resource Metadata (RFC 9728) naming your authorization server in authorization_servers; Intercom uses the first entry. If there is no such document, Intercom treats the MCP server URL as the authorization server. The authorization server should publish OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery metadata so Intercom can find the authorization and token endpoints, and the registration endpoint if you rely on Dynamic Client Registration. Intercom needs this metadata to use the Client ID Metadata Document. If no metadata is found, Intercom falls back to /authorize, /token and /register under your MCP server URL with Dynamic Client Registration.
• Authorization code flow with PKCE (S256) for a public client. Intercom sends client_id in the body of the token request and never a client secret. Issue a refresh token if you want the connection to outlive the access token; Intercom uses the refresh_token grant.
• The resource parameter. Intercom sends the MCP server URL the teammate entered as the RFC 8707 resource parameter on both the authorization request and the token request. Accept or ignore it, and if you bind tokens to an audience, expect that exact URL.
• Scopes. Intercom requests the scope from your MCP server's 401 WWW-Authenticate challenge if there is one, otherwise scopes_supported from the Protected Resource Metadata, otherwise every scope in the authorization server's scopes_supported. To control what Intercom asks for, return a scope in the challenge or list the minimal set in the Protected Resource Metadata.
• The iss parameter (RFC 9207). When Intercom identifies itself with the Client ID Metadata Document, it compares any iss in the authorization response with the issuer from your authorization server metadata (exact string match) and fails the connection on a mismatch. A missing iss fails the connection only if you advertise authorization_response_iss_parameter_supported: true. When Intercom used Dynamic Client Registration, a mismatch does not fail the connection.