MCP Server

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.

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 live in the MCP datastore, opened from All Datastores. Issued tokens are visible and revocable at Architect Panel → Integration & Connections → OAuth Tokens.

The four rungs

• None — no access at all. The default, and what an unrecognised credential gets.
• Read — look things up.
• Write — create and change records, and everything Read allows.
• Admin — everything above, plus administrative operations.

Because it is a ladder rather than a set of checkboxes, a credential with Admin can read without Read also being granted. The corresponding OAuth scopes are mcp:read, mcp:write and mcp:admin, and a broader scope implies the narrower ones — which is what the specification requires, and what client libraries expect.

Capability is a ceiling, not a grant

This is the most important thing to understand, and the thing most often misread.

A credential carrying Write does not thereby gain access to every datastore. It still reaches only what its underlying permissions allow. The two combine and the more restrictive wins.

That is what lets you issue a credential for one narrow purpose without it becoming a general key to the system: grant Write at the capability level, then grant the credential's identity rights to exactly one datastore, and that is all it can touch.

Issuing credentials

One credential per client and per purpose. A shared credential used by three integrations cannot be revoked without breaking all three, and its call log tells you nothing about which of them did what.

Name them for what they are for, not who set them up. "Service desk assistant — read" survives a staff change; "Dave's test key" does not.

Start read-only

Give a new client Read and watch what it does with it for a while. Most genuinely useful AI integrations are read-heavy — answering questions, summarising, finding things. The ones that truly need Write are worth thinking about deliberately rather than granting by default because it seemed simpler.

Dynamic client registration

The server supports the standard dynamic registration flow, so a client can register itself rather than being configured by hand. That is convenient and worth a deliberate decision: it means a client you have not individually configured can obtain a credential. Decide whether self-registration suits your risk appetite before enabling it, and review OAuth Tokens regularly if you do.

Worked example

A finance team wants an assistant that answers questions about the ledger but must never change it. A credential is created with the Read capability, and its identity is granted rights to the ledger datastores only. Even if a future change raised its capability to Write by mistake, it still could not touch casework — because the permissions, not the capability, decide what it can reach.

Revoking

Revoke through OAuth Tokens rather than deleting the credential row — revocation is immediate and leaves the history, whereas deletion loses the record of what that credential did.

Recommendations

• One credential, one client, one purpose.
• Read first, always. Escalate on evidence of need.
• Constrain by permissions, not by capability alone. Capability is the ceiling; permissions are the walls.
• Review issued tokens quarterly and revoke anything you cannot account for.

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 itself, in the MCP datastore opened from All Datastores.

What the packs contain

• Casework — finding cases, reading their state, and the operations a case handler would recognise.
• CRM — contacts, organisations and pipeline enquiries.
• Documents — locating and reading documents, including extracted text.
• ERP — ledger, stock and document enquiries expressed in ERP terms.

Each pack is a handful of well-named tools rather than dozens, which is deliberate.

Expose the smallest useful surface

Every tool you expose is something a model may attempt to use. A narrow, clearly named set produces markedly better results than everything at once, because the model is choosing from a shorter list of less ambiguous options.

This is a quality argument as much as a security one. Models pick badly from long menus, and a wrong tool choice produces a confident wrong answer.

Prefer curated packs to generic access

A pack expresses operations at the level the module works at, which is safer as well as more effective. An operation meaning "post a journal" carries the ledger's own rules with it — balancing, period checks, immutability. Raw write access to the journal table carries none of them.

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 in a minute.
• Posting to the ledger is a reversing entry and an awkward conversation.
• Sending messages to service users cannot be recalled.
• Disposing of records cannot be undone at all.

The last two deserve either read-only exposure or a human approval step in between — and the approvals mechanism already exists for exactly this.

Watch what is actually called

Review the call log after enabling a client, particularly in the first fortnight. It tells you which tools are being used and how — the fastest way to spot both a tool being misused and a tool you exposed that nothing ever touches. Remove the latter.

Personal data leaves the building

Data reaching a model reaches whoever operates that model. Check where the provider processes it, what they retain, 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 — not with whoever is configuring the credential. For casework data in particular, get it in writing before you enable anything.

Worked example

A housing team exposes the casework pack read-only to an assistant used by the duty desk. Documents are deliberately not exposed, because tenancy files contain third-party information the team does not want summarised by an external model. When the team later wants case notes drafted, they add write access to a single notes datastore rather than the whole pack.

Recommendations

• Start with one pack. Add a second only when something concrete needs it.
• Never expose a pack "to see what it does" on production.
• Put approvals in front of anything irreversible.
• Re-read the call log monthly once it is live.