In the previous article, I discussed the idea of tool contracts. The core idea was simple: an AI agent should not have vague, unconstrained access to financial data systems. It should interact with those systems through explicit capabilities. Each capability should have a clear purpose, input structure, output structure, evidence expectation, and policy boundary.

For example, instead of allowing an agent to freely query any database table, we may expose governed capabilities such as semantic lookup, evidence retrieval, lineage tracing, readiness assessment, mapping support, validation, and lifecycle explanation.

But tool contracts raise another question. Once these capabilities are defined, how should they be exposed to AI applications in a standard way? This is where MCP becomes relevant.

Why MCP Matters Here

MCP stands for Model Context Protocol. At a high level, MCP is a standard way for AI applications to connect to external systems. These external systems may include files, databases, APIs, business tools, workflows, prompts, or other services.

For my AI-native financial data foundation, the most interesting point is not MCP as a technology trend. The important point is architectural. MCP gives us a way to think about the interface between AI agents and the governed financial data foundation.

In the previous post, tool contracts answered this question:

What capabilities should an agent be allowed to use?

MCP adds another question:

How can those capabilities be exposed to AI applications through a standard interface?

A tool contract defines the shape and boundary of a capability. MCP provides a possible protocol layer through which that capability can be exposed, discovered, and invoked by an AI application.

So the sequence becomes:

Semantic foundation → tool contracts → MCP interface → agent workflow

Without a standard interface, every AI application tends to connect to tools in its own way. A financial data foundation may need to expose many different types of capabilities: searching semantic concepts, resolving financial terminology, inspecting dataset lineage, checking field-level mappings, validating trade records, assessing reporting readiness, explaining lifecycle events, retrieving evidence paths, generating transformation logic, comparing broker files with internal records, and identifying authoritative sources. If every AI application integrates with these capabilities differently, the architecture becomes hard to govern. A standard interface helps reduce this fragmentation.

How MCP Works at a Conceptual Level

At a conceptual level, MCP introduces a simple separation of responsibilities.

There is a host application, such as an AI assistant, copilot, IDE, desktop application, or agent platform. The host is where the user interacts with the AI system.

Inside the host, there is an MCP client. The client manages the connection to an MCP server.

The MCP server is the external system that provides context or capabilities. It could connect to files, databases, APIs, business applications, knowledge bases, workflow systems, or internal services.

The high-level pattern is:

AI application / host
  ↓
MCP client
  ↓
MCP server
  ↓
governed capability

The server does not simply expose everything behind it. It exposes selected capabilities in a structured way. The basic usage pattern is simple.

First, the AI application connects to an MCP server. Then it discovers what the server can provide. The server may advertise available resources, tools, and prompts. The AI application can then decide which context to read, which tool to invoke, or which prompt template to use.

For example, if a user asks:

Where can I find clean IRS notional data for valuation?

The AI application should not directly guess the answer. It may need to discover that the financial data foundation exposes governed capabilities for semantic lookup, data discovery, evidence retrieval, and readiness assessment.

The agent can then use those capabilities through the MCP interface.

The important point is that MCP standardises the connection pattern. It gives the AI application a common way to discover and use external context and capabilities.

But MCP does not decide what the financial concepts mean. It does not decide which dataset is authoritative. It does not decide whether a field is approved for valuation or reporting. Those decisions still belong to the financial data foundation behind the MCP server.

Who Builds the MCP Server, and Where Does It Sit?

A practical question is: who actually builds the MCP server?

The answer depends on who owns the capability being exposed.

If the capability is a generic external system, such as a file system, Git repository, database, ticketing system, or document store, the MCP server may be provided by a vendor, an open-source project, or the platform team that manages that system.

But for an AI-native financial data foundation, the MCP server should normally be built by the team that owns the financial data foundation itself. That matters because the MCP server is not just a technical connector. It becomes the controlled interface through which AI applications access governed financial capabilities.

