Server

Intercom

Endpoint
https://mcp.intercom.com/sse
Transport
HTTP with SSE
Authentication as listed
oauth2.1 (the source's own label, not an observation)
Why it is listed
Listed because it appears in a public directory of MCP servers. Source
Homepage
https://intercom.com
  • Supported 1
  • Partial 1
  • Unknown 21

Contribute a correctionWithdraw this serverJSON

Status against MCP Authorization 2026-07-28 (current revision). Older revisions: 2025-11-25

MCP server features

FeatureLevelStatusObservedEvidence
Protected Resource Metadata servedmcp.prm · Discovery · Authorization Server Discovery › Authorization Server LocationMUSTUnknown (no observation)no observation yet
PRM lists an authorization servermcp.prm.authorization-servers · Discovery · Authorization Server Discovery › Authorization Server LocationMUSTUnknown (no observation)no observation yet
PRM lists scopes_supportedmcp.prm.scopes-supported · Discovery · Authorization › Scope Selection StrategyMAYUnknown (no observation)no observation yet
PRM reachable at a well-known URImcp.prm.well-known · Discovery · Authorization Server Discovery › Protected Resource Metadata Discovery RequirementsMUSTUnknown (no observation)no observation yet
resource_metadata in the 401 challengemcp.prm.www-authenticate · Discovery · Authorization Server Discovery › Protected Resource Metadata Discovery RequirementsMUSTUnknown (no observation)no observation yet
403 insufficient_scope for step-upmcp.rs.insufficient-scope · Authorization · Authorization › Scope Challenge HandlingSHOULDUnknown (no observation)no observation yet
Scope in the WWW-Authenticate challengemcp.rs.scope-challenge · Authorization · Authorization › Scope Selection StrategySHOULDUnknown (no observation)no observation yet
No offline_access in advertised scopesmcp.prm.no-offline-access · Tokens · Authorization › Refresh TokensSHOULDUnknown (no observation)no observation yet
401 for missing or invalid tokensmcp.rs.401-on-invalid · Tokens · Authorization › Token HandlingMUSTUnknown (no observation)no observation yet
Audience validationmcp.rs.audience-validation · Tokens · Security Considerations › Access Token Privilege RestrictionMUSTUnknown (no observation)no observation yet
Bearer token only in the Authorization headermcp.rs.bearer-header · Tokens · Authorization › Access Token UsageMUSTUnknown (no observation)no observation yet
No token passthrough to upstream APIsmcp.rs.no-passthrough · Delegation · Security Considerations › Access Token Privilege RestrictionMUSTUnknown (no observation)no observation yet
Per-client consent on proxy serversmcp.proxy.consent · Consent · Security Considerations › Confused Deputy ProblemMUSTSupportedVendor claim · jbspeakr (documentation pass with Claude Code)source— "This names the application asking to connect, lists what it will be able to do in your workspace, and shows its Client ID and the address it redirects to after you approve. [...] This asks you to authorize access for Intercom MCP, the server, rather than for the application." (Two screens: the Intercom MCP consent page for the dynamically registered client, then Intercom's own authorization screen for the MCP server's upstream client. Docs add that the application name is supplied by the application and not verified by Intercom.)

Authorization server features

FeatureLevelStatusObservedEvidence
Metadata issuer matches the discovery URLmcp.as.issuer-match · Discovery · Authorization Server Discovery › Authorization Server Metadata DiscoveryMUSTUnknown (no observation)no observation yet
Authorization server metadata discoverablemcp.as.metadata · Discovery · Authorization Server Discovery › Authorization Server Metadata DiscoveryMUSTUnknown (no observation)no observation yet
Client ID Metadata Documents supportedmcp.as.cimd · Registration · Client Registration › Client ID Metadata DocumentsSHOULDUnknown (no observation)no observation yet
Dynamic Client Registration offeredmcp.as.dcr · Registration · Client Registration › Dynamic Client RegistrationMAYPartialVendor claim · jbspeakr (documentation pass with Claude Code)source— "OAuth client registration is automatic — the server supports Dynamic Client Registration. However, every redirect URI a client registers is checked against an allowlist, which controls where the server will send authorization responses." (OAuth with a callback on localhost or 127.0.0.1 is allowed on any port; any other callback needs an allowlist entry requested via Intercom Customer Support before the flow will complete.)
1 earlier observation
  1. Unknown · Vendor claim · jbspeakr · evidence
Documented pre-registration pathmcp.as.preregistration · Registration · Client Registration › Pre-registrationSHOULDUnknown (no observation)no observation yet
Issuer identifier in authorization responsesmcp.as.iss-param · Authorization · Authorization › Authorization Response ValidationSHOULDUnknown (no observation)no observation yet
PKCE with S256 advertisedmcp.as.pkce-s256 · Authorization · Security Considerations › Authorization Code ProtectionMUSTUnknown (no observation)no observation yet
Refresh token rotation for public clientsmcp.as.refresh-rotation · Tokens · Security Considerations › Token TheftMUSTUnknown (no observation)no observation yet
Resource indicators honouredmcp.as.resource-indicator · Tokens · Security Considerations › Token Audience Binding and ValidationMUSTUnknown (no observation)no observation yet
All endpoints served over HTTPSmcp.as.https · Transport · Security Considerations › Communication SecurityMUSTUnknown (no observation)no observation yet