Intercom opens a closed beta for Fin to query Snowflake through MCP

Warehouse context becomes part of a support answer

Intercom announced on 8 September 2026 that Fin can query a Snowflake data warehouse through a Model Context Protocol connection. The announcement describes access to operational context such as orders, subscriptions, usage and billing. Rather than treating a support answer as a search only through help content, the connection can bring structured business records into the response.

The accompanying setup guide identifies the feature as a closed beta and directs customers to their Intercom account team for access. It is therefore not appropriate to describe this as general availability for every Fin customer. Availability, the connection configuration and the records exposed to Fin all need to be checked in the actual customer account.

Sources: Intercom original release

The selected Snowflake role defines the boundary

Intercom documents a connection to an MCP server in the customer’s Snowflake account, with read-only SQL lookups and optional Cortex or custom tools. The chosen Snowflake role governs permissions, masking and row access. Setup requires administrative work on both sides; operators should not confuse the privileges needed to establish the connection with the narrower role used for ongoing queries.

The guide also warns that replacing the MCP server resets its grants. That detail belongs in a change checklist: a working connection today does not establish that a later server replacement preserves the intended access. Review the actual grants after infrastructure changes and rerun the same restricted-access tests that were used before the initial release.

Sources: Intercom Snowflake MCP setup and beta status

Customer identity must be established before retrieval

A support conversation can mention an order number, an email address or an account name without proving the requester is entitled to the associated data. Define the identity evidence required before a warehouse lookup and keep it separate from the language used in the question. A fluent match between a name and a record is not sufficient authorization.

Test similar names, shared domains, a former employee, several subscriptions under one account and an order number belonging to another customer. Record whether the connector returns nothing, returns a bounded result or requires a human handoff. The acceptance condition should include absence of unauthorized information, not merely the presence of the expected answer for a normal case.

Keep a lookup distinct from a commercial decision

An invoice status can inform an answer without authorizing a refund, an entitlement change or a renewal offer. Assign those decisions explicitly. If a downstream tool can perform an action, require the workflow to show which retrieved fact supports that action and which policy permits it. Adding warehouse access should not silently expand a support agent’s commercial authority.

For ambiguous data, preserve the ambiguity. A delayed payment feed, a disputed invoice or a backdated contract change may produce several legitimate states. The response should identify the relevant effective time and offer an appropriate review path. Avoid converting an unavailable value into a confident negative answer, especially when the customer may act on the result.

Evaluate answers and warehouse behaviour together

Build a small review set using approved test data and independently written expected outcomes. Include a straightforward lookup, an empty result, conflicting records, a restricted row and a temporary connection failure. Inspect both the customer-facing response and the records actually retrieved. A polite refusal is useful only if sensitive data was not already exposed earlier in the workflow.

Agree on query scope, latency expectations and the owner who investigates failures. Look at warehouse consumption during the trial as well as support handling time. No benchmark in the announcement establishes the cost or speed of a particular customer’s data model. A narrow lookup with clear keys may behave very differently from an open-ended query across several large tables.

A practical first deployment

Choose a support question with a stable definition and a clear read-only answer, such as the state of an authenticated customer’s specific order. Expose only the required fields through the chosen role or approved tool. Keep the original support path available so an unavailable warehouse does not leave the customer without a response or force the agent to improvise.

After the trial, review unresolved cases with Support, Data and the owner of the underlying commercial record. Expand the scope only when those teams can explain retrieval, access and answer quality from evidence. The announcement provides a new connection between systems; the operational value comes from a bounded question, correct identity and a dependable handoff when the answer cannot be established.

Keep the beta dependency visible in the operating plan. A successful trial does not establish a contractual availability commitment, regional coverage or permanent product packaging. Ask the account team to confirm those points before making the connector a critical service dependency.