MCP, A2A and ACP in Practice: How a Bank Wires Tools and Agents Together

A string of model releases over the last few years has followed one script. A larger model appears, writes better code, reasons more cleanly and handles longer context. Within weeks the excitement cools, because a clever model alone in a chat window still cannot look up a customer's balance, put a hold on a suspicious transaction or fetch an applicant's credit history. Intelligence was never the real bottleneck. Connection was.

Engineering effort has moved away from raw model size and toward protocol design. Three specifications target the connection problem: MCP (Model Context Protocol), A2A (Agent-to-Agent) and ACP (Agent Communication Protocol). Between them they settle how a model reaches tools, how one agent reaches another, and how many agents share work without descending into chaos.

One example carries through everything below: a bank assembling an AI assistant that must spot fraud, assess loan applications and talk to core banking systems, while remaining auditable enough to satisfy a regulator.

Why a bare model needs protocols

Left alone, a language model only predicts text. Ask whether a customer's account shows suspicious activity this month and it will either decline or produce a fluent, wrong answer, since the real transaction ledger is outside its view.

Early fixes plugged models directly into REST APIs, one connector after another. A fraud assistant got custom code for the core banking API, more for the CRM and still more for case management. Small deployments coped. Larger ones ran into three problems:

• Nothing was reusable. The fraud team's core banking connector was no use to the loans team even though both needed identical transaction data, so each project started from zero.
• State disappeared between requests. APIs are stateless by design. An analyst who fetched a customer's transactions and, two questions later, asked about anything unusual in "that data" found that a plain API integration kept no link between the two requests, unless engineers built a memory layer by hand.
• Permissions were tacked on. Banking actions each require a permission check and a record for auditors. A junior fraud analyst can read transaction history but cannot approve reversing a wire. Wiring each API ad hoc made such fine rules easy to botch and hard to demonstrate to an auditor.

A protocol settles the contract once. No bank has to design its own method for a model to call the fraud engine, because MCP supplies a single interface. No team has to design its own way of passing a case from a Fraud Agent to a Compliance Agent, because A2A supplies another. HTTP did this for networked applications and SQL did it for databases: one shared language that lets independently built systems work together.

Five stages of design

System design has passed through five stages, in banking and elsewhere.

1. A plain LLM. The model answers from training data alone. It can explain what KYC is but cannot say whether a particular customer's profile satisfies the bank's KYC rules, because it never sees that customer's record.
2. Retrieval-augmented generation. The model connects to a document store such as the compliance manual and past regulatory guidance, so answers rest on current, private, organization-specific content and not on generic training knowledge.
3. Agents. The model can act as well as retrieve. A compliance assistant can now cite the KYC policy and also check a customer's documents on file against it, flagging any gap.
4. Multi-agent systems. One agent handling fraud detection, underwriting and customer messaging simultaneously becomes unreliable and hard to govern. The work is divided among specialists, such as a Fraud Agent, a Loan Agent and a Customer Communication Agent, each expert in one narrow field.
5. Protocols. Once there are many agents and many systems, a standard way is needed for them to discover each other, share context and communicate safely. MCP, A2A and ACP answer that need.

Most banks sit between the third and fourth stages today. Individual agents exist, often one per use case, yet without a shared protocol between them every new agent still demands more custom integration. Closing that gap is what the protocols are for.

Tool calling, the layer underneath MCP

Before MCP came tool calling, also known as function calling. It lets a model request an external action instead of only producing text, and MCP is built on top of it.

The mechanics are modest. For every available tool, a developer writes a JSON Schema giving a name, a description and typed parameters, and ships it to the model alongside the prompt. When the model concludes that a tool is required, it runs nothing. Its output is a structured JSON object naming the tool and supplying arguments, and the surrounding application executes the function and returns the outcome to the model. A banking schema looks like this:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

Say a fraud analyst asks to see a customer's recent large transactions, over five thousand dollars across the past month. Memory is not used to answer. The model instead emits a call to get_customer_transactions with the customer ID, the amount threshold and the date window. The application then queries the core banking database for real, passes the actual rows back, and the model turns them into a readable summary.

Plain tool calling handles a single model with a few hardcoded tools nicely. Trouble starts with dozens of tools scattered over core banking, fraud, CRM and document systems, with tools that must be added without redeploying each client, or with one tool that the fraud and loans assistants must share safely. MCP targets precisely those problems.

