Model Context Protocol (MCP)
Published on
29/09/2026
Updated on
29/09/2026
Reading time
2 min
As of 29 September 2026
Definition
The Model Context Protocol (MCP) is an open standard for how an AI application reaches tools and data sources. It does not describe what a language model can do, but how the application around the model is connected to a business system. Anthropic published MCP in November 2024 and handed it over to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025. It is maintained through an open proposal process; the version currently in force is published on modelcontextprotocol.io.
Distinction
MCP is most often confused with an API. An API is the interface of the business system itself; MCP is the convention in which an upstream server describes that interface for a language model – including when a call makes sense. Nor is MCP an agent framework: it governs how tools are offered, not how an agent plans or decides. And it is not a transmission procedure in the sense of EBICS; underneath it sits JSON-RPC over stdio or HTTP.
How MCP works
Three roles: the host is the AI application. For every server it connects to, it creates a client that holds exactly one session. The server encapsulates one system and offers three kinds of building block: tools (calls that act), resources (content that can be read) and prompts (prepared working instructions). When the connection is established, both sides negotiate which capabilities the session has. A server either runs locally alongside the application or as a service on the network.
The connection also carries traffic the other way: through sampling, a server asks the client to have a model response generated; through elicitation, it requests input from the user. Both run through the host, which presents the request and allows it to be declined. Credentials must not be requested through the form, only through an address outside the client that the user confirms beforehand.
Security and control
The architecture draws the line at the host: it enforces approval, and a server sees neither the whole conversation nor the other servers. The specification explicitly requires a server to accept only tokens that were issued to it; passing through someone else’s tokens is forbidden. Further named risks are the confused deputy problem with upstream OAuth servers, session hijacking, and locally executed servers from unknown sources. Rights should be cut narrowly rather than granted as a blanket permission.
What it means for banks and payment service providers
MCP promises that one connection per system is enough, instead of one per application. That is of interest wherever every evaluation is built individually today: account information, format checks, status enquiries, rulebook research. MCP does not solve the authorisation question – a server reaches exactly what its technical access allows; rights management stays in the business system. For operations this means: run servers in house, log approvals, and establish beforehand which data leaves the application.