Fin and MCP oAuth | Community
Skip to main content
Answered

Fin and MCP oAuth

  • May 5, 2026
  • 1 reply
  • 201 views
M

We are testing Custom MCP with OAuth for a multi-tenant SaaS use case.

Observed behavior: after one admin completes the OAuth flow, all Fin conversations appear to call our MCP server with the same OAuth token, even when the current conversation belongs to another customer/account.

Can you confirm:

  1. Is Custom MCP OAuth stored at the Intercom workspace / connector level?
  2. Does Intercom support per-contact or per-company OAuth grants for Custom MCP?
  3. Can Fin trigger an OAuth authorization flow for the current end customer during a conversation?
  4. Can Custom MCP tools receive Intercom User Tokens from auth_tokens, or are User Tokens only supported by standard Data connectors?
  5. Does every MCP tool call include a stable Intercom workspace/contact/company identifier in metadata or only via configured tool input parameters?
  6. Is there a supported way to send a dynamic Authorization header per current Messenger user for Custom MCP?
  7. If not, is the recommended design to use standard Data connectors with User tokens for customer-specific authenticated data?

Best answer by Sean Meade Forum Support Lead

Hi ​@Mekios, Seán here from the Fin technical support team 👋 yes, what you're seeing matches how Custom MCP works today.

 

Short version:

  • The OAuth grant for a Custom MCP server is stored at the workspace / connected-server level, not per end customer. The OAuth flow happens when the server is connected in Intercom settings, and that connected MCP server is then reused for tool calls from that workspace.

  • Intercom does not currently support a separate Custom MCP OAuth grant per contact or per company. For MCP, the auth is attached to the MCP server, while per-conversation variation is handled by passing Intercom user/company/conversation attributes into tool input parameters.

  • Fin cannot trigger a fresh OAuth authorization flow for the current end customer during a live conversation. The OAuth initiation flow is part of MCP server setup by a teammate/admin in workspace settings.

  • User tokens are definitely documented for standard Data connectors via auth_tokens. For Custom MCP, that is separate from the shared connector-level OAuth flow. Internally, the current MCP token-based path does resolve token values by user_id, but that is different from the one-time Custom MCP OAuth grant you described.

  • I also would not rely on implicit MCP metadata for stable workspace/contact/company identifiers. The MCP client request is essentially the tool name plus arguments, so if your server needs those identifiers, the safest pattern is to pass them explicitly as configured tool inputs mapped from Intercom attributes.

So for your design question if you need customer-specific authenticated access, the recommended pattern today is to use standard Data connectors with User tokens, rather than Custom MCP OAuth.

 

A simple rule of thumb is:

  • Use Custom MCP OAuth when one workspace-level service grant is acceptable.

  • Use standard Data connectors with User tokens when auth needs to vary per Messenger user/customer.

    1 reply

    S
    Intercom Team
    Forum|alt.badge.img+6

    Hi ​@Mekios, Seán here from the Fin technical support team 👋 yes, what you're seeing matches how Custom MCP works today.

     

    Short version:

    • The OAuth grant for a Custom MCP server is stored at the workspace / connected-server level, not per end customer. The OAuth flow happens when the server is connected in Intercom settings, and that connected MCP server is then reused for tool calls from that workspace.

    • Intercom does not currently support a separate Custom MCP OAuth grant per contact or per company. For MCP, the auth is attached to the MCP server, while per-conversation variation is handled by passing Intercom user/company/conversation attributes into tool input parameters.

    • Fin cannot trigger a fresh OAuth authorization flow for the current end customer during a live conversation. The OAuth initiation flow is part of MCP server setup by a teammate/admin in workspace settings.

    • User tokens are definitely documented for standard Data connectors via auth_tokens. For Custom MCP, that is separate from the shared connector-level OAuth flow. Internally, the current MCP token-based path does resolve token values by user_id, but that is different from the one-time Custom MCP OAuth grant you described.

    • I also would not rely on implicit MCP metadata for stable workspace/contact/company identifiers. The MCP client request is essentially the tool name plus arguments, so if your server needs those identifiers, the safest pattern is to pass them explicitly as configured tool inputs mapped from Intercom attributes.

    So for your design question if you need customer-specific authenticated access, the recommended pattern today is to use standard Data connectors with User tokens, rather than Custom MCP OAuth.

     

    A simple rule of thumb is:

    • Use Custom MCP OAuth when one workspace-level service grant is acceptable.

    • Use standard Data connectors with User tokens when auth needs to vary per Messenger user/customer.

    Terms & ConditionsAccessibility statement