MCP in detail

MCP arrived from Anthropic in late 2024 as an open standard for linking AI applications to external systems. Think of a universal adapter. Previously, connecting a banking assistant to core banking, the fraud engine and the CRM took three incompatible integrations. Now any MCP-compliant client can talk to any MCP-compliant server, the way any USB device fits any USB port.

The arithmetic of M times N

The underlying problem is combinatorial. Connecting M tools to N applications produces a matrix that becomes unmanageable as both numbers grow. A bank with five internal systems and four assistants (fraud, loans, customer service, compliance) would need up to twenty custom connectors. A standard protocol reduces that to five plus four, since every system and every assistant implements MCP once.

Three roles

• Host: the AI application the user actually sees, for instance a fraud analyst's assistant interface.
• Client: a component inside the host that manages one connection to one MCP server and handles protocol-level communication.
• Server: the party exposing capabilities, meaning data or actions. A bank might run one server in front of core banking, another in front of the fraud engine and a third in front of the document repository, each maintained by the team that owns the system behind it.

Three primitives a server can offer

• Resources carry read-only data the model may bring into context, for example an account statement or the status of KYC documents. Like a GET request, they inform and change nothing.
• Tools perform actions, like freezing part of an account or sending a case to a compliance officer. Like a POST request they alter state, which makes them the primitives most in need of human approval gates at a bank.
• Prompts are reusable parameterized templates that guide the model toward a well-formed request. One example is a standard fraud-escalation prompt that every analyst assistant uses in the same way, so no team maintains its own slightly different copy.

Sampling, discovery and transport

Sampling lets a server ask the host's LLM for a completion, borrowing the model's reasoning for a sub-task. A document-store server might use it to have the model summarize a long loan agreement before returning it, with a human analyst still reviewing that summary before acting.

Discovery occurs when a client connects and asks a server what resources, tools and prompts it offers, which keeps MCP dynamic. Once the fraud team publishes a new tool for checking a customer's device history, every connected assistant can use it immediately, with no change to client code.

The wire format is JSON-RPC 2.0, over one of two common transports. Stdio suits a server running on the client's own machine. HTTP with Server-Sent Events, or streamable HTTP, suits a remote one. A core banking server inside the data center and behind the firewall would be reached over remote HTTP with proper authentication, not stdio.

Security

Regulated industries are where MCP earns its keep, though it supplies no controls automatically. It gives engineers one consistent place to build and enforce them rather than reinventing security per integration. A production banking deployment should:

• require OAuth 2.1 when clients authenticate to servers;
• give each tool only the permission it needs, so that a junior analyst's token cannot reach something like approve_wire_transfer;
• keep a log entry for every tool call;
• insist on explicit human confirmation before a state-changing call, such as freezing an account or releasing a hold.

What an MCP deployment looks like

Three layers make up a typical bank deployment. The host is the chat interface or agent runtime the user sees, such as an investigation assistant. An MCP client inside the host opens sessions with servers, sends discovery requests and passes tool calls back and forth. The servers each front a single system of record, say core banking, the fraud engine and the document store, and each is maintained and secured by the team that owns it.

A fraud investigation shows the request path:

1. An analyst wants every transaction above ten thousand dollars for a customer over the past thirty days, plus a check on whether the device fingerprint recently changed.
2. The host's LLM works out that two tool calls are needed and tells the client to run get_transactions on the core banking server and get_device_history on the fraud engine server.
3. The client issues JSON-RPC requests to both over HTTPS.
4. Each server verifies the analyst's OAuth scope and right to see that customer's data, queries its own backing system and answers.
5. The client passes both answers to the model, which combines them into one summary.
6. Everything, both calls, both replies and the analyst's identity, is written to the audit log.

A minimal Python server using the official SDK pattern shows how little code a tool needs:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

The two tools in it deserve different handling in practice. get_transactions is a read, Resource-like, and can run with no confirmation step. place_transaction_hold alters state in a real financial system, so it must never fire merely because the model asked. The application layer should route it through explicit analyst confirmation first.

Some habits keep production servers healthy:

• Give each server one system to wrap, not a monolith spanning core banking, fraud and CRM.
• Write tool descriptions the way documentation for a new analyst would be written, because the model decides when a tool applies purely from that text.
• Version tool schemas. Altering a required parameter on get_transactions without notice breaks every assistant depending on it, including those outside the fraud team.
• Assume every tool call is untrusted input to the downstream system and validate it, since a manipulated model output might otherwise try an unauthorized call.

