Yes, you can connect Intercom Fin to your codebase — without giving it any access to the code. Fin supports custom MCP connectors (Settings → Integrations → Data connectors → "Custom MCP"): all it needs is the URL of an MCP server plus authentication. So the right way to do this is not to hand your support platform a GitHub token: it's to plug Fin into an answers endpoint — a product expert that answers questions from your real code, re-synced on every push.
This guide walks through the setup step by step (Intercom UI verified on August 18, 2026), then takes on the two objections that always come up: "why not the official GitHub MCP server?" and "but this expert reads my repo itself."
Why plug Fin into the code, instead of yet another knowledge base?
Fin answers from the knowledge sources you give it: help center, articles, snippets. All of them share the same structural flaw — they are frozen copies of your product, written at one point in time. Your product changes with every deploy. The window right after a release is exactly when customers ask the most questions ("this button moved", "this behavior changed") — and exactly when every frozen copy is stale. We unpacked the mechanism in why your AI support agent doesn't know your product: written knowledge starts lying at the precise moment you deploy.
An MCP connector gives Fin access at question time: instead of re-reading a copy written in advance, the agent queries a live source at the moment the customer asks. If that source is derived from the real code, the answer is true now — not as of the last documentation sprint.
"Fin, what changed in the product this week?"
That's the litmus-test question. Asked of a Fin fed on help-center articles, it gets you the last published release note at best — if someone wrote one. Asked of a Fin plugged into a code-derived expert, it gets a dated, sourced answer built from commits and diffs. An illustrative example of what the connection changes:
- Without: "You can check our What's New page" (last updated three weeks ago).
- With: "Two visible changes this week: the CSV export now includes a header row, and the default session timeout went from 30 to 60 minutes. No API changes."
The entire "what changed?" family of questions becomes answerable the same way: since the last release, for one specific feature, does anything break.
The step-by-step guide
1. What you need
A remote MCP server exposing answer tools about your product: a URL, and authentication (an access token, or OAuth if the server offers it). That's exactly what DeployIt provides in early access: one MCP server per project, connected read-only to your GitHub repository, with answers derived from the code and the git history — see how the DeployIt MCP server works.
2. Create the connector in Intercom
- Open Settings → Integrations → Data connectors.
- Click the "Custom MCP" tile.
- Enter a meaningful name (say, "Product expert — your product") and the MCP server's URL.
- Provide the access token if your server uses token auth; otherwise Intercom initiates an OAuth flow with the server.
3. Add the tools and let Fin use them
Once the server is connected, add its tools with "+ New" under the connector's section. The decisive option is the checkbox:
"Enable Fin to use this connector directly without adding it to a workflow or task"
Checked, it lets Fin decide on its own to call the tool when the conversation warrants it — based on the tool's name, description, and inputs. Hence a practical rule: invest in the descriptions ("answers questions about the product's current behavior and what changed between versions" beats "product tool"). Unchecked, the tool must be added explicitly to a Procedure — Intercom's current format for guided flows (since March 12, 2026, new automations are built as Procedures rather than Tasks).
4. Test before going live
In Fin's preview, ask the questions your customers will actually ask: "what changed this week?", "why did the export format change?", "does the update break my integration?". Check that the answers are dated, sourced, and match your latest deploy. A good habit: ship something small, then ask the same question again five minutes later — the answer should already reflect the new push. That freshness loop is the whole point of the connection, so it's worth verifying before your customers do it for you.
Ready to see what your team shipped?
The DIY objection: "I'll just use the official GitHub MCP server"
It's a real option, and it deserves an honest look. GitHub's official MCP server can list commits, pull requests, and issues — for a tooled-up developer using it from Claude or Cursor, that's often enough. For the Fin use case, two structural limits:
- Credentials. The official GitHub server authenticates with repository credentials. Pointing Fin at it means handing repo access to a third-party platform that talks to your customers — precisely what you're trying to avoid. An answers endpoint flips the relationship: Fin receives answers, never repository access.
- Metadata vs. diffs. Listing commits means reading commit messages. If a commit is named "fix", the list tells you neither what changed nor why. Answering "why did this behavior change?" requires reading the diffs — the actual content of the change. That's what a dedicated product expert does: its answers hold up even with badly named commits.
The mirror objection: "but this expert reads my repo itself"
Correct — and here is exactly how. The GitHub connection is read-only. Each project gets its own MCP server: one product's expert sees nothing but that product. Answers are derived from commits and diffs — the expert never returns raw source code to whoever asks. Access is revocable at any time, and the code never leaves your repository: what you share with Fin is the answers, not the code. And the knowledge is re-synced on every push — Monday's answer includes Monday's deploy.
That's also what separates this approach from the neighboring tools: Context7 and DeepWiki cover libraries and public repositories; Mintlify generates an MCP server from written docs. The DeployIt expert covers your private product, derived from the code itself, fresh on every deploy.
Mini-FAQ
Can Fin trigger actions through this connector? MCP allows it in general (create a ticket, update a status…). The DeployIt connector, though, exposes answer tools: it reads, it changes nothing.
Do I need to reconfigure anything at each release? No. The expert's knowledge is rebuilt on every push; the Fin connector itself doesn't change.
Does this measure my developers' activity? No. The expert answers questions about the product — what changed, when, why. It is neither an activity-reporting tool nor a productivity metric.
What about other agents — HubSpot Breeze, Claude, Cursor? Same principle: any MCP client can query the same server. One expert, every surface you have.
Give Fin an expert on your product
The DeployIt MCP server is in early access, as part of a design partner program: if you run Fin on a product that ships often, your use case is exactly the one we're building for — join the design partner program, or connect your repository now: it's free during early access.
Continue reading
Architecture Decision Records from Git: Always Current
ADRs go stale as soon as the code moves on. Derive them from git history so every decision record stays current, traceable and auditable — for humans and AI agents.
What Changed in the Product This Week?
The most useful question you can ask about a product — and why the reliable answer comes from your repo's real diffs, asked through Claude via MCP.
Why Doesn't Your AI Support Agent Know Your Product?
AI support agents answer from a frozen copy of your product, not from what you just shipped. Why that is structural — and how to ground them in your real code.