In a bank, this could be owned by a financial data platform team, semantic data architecture team, AI platform team, or a joint team across data architecture, engineering, governance, and risk.

In my own architecture, the MCP server would sit on top of the governed financial data foundation. The pattern would look like this:

AI application / copilot / agent platform
  ↓
MCP client
  ↓
Financial Data Foundation MCP Server
  ↓
Semantic registry, knowledge graph, lineage, validation, governance services
  ↓
Curated datasets and source systems

A generic AI application provider may understand the protocol. But it does not know which dataset is authoritative, which field is approved for valuation, which trade attributes are restricted, which mappings require review, or which answers can be used for reporting. Those rules belong to the financial data foundation. So the MCP server should be built close to the semantic and governance layer, not close to the LLM. It should sit at the boundary between the AI agent layer and the governed data foundation.

This placement is important because the MCP server becomes a control point. It can decide which capabilities are visible, which inputs are allowed, which data can be accessed, which evidence must be returned, and which actions require human review.

In production, it would more likely sit behind enterprise controls such as identity management, role-based permission, audit logging, monitoring, policy enforcement, and approval workflows.

The Kind of Capabilities MCP May Eventually Expose

Conceptually, MCP could become a standard interface for exposing several types of governed capabilities.

One capability area is semantic lookup. An AI agent may need to resolve a user phrase, source field, or business term into a governed financial concept. For example, when a user says “IRS notional”, the agent should not guess from language alone. It should be able to ask the semantic layer what concept this refers to, how it is defined, and which product structures it belongs to.

Another capability area is evidence retrieval. An agent may need to understand why a concept, mapping, or answer is trusted. This requires access to definitions, approved mappings, source-system metadata, lineage records, validation results, and graph evidence paths.

A third capability area is data discovery. A user may ask where a particular type of data can be found, even if the request is expressed in non-standard language. The agent should be able to search across semantic concepts, datasets, source fields, product types, and use cases, rather than relying only on keyword matching.

Another area is readiness assessment. Before a dataset can be used for valuation, reporting, reconciliation, or risk, the agent may need to check whether the required concepts are present, whether mappings are approved, whether validation rules have passed, and whether the dataset is approved for that specific use case.

There may also be capabilities around mapping support, validation, lineage tracing, and lifecycle explanation.

But the important point is not the exact list of tools. The important point is the architectural pattern.

An AI agent should not directly improvise over databases, schemas, documents, and prompts. It should interact with the financial data foundation through governed capabilities.

MCP may provide a standard interface for exposing those capabilities, but the capabilities themselves still depend on the semantic model, knowledge graph, lineage, validation rules, and governance framework behind it.

MCP and Evidence-Based Answers

One of the core themes of this series is that AI-native financial data should not produce unsupported answers. A financial AI agent should not simply say:

This field looks like notional.

It should be able to say:

This source field appears to map to a governed notional concept.
The mapping is supported by field name, sample values, source-system metadata, 
prior approved mappings, and product-model context.
The evidence path is:
source field → semantic concept → product model → use case.

This kind of answer requires evidence.

MCP can expose capabilities that retrieve evidence, but the evidence itself must come from the graph, lineage store, semantic registry, validation engine, and governance metadata.

This is where MCP and GraphRAG can work together. GraphRAG provides grounded traversal across concepts, datasets, mappings, products, use cases, and evidence paths. MCP can expose those graph-grounded capabilities through a standard interface.

The AI agent can then call those capabilities instead of inventing an answer from the prompt alone.

Closing Thought

MCP is useful because it gives AI applications a standard way to connect to external context and tools. For an AI-native financial data foundation, this is important but not sufficient. The real value is not simply exposing tools to an agent. The real value is exposing governed financial meaning.

That meaning comes from the canonical model, semantic registry, knowledge graph, lineage, validation rules, evidence paths, and governance framework behind the interface.

This is the role MCP should play in the architecture: not the source of truth, but a standard interface to governed financial truth.

• *AI-Native Financial Data Foundation