Your platform serves 40 internal teams shipping LLM features against OpenAI, Anthropic, and Gemini. You already have OpenAPI specs for every internal service. A staff engineer proposes adding MCP as a third integration layer on top of function calling and OpenAPI. Defend the three layer architecture against the counter argument that one standard should suffice.
OpenAPI, function calling, and MCP sit at three different boundaries (service contract, LLM wire format, host to tool execution) and removing any one breaks a different axis of the platform.
Picture a large company with restaurants, translators, and delivery drivers. Restaurants have menus that list everything they cook (that is OpenAPI describing what each service does). Customers speak different languages (those are the LLM providers, each with its own way of placing an order). Delivery drivers carry the food from the kitchen to the table (those are MCP servers connecting hosts to tools). If you remove the menus, nobody knows what the restaurant offers. If you remove the translators, customers cannot order in their language. If you remove the delivery drivers, every customer has to walk into every kitchen themselves, which gets chaotic at 40 restaurants and three languages. Each role handles a different problem, and saying 'just pick one' is like insisting restaurants only need menus but not drivers.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
At a 40-team organization with 120 OpenAPI services and three LLM providers, the question of where MCP fits is the highest-leverage platform decision of 2026. Getting it wrong in either direction costs the platform team and every consumer team months of rework.
The correct framing is that MCP, vendor function calling, and OpenAPI sit at three different system boundaries. The platform decision is which one belongs at each boundary, not which to pick. This explanation walks each layer, surfaces concrete tradeoff axes, quantifies the integration math, and names the specific situations where MCP wins and where direct function calling wins.
Layer 1: OpenAPI as the service contract boundary
OpenAPI predates LLMs by years. At a 40-team organization with 120 services, the specs are the source of truth for service capability and the input to client SDK generation, request validation, rate-limit configuration, audit logging, and partner documentation.
Non-LLM consumers depend on these specs everywhere. Frontends generate typed clients from the spec. Partner integrations build their own clients from the spec. Cron jobs and internal services call each other through the documented endpoints. None of these consumers speak MCP. Replacing OpenAPI with MCP at the service contract boundary would break all of them.
OpenAPI also provides a mature operational stack. Auth schemes (Bearer, OAuth flows, mTLS, API keys) are documented in the spec and enforced at the gateway. RBAC attaches to operations. Versioning is well-understood: info.version, URL path versioning, header-based versioning. Audit logging hooks into operation spans by operationId. Rebuilding any of this at the MCP layer is duplicative work.
The right move is to keep OpenAPI as the canonical service contract and treat MCP as a derived view layered on top. Each service maintains its spec as before. An MCP wrapper is added (auto-generated, ideally) that exposes the same operations as MCP tools with LLM-optimized descriptions. The investment in OpenAPI is preserved and MCP capability is additive.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- openapi-mcp and FastAPI-MCP are auto-generators that produce an MCP server from an OpenAPI spec, letting platform teams wrap services at scale without hand-writing each server.
- Claude Desktop, Cursor, Zed, and Claude Code all consume MCP servers through the same protocol while translating to Anthropic's or OpenAI's function-calling format internally, validating the three-layer separation in production.
What an interviewer would ask next. Try answering before peeking at the approach.
QTrace a single request end to end through the three-layer model, from user query to backend response. Which component does what at each boundary?
User sends a question to the host. Host calls the LLM API with the message plus tools in the provider's function-calling format. LLM returns a tool_use response. Host identifies which MCP server owns the tool and sends a JSON-RPC tools/call over stdio or streamable HTTP. MCP server translates the call into an HTTP request against the underlying OpenAPI service. The service responds, the MCP server returns the result, the host passes it to the LLM as a tool_result, and the LLM continues. Each boundary is crossed exactly once.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating MCP, function calling, and OpenAPI as interchangeable standards where choosing one eliminates the need for the other two. Each layer answers a distinct question no other layer can.
60 second bullets to scan on the way to the call.
Name the three layers: OpenAPI as service contract, function calling as LLM to host wire format, MCP as host to tool boundary.
Explain why OpenAPI cannot be replaced by MCP (non-LLM consumers depend on it).
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.