MCP in finance: the Model Context Protocol explained
What the Model Context Protocol (MCP) is, how it works, and why it matters for financial institutions connecting AI agents to systems of record — safely.
6 min read
What MCP is
The Model Context Protocol (MCP) is an open standard that lets AI agents call external tools and data sources through a uniform interface: each capability is exposed by an MCP server, with declared input and output schemas, and any MCP-compatible agent can discover and invoke it. Open-sourced by Anthropic in late 2024, it has rapidly become the common connectivity layer of the agent ecosystem — often summarized as doing for AI-tool integration what USB did for peripherals.
Before MCP, every agent-to-system connection was bespoke: custom function-calling glue per model vendor, per application, per data source — an N×M integration matrix that made every new agent or tool a project. MCP collapses the matrix: build one server per system, and every compliant agent can use it; build one agent, and it can use every approved server.
How it works, briefly
MCP is a client–server protocol. The agent side (client) connects to one or more MCP servers; each server publishes the tools it offers — name, description, JSON-schema-typed parameters and results — plus optionally resources (readable data) and prompts (reusable templates). At runtime the agent's harness presents these tools to the model, the model requests calls, and the server executes them and returns structured results. Transport options include local processes and HTTP-based connections for remote servers (Streamable HTTP in current revisions).
Three properties matter more than the wire details. Tools are declared: what an agent can do through a server is enumerable in advance, not discovered in logs afterwards. Contracts are typed: inputs and outputs validate against schemas, so integration errors fail loudly. And the protocol is model-agnostic: the same servers serve agents built on any provider's models, which keeps the tool investment portable across model choices.
Why MCP matters for financial institutions
Finance adopts integration standards when they reduce risk and audit cost — and MCP's design is unusually aligned with that filter:
- Reviewability — a security team can read an MCP server's tool list and schemas as a complete statement of what an agent could reach through it; ad-hoc API glue offers no equivalent artifact.
- Permissionability — because every action is a named tool with typed parameters, per-tool policies (allow, require approval, deny) attach naturally, and approvals reference exactly what was requested.
- Auditability — tool calls and their structured inputs/outputs are uniform events, ready for tracing and reconstruction across every system the agent touches.
- Vendor neutrality — tools built once serve any model provider's agents, weakening the lock-in by which agent capability ties you to one AI ecosystem.
- Domain encapsulation — systems of record can expose semantically meaningful operations ("get break detail", "validate business rule") rather than raw database access, keeping domain logic where it belongs.
MCP in the wild on the buy side
Adoption in investment management became visible in 2025. FINBOURNE announced "compliant agentic AI for the investment industry — powered by MCP" in June 2025, integrating its LUSID platform with Anthropic's Claude so permission-aware agents can access live investment data. Platform vendors more broadly have begun exposing product capabilities as MCP servers — reconciliation context, data-management operations, document stores — so that agents act on systems of record through governed, typed interfaces rather than screen-scraping or raw SQL.
The strategic reading: as agents become a procurement category, MCP support is turning into the interoperability question buyers ask by default — both "can your agents use our existing MCP tools?" and "do you expose your product's capabilities as MCP servers we could reach from elsewhere?" Vendors answering yes to both keep their clients' options open; vendors answering no are selling a silo.
What MCP does not solve
MCP standardizes connectivity; it deliberately does not provide governance. The protocol will connect an agent to any server it is pointed at — including a malicious one — and a tool's schema says nothing about whether calling it is wise. Production deployments in regulated environments therefore wrap MCP in controls: a curated registry of approved servers (arbitrary endpoints rejected), security review before admission, OAuth and credential handling through vaults rather than configuration files, per-tool allow/ask/deny policies, namespacing so internal and external tools are distinguishable, and full tracing of every call.
It is also not a workflow engine or an agent framework: MCP says nothing about how agents reason, how runs are bounded, or how quality is evaluated. Those remain platform concerns. The clean mental model: MCP is the standardized socket; the platform decides what may be plugged in, by whom, under which policy, with what evidence.
FAQ
Frequently asked questions
Is MCP tied to Anthropic's models?
No. Anthropic open-sourced the protocol, but it is model-agnostic by design: MCP servers serve agents built on any provider's models, and the specification is developed openly. That neutrality is precisely why it works as an industry integration layer.
Is it safe to connect MCP servers to production financial systems?
It is as safe as the controls around it. The pattern that passes review: product-owned servers exposing narrow, semantically scoped tools (not raw database access), admitted through a security-reviewed registry, called with scoped credentials from a vault, gated by per-tool policies, and fully traced. The protocol enables this discipline; the platform must enforce it.
How does MCP differ from a normal REST API?
MCP is a meta-layer over capabilities: it standardizes how tools are discovered and described (typed schemas a model can read) and how agents invoke them, regardless of what sits behind — REST, databases, files. You typically implement an MCP server as a thin, governed facade over existing APIs.
What are A2A agent cards, and how do they relate to MCP?
They address adjacent problems: MCP standardizes how agents call tools; A2A (agent-to-agent) conventions like agent cards standardize how agents describe their own capabilities so other systems can discover them. Platforms increasingly support both — MCP for acting, agent cards for being found.
Should we build MCP servers for our internal systems?
If you expect agents to act on those systems, yes — it is the highest-leverage integration work available: one typed, reviewable server per system, reusable by every approved agent regardless of model vendor. Start with read-oriented tools for investigation use cases, and add gated write operations only behind approval policies.
In NeoXam Agents
MCP-native by construction
In NeoXam Agents, every tool an agent can call is an MCP server — there is no other kind. NeoXam products expose their data and actions through product-owned MCP servers (Aro break context, DataHub search, business-rule engine operations), declared in the Git-governed catalog under explicit namespaces, with per-tool allow/ask/deny policies and per-run signed tokens on every call. Third-party tools are admitted only through a curated, security-reviewed registry — arbitrary MCP endpoints are rejected — and every agent publishes an A2A-compatible agent card for discovery. Open standards throughout: MCP, A2A, OIDC, OpenTelemetry.
Keep reading