Model Context Protocol

MCP onIntelliBooks

One protocol between your agents and everything they need to touch. We run the gateway that discovers the tools, holds the credentials and records every call.

28
MCP servers
4
Server tiers
JSON-RPC 2.0
Transport
How It Works

Register, discover, authorize, route

The gateway sits between your agents and your systems. Agents never hold credentials and never talk to a tool directly.

01

Register the server

Add an MCP server to the gateway registry — one we already maintain, an open-source stdio server, or one we write for your internal system.

02

Discover the tools

The gateway queries the server for its tool manifest, so agents see the current capability set rather than a hand-maintained list that drifts.

03

Authorize per user

OAuth runs through Nango and the resulting connection is scoped to the individual, so two people using the same server never share a token.

04

Route and audit

Tool calls travel as JSON-RPC 2.0 through the gateway, which logs the caller, the server, the arguments and the result for every invocation.

Connect in seconds

Servers we already run and maintain. Anything missing, we build — and it joins the same registry with the same authorisation and audit.

Production

Tier 1 — hardened, in daily use
DatabaseGitHubGmailSlackZoomZoho MailClickUpGoogle Calendar

Secondary

Tier 2 — data and delivery tooling
dbtAirflowMicrosoft TeamsGoogle DriveJiraNotionAzure DevOpsNeo4jBrave Search

Specialist

Financial, market and warehouse systems
DatabricksTrinoBloombergApolloTwilioMicrosoft GraphOMSReference Data

Open source

Supervised stdio servers
PostgresSQLiteFilesystemFetchPuppeteerMemorySequential ThinkingGoogle MapsSentry
Both Directions

It works where your teams work

MCP is not only how agents reach your tools. The gateway can publish your agents and knowledge base as an MCP server, so they appear inside whichever AI client your teams already have open.

Build the retrieval and the guardrails once, then use them from your own product, from a chat client, or from an IDE — without a second integration to maintain.

One gateway, two directions
Inbound

Your agents call GitHub, Slack, Jira, dbt, Databricks and your internal systems.

Outbound

Your agents and knowledge base are exposed as an MCP server for other AI clients to call.

One policy layer

Authorisation, rate limits and audit apply the same way whichever direction the call arrives from.

What makes it safe to put in production

Tool calling is where agents stop being read-only. These are the controls that make that acceptable.

Runs on your infrastructure

The gateway is a service you deploy, not a hosted middleman. Tool traffic and credentials stay inside your own network boundary.

Per-user connection isolation

Each agent can hold a different OAuth token for the same server via its connection ID, so an agent inherits the permissions of whoever it acts for.

Custom servers for internal systems

Where no MCP server exists — a core banking API, a policy administration system, an internal warehouse — we write and maintain one.

Full call audit trail

Every tool call is recorded with its caller, arguments and result, which is what turns an agent from a demo into something that passes review.

Frequently asked questions

Common questions about running MCP in an enterprise estate.

MCP is an open standard for connecting AI models to tools and data. Instead of writing a bespoke integration per model and per system, a tool is exposed once as an MCP server and any MCP-aware agent can discover and call it.
No. MCP is a standard, so servers we build for you work with any MCP-compatible client. The gateway is useful on its own as the routing, authorisation and audit layer in front of your tool estate.
28 server implementations across four tiers: eight production servers, nine secondary, a set of specialist financial and data servers, and sixteen open-source stdio servers the gateway can supervise directly.
We write one. That is routine work for us — most enterprise systems worth connecting are internal, so a bespoke server is the normal case rather than the exception.
OAuth flows run through Nango and tokens are stored against a per-user connection record. The gateway resolves the right connection at call time, so tokens are never embedded in an agent definition.
Yes, in both directions. As well as consuming MCP servers, the gateway can expose your agents and knowledge base as an MCP server so they appear inside whichever AI client your teams already use.

Let's connect your tools

Tell us which systems your agents need to reach. We will tell you what already has a server, what needs one built, and what it takes to run it safely.