A customer writes in: "Does your platform retain my uploaded files after I delete them?" Fin answers from your help center: "No, files are deleted immediately and are not retained." The customer thanks Fin. Three weeks later, an audit by your security team finds that the actual retention policy, declared in your system's compliance artifact, is seven days for deletion-recovery and thirty days for legal-hold. The help center article was written two years ago. Nobody remembered to update it when the policy changed. Fin did not invent the answer; it read the source it was given. The source was stale.
This is the deep failure mode of support agents that pull from documentation. They are only as current as the documentation, and documentation is almost never current. The architecture that fixes it is not "write better help center articles." It is "give the agent a source of truth that updates when the system changes." Intercom's MCP connector support makes that shape reachable. Ribo is the connector that supplies the truth.
Documentation drifts. Declarations do not.
Documentation describes a product at a moment in time. The moment is usually six months ago, occasionally eighteen, rarely today. Every support agent that reads documentation inherits that drift. Fin is particularly good at being fluent with whatever it is given, which means it is particularly good at delivering fluent, confident, out-of-date answers.
The problem has a structural shape. Documentation is prose, written by humans for humans, updated only when somebody with the time and authority remembers. Declarations are artifacts, updated when the system they describe changes, reviewed through proposals, versioned. The two differ in freshness by definition. A support agent that reads declarations instead of, or alongside, documentation answers customers with a different level of accuracy.
Intercom Fin now supports custom MCP connectors through the Data connectors feature. Any MCP server can be added as a source, which means Fin can pull context not just from your help center but from whatever queryable truth surface you expose. Ribo is purpose-built to be that surface for declared product identity.
What changes when Fin reads declared intent
Ribo exposes a small set of read tools over MCP: search declared artifacts, retrieve a specific artifact, list artifacts in a project, walk relationships. When Fin has Ribo connected, its retrieval layer gains a source that is both more structured and more current than the help center.
Take the retention-policy scenario. With Ribo connected, Fin searches the declared artifacts for "retention" and "file deletion." It finds the intent artifact stating the product's retention behavior. It finds the glossary artifact that defines "deletion" and "legal hold" in the specific way this product uses them. The answer it returns to the customer cites the current declared policy: "Uploaded files are available for recovery for seven days after deletion and retained under legal hold for thirty days. After that, they are purged." The answer matches what the product actually does, because the artifact is maintained when the policy changes.
The support team does not have to rewrite documentation to get this right. They have to maintain declarations, which they were already doing for engineering and compliance reasons. Fin just reads those same declarations.
Role-appropriate projection for a support agent
This is the projection that matters most, because the consequences of getting it wrong are visible to customers. A support bot answering from the wrong DNA layer can cause real damage. Ribo's DNA splits into thirteen layers: intent, contract, algorithm, evaluation, escalation, pace, monitor, glossary, integration, reporting, compliance, constraint, and tradeoff.
For Fin, expose only three: intent, glossary, integration. Intent tells Fin what the product is supposed to do, at the level a customer experiences it. Glossary defines the product's vocabulary, so Fin uses words the same way your product team uses them. Integration names the external systems your product talks to, which is useful when a customer asks whether a feature connects to their tool.
Withhold every other layer. Compliance, constraint, algorithm, evaluation, monitor, reporting, pace, escalation, contract, tradeoff: none of these should be queryable by a support agent. Compliance artifacts may reveal gaps in your security posture; constraint artifacts describe what your system must not do; algorithm and contract artifacts describe implementation details customers have no reason to know; monitor, reporting, pace, and escalation are operational and internal. A leaked support-bot token must not be able to surface any of them.
This is the point of role-appropriate projection, and Fin is the clearest case for it. The support bot is the most externally-visible surface you will wire to Ribo. The projection has to reflect that.
How to wire it up
First, mint the support token in the Ribo console. Go to Agents, create an agent named intercom-fin-<workspace-id>. Set scopes to artifact:read. Set projectIds to the Ribo projects whose customer-facing behavior Fin should be able to answer about; exclude projects covering internal infrastructure. Set allowed_kinds to the three-layer support projection: intent, glossary, integration. Capture the bearer token. This token is the most sensitive of the integration tokens you will mint, because it is the one a compromise would expose to the widest audience. Store it accordingly.
Second, add Ribo to Intercom's custom MCP connectors. In Intercom, go to Settings → Integrations → Data connectors → Custom MCP. The fields:
| Field | Value |
|---|---|
| Name | Ribo (or a customer-recognizable name if Fin will cite the source) |
| URL | https://mcp.ribo.dev/context/mcp |
| Access token | Bearer token from the Ribo console |
Save the connector. Intercom's current documentation lists Custom MCP as available on US-hosted workspaces only, so teams on EU or AU regions will need to wait for regional availability or run the integration through a US workspace if their account structure supports it. Confirm current regional availability with Intercom before rolling this out more widely.
Once saved, Fin will include the Ribo source in its retrieval for new conversations. Test with the retention-style question before exposing to all customers: ask Fin directly about a behavior you know is declared in Ribo, and verify the answer cites the declared policy rather than the help center's older phrasing.
What the customer-facing change looks like
The shift is not dramatic per-answer; it is systemic. One wrong retention answer is an awkward conversation. A thousand wrong retention answers per quarter, compounding across every customer inquiry that touches a policy the help center has not caught up on, is a pattern of customer trust erosion that rarely traces back to its source. Connecting Fin to Ribo replaces the slow-moving source with one that updates the moment the declared policy changes.
The team that maintains the help center does not go away. Their job shifts to writing human-friendly explanations that sit on top of the declared artifacts. Fin reads the declarations for the answer; the help center exists for customers who read articles directly. Both stay current because the declaration is the thing that updates, and both surfaces derive from it.
What it's worth
Support is the product's promise, made operational. Every answer a support agent gives is a small contract with a customer. Answers grounded in documentation are only as current as the documentation. Answers grounded in declared intent are as current as the declaration, which is as current as the system itself. Wiring Fin to Ribo does not change how Fin works. It changes what Fin is reading. The downstream effect is a support function whose answers hold up to audit.
Fin speaks to your customers. Ribo gives it the same source of truth your engineers use. What the product promises, and what the support bot says, become the same sentence.