As MCP gained popularity, a bold slogan started circulating: APIs are no longer needed. The video grounds this question in e-commerce. When a customer opens the orders page, the app calls an orders interface and renders the returned record on screen. The question is why MCP was born at all while this setup works.
The checkout flow reads like a summary of the traditional model. The app first calls a payment interface, then issues an inventory update, and finally reaches an email interface for the confirmation message. The developer decides which call happens when and in what order. Because the flow is baked into code, it arrives predefined and rigid.
The picture breaks once the user phrases a sentence instead of pressing buttons. The model can grasp a request like find my latest order and email me the tracking details, yet it has no map of the available interfaces. It cannot tell which one runs first or which inputs each expects. Feeding the model the whole interface documentation is sensible to nobody.
Two concepts get clarified at this point. A tool is a single action an AI application can take: searching, drafting, and sending on the mail side, or fetching history and opening records on the repository side. An MCP server is the program publishing such capabilities through the model context protocol: action-bearing tools next to information-bearing resources like files, documents, or records.
Back in the e-commerce example, the picture clicks into place. The customer, orders, and email interfaces stay exactly where they are; nothing gets replaced. An MCP server layered above them offers three tools: fetch the customer, fetch the latest order, send an email. When a request arrives, the application connects to the server and learns the tool catalog, with each entry explaining its purpose and expected inputs.
Reading the request, the model lines the tools up: customer first, latest order next, email last. Behind the curtain, each tool calls its matching interface, collects the result, and hands it back to the application. Existing systems keep running untouched. MCP presents current capabilities as AI-friendly tools.
The closing distinction forms the backbone of the piece. With classic interfaces, developers define the flow and freeze it in code; in the MCP arrangement, developers publish capabilities as tools and the model picks. Discovery differs the same way: developers read documents and hunt for endpoints, while the MCP server broadcasts standard tool definitions. When a cancel-order tool appears tomorrow, the next connection simply discovers it.
AI commentary
"In my view, the most valuable line is the framing of the MCP server as an adapter: the most realistic way to bring AI into the loop without touching legacy systems."
AI assessment
To steelman the other side: models could already reach interfaces through function calls, and OpenAPI schemas offered machine-readable definitions. Seen through that lens, MCP looks like an extra layer over a solved problem. In simple integrations, that layer can add latency and upkeep without measurable gain.
Untested sides remain. Real code, failure handling, authentication, versioning, and latency cost under heavy traffic never enter the frame. Independent reviews gather the protocol's production limits under exactly these headings: dropped connections, bloated tool catalogs, and context cost across long sessions. Each heading deserves its own trial before any commitment.
The trust picture is harsher. Because the server authors its own tool definitions, a hostile or compromised server can whisper misleading instructions to the model. Security reviews through 2026 flag command injection and privilege escalation risks. For sensitive steps like payments and mail, which server connects with which permissions demands independent auditing.
My practical read: where tools are many, requests vary, and no flow can be scripted upfront, MCP buys real convenience. Where the flow stays fixed and endpoints are few, plain interface calls remain simpler and faster. So the question is not whether the protocol kills the interface, but which workload earns which layer.
Sources
6 links; no other published story cites them. Stories sharing a link do not confirm each other; a source's origin is not inferred from how often it is cited.
- @youtube Cloud X Berry — episode video
- @modelcontextprotocol https://modelcontextprotocol.io/specification/2026-07-28
- @descope https://www.descope.com/learn/post/mcp
- @designrevision https://designrevision.com/blog/mcp-vs-api
- @amber https://amber.de/en/limitations-model-context-protocol/
- @microsoft https://techcommunity.microsoft.com/blog/microsoft-security-blog/the-state-of-mcp-security-in-2026/4531327
mcp · api · ai tools · protocol