Why we bet on MCP for clariBI integrations

When we started building clariBI's integrations, we made a bet: that the Model Context Protocol (MCP) would become the common way AI tools talk to business software, and that building on it would let a small team support far more vendors than hand-written connectors ever could. This post explains the reasoning, what has happened since, and where the bet needed a second approach alongside it.

The problem MCP solved for us

Integration breadth quietly decides whether a BI tool is useful. Established tools support almost everything because they have spent many years building and buying connectors. A new tool starts with a handful and either spends years catching up or stays in a niche.

A small company's numbers are spread across its payment processor, CRM, project tracker, support desk, ad platforms and a spreadsheet or two. If the BI tool cannot reach three of those, the owner goes back to exporting CSVs.

Hand-written connectors are expensive to keep. Every vendor has its own authentication, pagination, rate limits and data model, and every one of them changes over time. Multiply that by a hundred vendors and the connector work consumes the team.

MCP changes that. A vendor that publishes an MCP server describes its own tools: their names, what they return and the inputs they take. clariBI connects to that server, discovers the tools, and uses them. Adding a vendor becomes a catalog entry and a review of its read tools, not a new client library to maintain for years. Authentication is standardized too: most MCP servers support OAuth 2.1 with Dynamic Client Registration, which is why connecting one is usually a single click. We explain that flow in OAuth 2.1 with DCR explained.

What happened after the first wave

The first catalog had 30 vendors, chosen from the tools small companies use most: Stripe, HubSpot, Linear, Notion, PostHog, Atlassian and others. Today the catalog has 86 active MCP apps. 52 are available from the trial up, 32 more from Starter, and two (dbt Cloud and Microsoft Dataverse) from Professional. The MCP integrations page lists them.

Two things we planned early on now exist:

• Custom MCP servers. On Starter and above, you can point clariBI at any MCP server by URL, including one your own team runs, with an API key or bearer token. Addresses inside private networks are refused.
• Data that stays for dashboards. An MCP app is used in two ways. When the source syncs, clariBI calls the vendor's read tools that return records and measures and stores the rows, so dashboards, reports and forecasts can use them. When you ask a question, clariBI can also call the vendor's tools during the answer.

Where MCP was the wrong fit

MCP works well when a vendor exposes tools that list and summarise your records: your charges, your deals, your issues. It fits less well for data where you have to choose what to fetch: stock symbols, coins, keyword sets, competitor domains. There is no "list everything" tool for the whole stock market.

For those vendors we built a second framework: REST API connectors driven by a declarative preset per vendor, where you pick the resources you want and clariBI syncs them on a schedule. Five vendors that started in the MCP catalog (Twelve Data, CoinGecko, Financial Datasets, Ahrefs and SE Ranking) moved to it. There are now 80 REST API connectors, and most of them come with an endpoint catalog generated from the vendor's own published API reference. The help article on REST API data sources explains how they work.

So the bet was right, but not alone. MCP for tools that know your records, REST connectors for data you select, and native OAuth connectors for Google, Meta Ads, Jira and Confluence. All of them feed the same dashboards and the same plain-English questions.

What did not change

Breadth was never allowed to cost the rules in our MCP security model:

• Read-only. Each vendor has an allowlist of read tools, and any discovered tool whose name suggests it creates, changes, deletes or refunds something is filtered out before a call is made.
• Encrypted at rest. Tokens and keys are encrypted with Fernet before they are stored, with a key kept outside the database.
• One organization per connection. A connection belongs to the organization that made it.
• Disconnect means disconnect. An Owner or Administrator can disconnect a vendor; the stored credentials are erased at once, the sources built on it stop syncing, and the connection record is deleted after 30 days.

And using it stays simple: click Connect, approve on the vendor's page, then ask questions.

The same bet in the other direction

MCP also runs the other way. clariBI has its own MCP server, so assistants such as Claude, Cursor and ChatGPT can list your dashboards, run an analysis or generate a report with your permission. It is available on the Trial, Starter, Professional and Enterprise plans. If MCP becomes the way people reach their business software from an assistant, a BI tool should be reachable that way too.

What we are watching

We are not promising dates, but three things will shape the catalog:

• Vendors publishing richer tools. Most MCP servers today offer list, search and fetch tools. As vendors add aggregate and time-window tools, answers get better without a clariBI release.
• Industry-specific tools becoming MCP-capable, such as booking, point-of-sale and learning systems.
• Your requests. A vendor people ask for moves up the list.

Try it

Start the 14-day trial (50 AI credits, no card), connect a tool you use every day, such as Stripe, and ask a question you would normally answer by exporting a CSV. If the tool your numbers live in is not in the catalog yet, tell us which one. For a primer on the protocol itself, read what MCP is.