The Model Context Protocol, plainly.

The problem MCP solves

Before MCP, every team that wanted an AI to do things invented their own plumbing. Custom tool-call schemas. Bespoke auth flows. One-off function shims for each model and each app. The result: brittle integrations, vendor lock-in, and a security story you didn't dare audit too closely.

The Model Context Protocol is a standard that defines, in one place, how a model discovers what it can do, how it asks to do it, and how the host enforces permission before anything happens. Think of it as the missing API contract between models and tools.

The three roles

• Host - the application orchestrating the conversation. In our world, that's CentralbrAIn itself. The host enforces permissions, handles approvals, writes the audit log, and routes the model's intent to the right place.
• Server - a process that exposes a set of capabilities (tools, resources, prompts) to the host. We call these bridges in our documentation. One bridge per app: a HubSpot bridge, a Stripe bridge, a Notion bridge. They speak MCP.
• Client - the part of the host that talks to a single server. The host typically runs many clients in parallel.

What a bridge actually is

A bridge is a small program that adapts your existing SaaS API into MCP-shaped capabilities. Concretely it does four things:

1. Authenticates against the underlying app on behalf of your org - usually OAuth, sometimes service account, occasionally API key.
2. Advertises tools the Brain may invoke (e.g. hubspot.create_contact, stripe.refund_charge) along with their parameter schemas.
3. Advertises resources the Brain may read (e.g. recent deals, open invoices, current sprint) without making a write.
4. Executes a tool call against the app and returns the structured result, surfacing errors in a way the host can interpret.

We ship bridges for the top 500 business apps out of the box. Custom and legacy systems get a custom bridge as part of an Enterprise engagement.

Where guardrails live

The protocol carries the intent; the host enforces the policy. A bridge advertises that it can delete a Salesforce record. CentralbrAIn decides whether this caller, in this org, on this row, with this approval may do so.

The policy layer is where the four tier-differentiator dials sit:

• Action power. Read-only · drafts only · limited write · full execution.
• Approval mode. Slack alerts · approval queue · governance rules.
• Data freshness. Hourly · real-time · predictive pre-fetch.
• Sovereignty. Shared cloud · isolated VPS · air-gapped Iceland.

Why we bet the company on MCP

We don't want to be the proprietary glue. MCP is open, vendor-neutral, and gaining adoption fast. Building on it means:

• New bridges arrive faster (we adapt; we don't reinvent).
• You're not trapped in our orchestration layer - your bridges keep working if you ever leave.
• Auditing the protocol is auditing one thing, not seventeen integrations.

Want the operational picture? Read the audit logs primer. Want the full handbook? Start here.