What the MCP Server Does
The Model Context Protocol lets an AI model use an external system as a source of tools. The MCP server makes your install one of those sources, so a model can look things up in your data and — where you permit it — make changes.
Where to find it
The endpoint is served at /mcp on your install. There is no dedicated Architect Panel section for MCP; credentials and their capabilities are held in the MCP datastore, opened from All Datastores.
Two related screens do exist and matter for authentication: Architect Panel → Integration & Connections → OAuth Tokens shows issued tokens and lets you revoke them, and OpenID Connect Provider configures the install as an identity provider where a client authenticates that way.
MCP and A2A are different things
Both let something outside your install do work with it, and the distinction is worth being precise about because it decides which you should use.
- MCP — a remote model drives your tools and does its own reasoning. It is stateless: every request carries everything it needs, and nothing persists between calls.
- A2A — a remote agent hands you a goal and you decide how to reach it. It is stateful: a task is a durable object with a lifecycle that outlives the request that created it.
They compose rather than compete. A2A is the front door; the MCP tools are the hands. An agent can delegate "chase the overdue Borden invoice" through A2A, and the work of finding and updating that invoice happens through the same tools MCP exposes.
What it exposes
- Generic datastore tools — read and, where permitted, write your datastores.
- Curated packs — purpose-built tool sets for casework, CRM, documents and ERP, expressing operations in the language of those modules rather than as raw table access.
Prefer the curated packs where they cover what you need. A tool that means "find the case for this party" is far more likely to be used correctly by a model than one that means "select rows from a table".
Why this is useful
It removes the integration step for AI. Rather than building a bespoke connector for each assistant somebody wants to use, you expose the application once and any MCP-speaking client can use it under credentials you control and can revoke.
What it is not
It is not a way to give a model unrestricted access to your database. Every call runs under a credential carrying a capability, and — critically — the platform's own permission model still applies underneath. A credential with no rights to a datastore reaches nothing, whatever its capability says.
Worked example
A service desk team uses an AI assistant to answer "how many open cases does the housing team have, and which are overdue?". A read-only MCP credential exposes the casework pack. The assistant calls two tools and answers from live data, with no export, no copy of the data outside the platform, and an audit trail of what it asked for.
Recommendations
- Start read-only. Raising a capability later is easy; explaining a change nobody intended is not.
- Decide what you want a model to do before you enable anything, rather than exposing broadly and narrowing later.
- Use MCP for lookups and A2A for delegated work. Reaching for the wrong one produces awkward integrations.
- Check the data protection position first — data reaching a model reaches its operator.