MCP Server
Let an AI model use your application as a tool source, with credentials and a capability ladder controlling what it may do.
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 and — if you let it — make changes.
Where to find it
The endpoint is served at /mcp on your install. There is no dedicated Architect Panel section; the credentials and their capabilities are configured through the MCP datastore, opened from All Datastores.
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, which express 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 more likely to be used correctly by a model than one that means "select from a table".
Why this is useful
It removes the integration step for AI. Rather than building a bespoke connector for each assistant, you expose the application once and any MCP-speaking client can use it under credentials you control.
What it is not
It is not a way to give a model unrestricted access to your database. Every call runs under a credential with a capability, and a credential with no rights to a datastore reaches nothing — the platform's own permission model still applies underneath.
Before enabling it
Decide what you actually want a model to be able to do, and start read-only. It is easy to raise a capability later and awkward to explain a change nobody intended.
Credentials and the Capability Ladder
Access is controlled by a credential and the capability it carries. The capabilities form a ladder, not a set of independent flags: each level includes everything below it.
Where to find it
Credentials and their capabilities are held in the MCP datastore, opened from All Datastores in the Architect Panel. There is no dedicated panel section for MCP.
The rungs
- None — no access. The default.
- Read — look things up.
- Write — create and change records, and everything Read allows.
- Admin — everything above, plus administrative operations.
Because it is a ladder, a credential with Admin can read without also being granted Read. The corresponding OAuth scopes are mcp:read, mcp:write and mcp:admin, and a broader scope implies the narrower ones as the specification requires.
Permissions still apply
Capability is a ceiling, not a grant. A credential carrying Write still only reaches datastores its underlying permissions allow — the two combine, and the more restrictive wins. This is what lets you issue a credential for one narrow purpose without it becoming a general key.
Issuing credentials
One credential per client and purpose. A shared credential used by three integrations cannot be revoked without breaking all three, and its log tells you nothing about who did what.
Start read-only
Give a new client Read and see what it does with it. Most useful AI integrations are read-heavy, and the ones that genuinely need Write are worth thinking about deliberately rather than granting by default.
Dynamic client registration
The server supports the standard dynamic registration flow, so a client can register itself rather than being configured by hand. Convenient, and worth understanding before you enable it — decide whether self-registration suits your risk appetite.
Tool Packs and Safe Exposure
Four curated tool packs ship — casework, CRM, documents and ERP — alongside the generic datastore tools.
Where to find it
Which packs a credential may use is set on the credential, in the MCP datastore opened from All Datastores.
Expose the smallest useful surface
Every tool you expose is something a model may attempt. A narrow, well-named set produces better results than everything at once, because the model is choosing from a shorter list of clearer options.
Curated packs over generic access
A pack expresses operations at the level the module works at. That is safer as well as more effective: an operation meaning "post a journal" carries the ledger's own rules with it, whereas raw write access to the journal table does not.
Think about the blast radius
Before granting Write, ask what the worst plausible outcome is if a model misinterprets an instruction. Creating a duplicate contact is recoverable. Posting to the ledger, sending messages to service users or disposing of records are not, and those deserve either read-only exposure or a human approval step in between.
Watch what is actually called
Review the call log after enabling a client, particularly early on. It tells you which tools are being used and how, which is the fastest way to spot a tool that is being misused or one that is exposed and never touched.
Personal data
Data reaching a model reaches whoever operates that model. Check where the provider processes it and whether that is compatible with what you told people in your privacy notice. This is a data protection decision as much as a technical one, and it belongs with whoever owns that in your organisation.