What is MCP, and how does it differ from an API
MCP is short for Model Context Protocol, an open protocol for connecting an AI application to external data and tools. An API is the interface one system defines for itself. MCP is the shared way an AI application and a server discover and call tools, resources, and prompts. An MCP server may still call an existing API. Using MCP does not remove that API’s permissions, and it does not remove the need for a person to agree before a tool runs.
On this page
What the specification says
The Model Context Protocol specification dated 28 July 2026 describes MCP as an open protocol that lets an LLM application connect to external data sources and tools in a standard way. The same page says the protocol uses JSON-RPC 2.0 messages, and names three roles: hosts (LLM applications that initiate connections), clients (connectors inside the host), and servers (services that provide context and capabilities).
The specification lists three kinds of capability a server may offer a client: resources (context and data for a person or a model), prompts (templated messages and workflows for a person), and tools (functions for the model to execute). The project introduction defines MCP as an open standard for connecting AI applications to external systems, and names data sources, tools, and workflows as what gets connected.
An API is still that system’s own interface
An API is defined by the provider of that system: which operations exist, which address to call, and which credential to send. If the accounts package, the file store, or the messaging system already has an API, creating a record or reading a file still goes through that interface.
An MCP server can wrap “call this API” as a tool, so the AI application discovers the tool and proposes the call in the same way it would for any other server. The tool’s inputs and permissions still have to match the rules that API already has. Changing the protocol does not replace the account and the authorisation behind it.
A person agrees before a tool runs
The security principles on that specification say a host must obtain the user’s explicit consent before invoking any tool, and that the user should understand what the tool does before authorising it. Tools can execute code, so a description taken from an untrusted source should not be treated as fact.
That is the same boundary as sending a reply straight to a customer, or posting an amount straight into the books. The specification says the protocol itself cannot enforce these principles. The application has to build consent, authorisation, and access control.
Write the process down before connecting anything
If the process and the location of the data are not written down, connecting MCP only adds another door that can act. Test the operation on a small real sample first, then decide whether to connect it to the identity and the data you already run.
In that assessment, write which API remains the source of record, which tool may propose a call, and which result must stop for a person. Leave those three unwritten, and do not attach the tool to a system that changes records.