A2A, agents talking to agents

MCP handles model-to-tool links. A2A, which Google introduced in 2025 and the Linux Foundation now maintains, handles a different link: one autonomous agent calling on another, particularly when different teams or vendors built them.

One agent is not enough because a single agent handling fraud, underwriting and communication grows into a sprawling system that is hard to govern, and proving to an auditor which logic decided what becomes very difficult. Specialists that delegate to each other are cleaner and safer.

Delegation runs on the agent card, a machine-readable statement of what an agent can do. It resembles an MCP server's tool list but describes the abilities of a whole agent, not individual functions. A coordinating Customer Assistant Agent reads the Fraud Agent's card and learns it can look into disputed transactions, reads the Loan Agent's card and learns it can judge refinancing eligibility, then chooses the right delegate for the customer's request.

Coordination defines how agents hand over tasks, stream partial results and report success or failure over a standard transport. Each side treats the other as a black box. The Customer Assistant Agent has no need to know how the Fraud Agent was built, whether it calls MCP tools on core banking, what model drives it or how many steps it takes. It needs only the agent's capabilities and a way to send it work.

Two banking cases illustrate it. First, a customer reports an unfamiliar five-hundred-dollar card charge and also asks about a better mortgage rate. The assistant handles neither itself. It sends the dispute to the Fraud Agent and the mortgage question to the Loan Agent, runs them side by side, then merges the answers into one reply.

Second, the Fraud Agent examines that charge, calling MCP servers for core banking and the fraud engine to fetch transaction and device records. When its confidence in a fraud verdict is low it avoids guessing and hands the case via A2A to a Compliance Review Agent, which applies stricter regulatory rules and, if necessary, passes it to a human compliance officer. Customer Assistant, Fraud Agent, Compliance Review Agent, human: that is the structured delegation A2A is built to carry.

ACP, the messaging layer

Where A2A concentrates on delegating tasks, ACP concentrates on the messaging beneath multi-agent conversations, especially state, memory and error handling over longer interactions.

• Architecture. Conversations become sequences of typed messages. Each message holds content plus metadata on its sender, its thread and the response it expects. A fraud-to-compliance escalation would therefore include more than the case itself: structured fields for case ID, requesting agent, urgency and expected reply type.
• Messaging. Structure displaces raw text, the way an email has a subject, sender and body and is not one blob of characters. With a dozen agents working a single loan workflow, each message has to reach the correct agent and the correct handler inside it.
• State. Underwriting that passes through an Eligibility Agent, a Risk Agent and an Approval Agent has to retain state over many exchanges. ACP sets conventions for attaching and updating shared state, such as passed checks and outstanding documents, so no agent loses sight of the application, even when the process runs for days.
• Memory. Short-term conversational memory, tied to the current application, is kept apart from long-term memory carried between sessions, for instance a customer's known preference for a fixed-rate mortgage, which should shape the conversation without a repeat question.
• Error handling. A failed agent call in banking cannot just disappear. Say the Risk Agent cannot fetch a credit report during a downstream outage. ACP specifies structured errors, which lets the coordinating Eligibility Agent choose between another attempt, a handoff to a human underwriter, or a pause, and keeps a partial or faulty decision from slipping out unnoticed.

How the five compare

Set side by side, the options differ along a few axes:

• What each connects. A plain API links one application to another. Tool calling links a model to a function. MCP links a model or app to tools, data and prompts. A2A links agent to agent. ACP links agent to agent at the message layer.
• Standardized across vendors. Plain APIs, no. Tool calling, partially. MCP, A2A and ACP, yes.
• Discovery of capabilities. None for plain APIs and tool calling. Dynamic for MCP, through agent cards for A2A, limited for ACP.
• Built-in state and memory conventions. None for plain APIs and tool calling, partial for MCP and A2A, and the primary focus for ACP.
• Banking illustration. Core banking talking to a CRM; an assistant calling one hardcoded balance function; an assistant discovering and calling core banking, fraud and document tools uniformly; a Fraud Agent delegating to a Compliance Review Agent; a multi-day loan approval tracking state across three agents.

