MCP, function calling and ChatGPT plugins explained as layers of the agent stack

Three layers, not three competing options

When API teams wire their services into AI agents, three concepts tend to get used interchangeably: function calling, ChatGPT plugins and the Model Context Protocol (MCP). A dev.to article argues this is a category error — the three sit at different layers of the stack, and treating them as alternatives produces integrations that fall apart as soon as a second agent client shows up.

Function calling is a model capability

Function calling is a feature of the chat-completion API itself: a developer sends the model a list of functions described with JSON Schema, the model emits a structured call, and the application executes it and feeds the result back. According to the article, everything around that loop — assembling the tool catalog, authenticating to underlying APIs, handling retries, timeouts and confirmation for risky actions, and mapping results into the conversation — stays with the application developer. There is no discovery protocol and no standard transport. Two applications using the same model against the same API still end up writing two separate tool integrations, which is the duplication the other layers attempt to remove.

ChatGPT plugins were a distribution experiment

OpenAI's plugin system, announced in 2023 and later retired in favour of GPTs, let ChatGPT discover an API through an ai-plugin. manifest pointing at an OpenAPI document. The dev.to piece credits it with proving that models can find HTTP operations from a machine-readable contract rather than pasted documentation. But it was tied to one host, one vendor's review and distribution model, and one conversation surface, so it never became a cross-vendor standard. The author's verdict: any 2026 guide still describing plugins is documenting a legacy path.

MCP standardizes the glue

MCP is a client-to-server protocol that formalizes what function-calling implementations previously hand-rolled. An MCP server exposes tools (callable functions with JSON Schema inputs), resources (readable context) and prompts over a defined transport — stdio for local processes, streamable HTTP for remote services. A client such as an IDE agent, chat app or CLI connects, lists the available tools and invokes them, while the server validates input, calls the API, scopes credentials and shapes results.

The important distinction, per the article, is that MCP does not replace function calling. The model still emits function calls; MCP replaces the bespoke, per-application plumbing that exposed those tools to the model in the first place. Because discovery and transport are standardized, the same MCP server works with clients like Cursor, Claude Code and custom-built agents.

OpenAPI as the common source

The mapping from an OpenAPI document to MCP tools is described as mechanical: operations become tools, parameters and request bodies become input schemas, security schemes become runtime-injected credentials, and responses become tool results. Generating the MCP server from the spec means one document feeds documentation, mocks, SDKs and agent tools; schema violations get rejected before the HTTP call, turning a class of model mistakes into immediate, correctable tool errors; credentials live in server configuration and never reach the prompt; and SSE operations become tools that collect streamed events instead of hanging. Hand-writing tool wrappers that restate what the spec already says, the author warns, recreates the very duplication MCP was meant to remove and decays at the first schema change.

Custom tools still have a place

Not every agent capability is an API operation. The article recommends hand-built MCP tools for composite domain-level actions, local workspace capabilities, and destructive or costly operations requiring policy checks or human approval. The mature setup, it argues, is generated tools covering the API's operations plus a small set of gated workflow tools, all behind one MCP server.

Why it matters

For API teams planning agent support, the practical guidance from the piece is concrete: keep a tight, current OpenAPI document with real descriptions, enums and examples, because machines choosing actions now consume it, not just humans reading docs; serve it as an MCP endpoint, locally over stdio for developers and hosted with scoped tokens for partners and internal agents; write tool descriptions with the same care as API design, favouring verb-first names and machine-readable errors such as problem+ types that let agents self-correct; and keep credentials and destructive-action policy in the server, never in prompts. Most pointedly, it advises ignoring new plugin-shaped vendor lock-ins — the ability to serve many clients from one server is the entire point of MCP.