What is the Model Context Protocol?
The younifyd team
July 5, 2026 · younifyd.com
In November 2024, Anthropic published the Model Context Protocol (MCP) — an open standard for connecting AI agents to external tools and data sources. It's compact enough to read in an afternoon, which makes it easy to mistake for a minor feature. It isn't. MCP is a communication standard, and it's already reshaping how software gets built and exposed to AI agents, including the AI shopping agents that browse, compare, and buy on behalf of customers. This post explains what MCP is at a technical level, why it was created, how it differs from function calling, and what it means for commerce teams whose APIs increasingly need to be callable by an agent, not just a person or a script.
The problem MCP solves
AI language models are powerful text processors, but they're stateless — they have no access to your database, your internal APIs, current inventory, or anything beyond their training data. Making a model useful for real tasks means giving it access to external systems, and the question has always been how. Before MCP, the dominant pattern was model-specific function calling: you define a set of functions in a schema format specific to the model you're using — one format for one model, another for the next — and pass them with every request. The model "calls" a function by returning a structured JSON object matching the schema, and your application code executes it. This works, but every model has its own schema format, every integration has to be rebuilt per model, and nothing is reusable across agent frameworks. MCP solves this with a standard protocol layer. Instead of defining tools inline in a model API request, you run an MCP server — a process that exposes tools, data, and prompt templates over a standard wire protocol. Any MCP-compatible client, whether that's a chat assistant, a custom shopping agent, or an automated pipeline, can connect to any MCP server and discover and invoke its capabilities without either side knowing the other's implementation details.
Hosts, clients, and servers
MCP defines three roles. A host is the application that contains the AI agent — a chat assistant, an AI shopping agent, an automated pipeline — and it manages the connection to the model and orchestrates tool use. A client runs inside the host and speaks the MCP protocol to a server; each client maintains one connection to one server. A server is the process that exposes capabilities — tools, resources, prompts — over the protocol, and it can run as a local subprocess or as a remote service. The wire protocol itself is JSON-RPC 2.0 over one of two transports: a local transport for servers the host spawns directly, and an HTTP-based transport for remote servers, where the client sends requests and receives responses and server-initiated notifications over a persistent connection. When a client connects, it performs a capability negotiation — the server declares which protocol version and which capabilities (tools, resources, prompts) it supports, and the client uses that to decide what's possible for the rest of the session.
Tools, resources, and prompts
MCP defines three primitives a server can expose. Tools are functions the agent can call to perform actions or retrieve information — each has a name, a description, and an input schema, and when the agent calls a tool it passes a JSON object matching that schema and gets a result back. Tools map directly to API endpoints, database queries, or any programmatic action, and they're the primitive most teams encounter first — an "add to cart" or "check order status" tool, for instance. Resources are data the agent can read lazily rather than fetch eagerly — files, records, API responses — identified by URIs and, in some implementations, able to push update notifications so the agent stays current without polling. Prompts are reusable prompt templates a server can expose directly to the user, packaging a multi-step task into a single named operation invoked with a few parameters. Most production MCP servers today focus on tools; resources and prompts are well specified in the protocol but less commonly implemented.
How MCP differs from function calling
Function calling and MCP solve related but distinct problems. Function calling is a feature of a specific model API — it lets you pass tool definitions into an inference request and have the model output structured calls to those tools. MCP is a protocol for discovering and invoking tools from a remote server, independent of which model is doing the calling. The practical difference is where the tool definitions live and how portable they are. With function calling, tool definitions live in the application code that calls the model — hardcoded, and rebuilt for every model you support. With MCP, tool definitions live on the server and are discovered dynamically when a client connects, so the same server works with any MCP-compatible client without modification, and the set of available tools can change without shipping a new version of the host application. Function calling and MCP aren't mutually exclusive, either — under the hood, a host still translates an MCP tool call into the model's own function-calling format before sending it to the model. MCP is the external, portable interface; the model's function-calling mechanism is an internal implementation detail.
Authentication in MCP
Remote MCP servers can require authentication before a client is allowed to discover or call tools, and the specification points to OAuth 2.0 with dynamic client registration as the recommended mechanism for user-facing authorization flows. In practice, a lot of commerce and internal-API MCP servers don't need the full OAuth handshake — a scoped API key or JWT bearer token, checked on every call, is enough to keep tools locked down without adding an interactive login step to a machine-to-machine request. That's the model younifyd's MCP tools use: API-key and JWT authentication with rate limiting enforced per tool, rather than a full OAuth implementation, which keeps the agent-facing surface simple for automated, non-interactive calls while still gating access properly.
The MCP ecosystem today
In the roughly eighteen months since the specification was published, the MCP ecosystem has grown substantially. Several major model providers and chat clients support MCP natively, open-source bridges let MCP clients connect to remote HTTP servers, and there are now hundreds of published MCP servers covering file systems, databases, version control, communication tools, and commerce platforms. The adoption pattern resembles the early years of REST: a period where the standard is defined and tooling gets built, a period where early adopters implement it and share what they learn, and then the point where it becomes an expected capability — something customers ask for, something that separates products that support it from those that don't. We're solidly in the second phase now. AI agent use is accelerating, MCP is the de facto interoperability standard for it, and teams that have exposed their APIs via MCP are already seeing agents use them in ways nobody explicitly designed for — composing several tool calls to answer a multi-part question, or working through a checkout flow end to end. That's the value of a standard: you build the capability once, and the use cases emerge organically.
What this means for commerce teams
If you run commerce APIs, MCP is a new distribution channel for your storefront, catalogue, and order capabilities — not a separate integration to build from scratch. Your existing API documentation and OpenAPI spec already contain most of what's needed to describe an MCP tool; the question is whether you expose that information in a way an AI shopping agent can consume. Teams that do this well get two things. First, their APIs become usable by AI-powered shopping flows without integration work on the agent side — any MCP-compatible agent can discover and call the tools without a developer writing wrapper code. Second, they get visibility into how agents actually use their APIs: which tools get called most, which parameters show up, where calls fail. The implication for API design is real. APIs have historically been designed for a human reading documentation or a developer wiring up an SDK. MCP shifts the primary consumer to an agent that reads tool descriptions at connection time and decides, in real time, which tool answers the current step of a task. A tool with a precise, accurate description gets used correctly and often; one with a vague description gets called at the wrong moment, or not at all. Description quality is the new API documentation quality.
The right architecture for MCP exposure
Exposing internal microservices directly as MCP tools is possible but rarely the right call. Internal services are shaped by service-to-service constraints, not by what an agent needs — expose them directly and every service change risks breaking a tool definition, every internal field leaks into the tool schema whether it's relevant or not, and auth has to be handled per service. The better pattern puts an orchestration layer between internal services and the MCP server: it composes several service calls into one coherent tool operation, handles auth with internal services so the agent never needs service-specific credentials, trims responses down to the fields an agent actually needs, and gives the agent the right level of abstraction — "get product with live inventory and current promotions" as a single tool, instead of three tools the agent has to call and stitch together itself. This is the same argument for using an orchestration layer for any other consumer — a BFF, a gateway — applied to the agent use case. In younifyd, that orchestration layer is the workflow builder itself: a workflow you've already built and tested — say, an add-to-cart flow that checks inventory and applies promotions — can be turned directly into an MCP tool with that same logic intact, so the agent gets the composed operation, not raw access to the underlying services. The same workflow can also run as a regular API route or fire from a webhook trigger, so you build the logic once and reuse it across all three surfaces. younifyd also supports connecting to major commerce MCP servers out of the box, and you can bring your own external MCP server where you need something it doesn't ship.
Turn your workflows into MCP tools
Build a workflow once in younifyd and expose it as an API route, an MCP tool for AI shopping agents, or a webhook trigger — the same logic, reused across all three. Start free, no credit card required.
Try for Free