MCP vs API: What Changes When an AI Agent Is the Caller

TL;DR: An API is a contract a developer reads and codes against; MCP (Model Context Protocol) is a standard way for an AI application to discover and call tools at runtime. MCP does not replace APIs: most MCP servers are a thin layer over an existing API. Use the API when your own code makes the call; add MCP when an AI agent decides which call to make.

MCP vs API is not a choice between two rival technologies. An API (application programming interface) is any defined interface one program uses to call another, usually REST over HTTP with endpoints documented in OpenAPI. MCP is one specific open protocol, released by Anthropic on 25 November 2024, that standardises how AI applications such as Claude, ChatGPT, Cursor and VS Code find out what a service can do and call it, using JSON-RPC 2.0 messages. The practical difference is who reads the documentation: with an API, a developer does, once, and writes code; with MCP, the model reads tool descriptions at runtime and chooses what to call.

What is the difference between MCP and an API?

The difference between MCP and an API is the consumer. An API is designed for a programmer who knows in advance which endpoint to call; MCP is designed for a language model that has to discover the available actions, understand their inputs from a schema, and pick one in the middle of a conversation.

Sources: MCP specification 2025-11-25 and its transports, tools and authorization pages, checked 25 October 2026.

How does MCP work?

MCP works as a three-part chain. The host is the AI application (Claude Desktop, Claude Code, ChatGPT, Cursor). Inside it, an MCP client holds one connection to one MCP server, which wraps a service. The design borrows from the Language Server Protocol, which did the same for programming languages in code editors.

A server can offer three kinds of things:

• Tools: functions the model can call, such as calculate_gst or create_invoice.
• Resources: data the user or model can read, such as a file or a record.
• Prompts: templated messages a user can pick.

Clients can offer servers three things back: sampling (the server asks the host's model for a completion), roots (filesystem or URI boundaries) and elicitation (the server asks the user for more input).

A session starts with initialize, where both sides state a protocol version and their capabilities. The client then calls tools/list to get every tool's name, description and inputSchema (JSON Schema, 2020-12 by default), and tools/call when the model chooses one.

Which transports does MCP use?

MCP defines two standard transports. stdio runs the server as a local subprocess and exchanges newline-delimited JSON-RPC messages over standard input and output; it suits tools that touch local files. Streamable HTTP exposes one endpoint (for example https://example.com/mcp) that accepts POST and GET, optionally streaming with Server-Sent Events. Streamable HTTP replaced the older HTTP+SSE transport from protocol version 2024-11-05. The spec requires servers to validate the Origin header and return HTTP 403 for an invalid one, to block DNS rebinding, and says local servers should bind to 127.0.0.1, not 0.0.0.0.

What does the same call look like as an API and as MCP?

The clearest way to see MCP vs API is one operation done both ways. LuckPanda exposes its free GST calculator as a REST endpoint and as an MCP tool on a public, no-auth server. Both calls below were run on 25 October 2026 and return the same numbers.

As a REST API call, your code picks the endpoint and the parameters:

curl "https://luckpanda.app/api/public/calc/gst?amount=10000&rate=18&mode=add&supply=intra"

{"currency": "INR", "rate_percent": 18, "amount_before_gst": 10000, "gst": 1800, "amount_including_gst": 11800, "components": [{"name": "CGST", "rate_percent": 9, "amount": 900}, {"name": "SGST", "rate_percent": 9, "amount": 900}]}

As an MCP tool call, the client first lists tools, then sends a JSON-RPC request to the single MCP endpoint:

curl -X POST https://luckpanda.app/mcp/public -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "calculate_gst", "arguments": {"amount": 10000, "rate": 18, "mode": "add", "supply": "intra"}}}'

{"jsonrpc": "2.0", "id": 2, "result": { "content": [{"type": "text", "text": "Before GST ₹10,000.00, GST ₹1,800.00 (CGST 9% + SGST 9%), including GST ₹11,800.00."}], "structuredContent": {"gst": 1800, "amount_including_gst": 11800}, "isError": false}}

Three differences show up. The MCP response carries a plain-text content block for the model to read plus structuredContent for programs; the REST response is data only. The MCP request goes to one endpoint with the operation named in the body, not in the URL. And nobody wrote code that knew calculate_gst existed: an agent finds it through tools/list. In practice you never type the MCP request; you register the server once, for example claude mcp add --transport http luckpanda-tools https://luckpanda.app/mcp/public, and the host makes these calls. The GST calculator page shows the same calculation for people.

How do authentication and security compare?

Authentication in a REST API is whatever the vendor chooses: an API key in a header, OAuth 2.0, or a signed request. MCP makes authorization optional; when a remote server uses it, the spec requires OAuth 2.1, with the server acting as a resource server and publishing OAuth 2.0 Protected Resource Metadata (RFC 9728) so the client can find the authorization server. Servers on stdio should not use that flow and take credentials from the environment instead.

The bigger security difference is not the token; it is who decides to act. With an API, a developer decided at build time which calls the program makes. With MCP, a model decides at runtime, so a malicious tool description or a prompt injection in a document can steer it. The spec says tool descriptions and annotations should be treated as untrusted unless the server is trusted, and that there should always be a human in the loop able to deny tool invocations. Two rules follow for any business system:

• Give the agent's key the same permission checks as a person's, never a broader service account.
• Keep irreversible actions behind a human. Let the agent draft; let a person issue, send or pay.

LuckPanda is built this way: its REST API (/api/v1) and its account MCP server run the same commands as the app with the same permissions, each change records the agent as its author, and agent keys cannot issue, send or pay. The agents page has the connection steps.

When should you use MCP, and when an API?

Use a plain API when the call is fixed and your code makes it; add MCP when an AI agent has to choose among actions.

Choose the API if:

• a scheduled job, webhook handler or backend makes the same call every time (nightly sync, invoice export);
• you need precise control of retries, rate limits and idempotency keys in your own code;
• latency matters and an extra protocol hop is waste;
• no language model is involved.

Choose MCP if:

• users work inside an AI application (Claude, ChatGPT, Cursor, VS Code) and want it to act on your service;
• the right action depends on the conversation, so the model must pick among many tools;
• you want one integration to work across every MCP-capable host instead of one plugin per host;
• the tool list changes and clients should pick up new tools without a release.

Most production setups use both. The service keeps its REST API as the source of truth and ships an MCP server that maps a curated set of tools onto it. Exposing every endpoint as its own tool is a common mistake: every tool description takes space in the model's context and near-identical tools are easy to confuse, so group endpoints into task-shaped tools with clear descriptions.

Does MCP replace APIs?

MCP does not replace APIs; it depends on them. An MCP server is usually a wrapper that translates tools/call into calls to an existing REST or GraphQL API, a database, or local files. What MCP replaces is the custom glue: before it, each AI application needed its own plugin or function-calling schema for each service. With MCP, a service writes one server and every compatible host can use it.

For the business side of letting agents act, the delegated authority matrix guide shows how to give an agent a role with limits, and the invoice approval process covers where a human must sign off.