Model Context Protocol: standardised tool wiring for AI in regulated firms.

The Model Context Protocol is an open JSON-RPC 2.0 specification published by Anthropic in late 2024 and now maintained as an open standard. It defines how a host application that uses a language model connects to external context providers - data sources, internal APIs, document stores, pricing engines - through a uniform wire format instead of bespoke integration code. It is the LLM-era equivalent of Microsoft's Language Server Protocol, which standardised the wiring between IDEs and language tooling and collapsed an N-times-M integration problem into N-plus-M.

There are three actors. The host is the application the user trusts - in our case the Alpha Quant Agent runtime. Inside the host, one client per data source negotiates with one external server. Each server exposes three categories of capability: resources (readable data such as a document, a database row, a pricing snapshot), prompts (parameterised workflow templates the user can invoke), and tools (callable functions with a JSON-schema input contract and structured output). The host advertises its own client-side capabilities back to the server: sampling (the server may ask the host to run a model completion), roots (which filesystem URIs the server is allowed to see), and elicitation (the server may ask the user a follow-up question through the host).

Capability negotiation happens at connection time. Transport is JSON-RPC 2.0 over stdio for local processes and Streamable HTTP with Server-Sent Events for remote ones. The language model itself never speaks MCP - the host does, on behalf of the model, and only forwards filtered tool descriptions and tool results.

Every AI integration project in an asset manager hits the same wall: the connectors. Custodian portal, fund administrator extract, internal pricing engine, depositary feed, document store, risk grid, OMS - each one is a separate ticket, a separate auth flow, a separate maintenance contract, a separate auditor question. The connector layer typically swallows more budget than the model itself, and rots faster.

MCP collapses this by giving every data source a uniform contract: tools/list to discover what is available, resources/read to fetch data, tools/call to perform an action, all in JSON-RPC envelopes the host can log byte-for-byte. The pricing-engine connector and the prospectus-store connector now look the same on the wire, which means they can be reviewed the same way, monitored the same way and replaced the same way.

For the buyer that translates into three concrete outcomes: less bespoke connector code in the codebase, a single review pattern for the compliance team, and a structured audit row for every read and every action the AI ever performs against an internal system.

DORA Art. 28-30 requires firms to maintain an ICT third-party register, document the operational tasks supported by each provider, and demonstrate concentration-risk management. EU AI Act Annex IV section 6 requires the Technical File to document lifecycle changes to a high-risk AI system, including modifications to the tools and data sources it relies on.

An MCP host that logs every JSON-RPC call - method, server, payload hash, outcome, timestamp - produces exactly the artefact those articles ask for. The third-party register becomes the list of MCP servers. The lifecycle log becomes the log of capability negotiations and tool registrations. Combined with a perimeter-resident host and local inference, no MCP call leaves the firm without a structured audit row, and DORA conformance is a property of the wire format, not a quarterly report.

We expose each internal system as a single-purpose MCP server. One server for the pricing engine. One for the prospectus store. One for the risk grid. One for the OMS read view. Each runs as a process the firm operates - a container in the firm's tenancy, not a hosted endpoint at a vendor - and each declares its resources, prompts and tools through a JSON schema we version and check into the repository alongside the rest of the codebase.

The host is the Alpha Quant Agent runtime, configured per client. Capability negotiation is locked at connection time so the model is never offered tools the firm has not approved. User consent is enforced before any tools/call executes against a write-capable resource; for read-only resources the host still records the call but does not block it. The structured audit log is the source of truth - method, server, schema hash, request payload hash, response payload hash, model version, user id, timestamp - and feeds the firm's existing SIEM and audit tooling.

Because MCP is an open protocol, we are not asking the firm to take a bet on a single vendor's connector library. The same server contracts work with any compliant host, which matters under DORA Art. 28 (exit and substitutability) and under any internal model-risk policy that requires component-level replaceability.

Where the language model is involved at all - selecting a tool, parsing a response, drafting a follow-up - it runs inside the perimeter via local inference, keeping the AI-method footprint inside the same boundary as the data.

Do not draw MCP as 'the LLM connects directly to your data'. The model never speaks the protocol. The host does, and the host is where the consent and audit mechanisms live. A vendor diagram that hides the host is hiding the security model.

Do not let a third party run the host for you on shared infrastructure. The host is the trust anchor. Outsourcing it to a vendor SaaS reintroduces the concentration risk MCP was meant to dissolve.

Do not skip capability negotiation. A 'wildcard' server that advertises every tool to every client gives the model surface area you cannot prove was bounded; regulators read that as inadequate change control.

Do not treat the audit log as optional metadata. The log is the deliverable. If a tool call did not produce a structured row, it did not happen in a regulated environment.