These options are complements, not rivals. A production banking assistant will probably combine MCP to connect agents to core systems, A2A for delegation among specialists, and ACP conventions to hold long multi-agent workflows such as underwriting together from start to finish.

One customer message, end to end

Take a single message: the customer does not recognize a five-hundred-dollar charge and also wants to know about a better mortgage rate. The full stack responds step by step.

1. The customer sends the message to the AI Assistant, the host application inside the banking app.
2. Through A2A, the assistant hands the fraud question to the Fraud Agent and the mortgage question to the Loan Agent, and both run at once.
3. The Fraud Agent calls the CRM server over MCP for contact and complaint history and the core banking server for the disputed transaction. After applying its fraud rules it invokes the core banking server's place_transaction_hold tool, again over MCP. That call goes to a human analyst for confirmation before it executes, as it changes state.
4. The Loan Agent fetches current mortgage terms and the credit profile from core banking over MCP, compares them with current rate tables and drafts a recommendation. Offering a refinancing rate requires underwriter sign-off, so it executes nothing and hands its recommendation and supporting data to a summary meant for humans.
5. Both agents report back to the assistant through A2A, using ACP-style structured messages that carry case status, pending human approvals and findings.
6. The assistant uses MCP to send the customer an email confirming the hold, and records every tool call, handoff and decision boundary in the audit system, because regulators will expect exactly that trail if the case is reviewed.

Interoperability in a bank therefore looks like this: no single giant model trying to do everything, but specialist agents with governed tool access, each doing one job well, joined by a clean audit trail.

Security across agents and protocols

• Prompt injection. A hostile instruction concealed in a document, email or uploaded file can try to take over an agent's next move. Imagine a fraudulent dispute containing hidden text that orders the Fraud Agent to approve the claim without verification. MCP tools change real state, so the danger is practical. Countermeasures: treat all retrieved content as untrusted, never allow model output to trigger a high-risk tool such as place_transaction_hold without a policy check, and limit which tools the model can see in any given context.
• Authentication. Each MCP client-server link and each A2A handoff needs authentication, usually OAuth 2.1, so an anonymous caller cannot run a core banking tool or assign work to the Compliance Review Agent.
• Authorization. Authentication says who is calling, and authorization says what that caller may do. An authenticated Fraud Agent must still be refused a tool that approves a mortgage rate change, since that is outside its remit no matter how sure its reasoning feels.
• Zero trust. No link in the chain is trusted by default, neither the model, nor another agent, nor a downstream server. Policy is checked at the moment each call executes, not waved through because it started inside the bank's own AI system.
• Human approval. Actions with financial, safety or regulatory weight, like freezing an account, releasing a hold or approving a loan, pass through human confirmation. That is a design decision matched to the stakes and not a shortcoming of the technology.
• Audit trails. Log each tool call, delegation and state change in enough detail to rebuild what occurred and why. If a regulator asks why an account was held for six hours, the bank must be able to show the exact chain of agent decisions and tool calls, not an estimate.

Where it is heading

The direction of travel is easy to read. Protocols like MCP are becoming the device-driver layer of AI, a standard route from any model to any tool without bespoke glue. Expect AI operating systems to appear as a real category, where MCP-style servers are first-class infrastructure like databases and message queues, and a core banking server is something every internal AI project plugs into without rebuilding. Expect pre-vetted, audited server marketplaces, so a bank can adopt a compliance-approved KYC verification server instead of writing one. Expect governance tooling to grow around auditing MCP calls and A2A delegations, since compliance and risk teams will want that visibility before any of this touches real money. And expect the same patterns to reach well past banking, into any field where a reasoning system needs a standard, auditable way to act in the world.

The short version

A model on its own cannot check a balance, place a hold or evaluate a mortgage. MCP standardizes how it reaches tools, data and prompts, letting a fraud assistant and a loans assistant share one core banking server with no duplicated integration. A2A standardizes how specialist agents hand work to each other without learning each other's internals. ACP standardizes messaging, state and error handling beneath long workflows like a multi-day loan approval. At a bank these protocols are not mere conveniences. They are what makes authorization, audit trails and human approval enforceable at scale.

Two design rules fall out of this. MCP splits read-only resources from state-changing tools, and authorization design should follow that split, because checking a balance and sending a wire carry very different risk. And human approval gates plus audit trails around every protocol call are core requirements, so they belong in the first line of code and not in a later patch.