Guides

What is an MCP server? A plain-English guide for business owners

An MCP server is how you give AI assistants buttons to press instead of pages to read: check availability, quote a price, book the slot. Here is what the Model Context Protocol actually is, who supports it, what a merchant server exposes, and how to get one without an engineering team.

Updated August 10, 2026 · 9 min read

An MCP server is a small service that exposes your business’s capabilities as tools an AI assistant can call. Instead of an agent reading your website and telling its user "this clinic offers physio, call to confirm availability," an agent connected to your MCP server can check Tuesday’s open slots, quote the current price, and complete the booking. MCP stands for Model Context Protocol, the open standard that defines how that connection works, and the server is your side of it.

Business owners keep running into the term because MCP quietly became the default way AI products talk to the outside world. If you have wondered whether it is another passing acronym or something worth an afternoon of attention, the short answer: it is infrastructure, it is already broadly adopted, and for a business that takes bookings or sells anything, it is the difference between being readable by agents and being usable by them.

This guide explains the protocol in plain English, who actually supports it, what a merchant MCP server exposes, the security guardrails that matter, and the realistic paths to having one. For where MCP sits next to the commerce-specific protocols, the UCP vs ACP vs MCP comparison maps the whole landscape.

MCP in plain English

The Model Context Protocol was open-sourced by Anthropic in November 2024 to solve an integration mess. Before it, every AI product needed a custom connector for every service it wanted to use: one for the calendar, one for the database, one for the payment system, multiplied across every vendor. MCP standardizes that plug. The common analogy is USB-C for AI: one connector shape, so any compliant assistant can use any compliant service without bespoke wiring.

The moving parts are simple. A client is the AI application (Claude, ChatGPT, a custom agent). A server is the thing offering capabilities. Servers offer tools, which are actions the AI can invoke, and resources, which are data it can read. When an assistant connects to a server, the first thing it does is ask what tools exist, and the server answers with a machine-readable list: each tool’s name, what it does, and what inputs it takes. From then on, the assistant can call those tools mid-conversation the way a person would tap buttons in an app.

For a service business, that tool list might look like this:

{
  "tools": [
    {
      "name": "list_services",
      "description": "Current services with prices and durations"
    },
    {
      "name": "check_availability",
      "description": "Live open slots for a service on a given date"
    },
    {
      "name": "create_booking",
      "description": "Book a slot; returns confirmation and a payment link"
    }
  ]
}

That is the whole trick. Nothing about MCP is conceptually exotic; it is a standard way to publish "here is what you can do with my business" so that software, not just people, can act on it.

Who actually supports it

Adoption is the reason MCP matters and the thing that separates it from most AI-era acronyms. Anthropic built it natively into Claude across desktop, web, and its developer products. OpenAI adopted the standard in March 2025 across its Agents SDK and products, an unusual case of the two biggest labs converging on one spec. Google committed Gemini support the same spring, and the ecosystem around them (developer tools, agent frameworks, and thousands of published servers for everything from GitHub to Stripe) treats MCP as the default integration layer. When one standard is spoken by the major assistants, a single server on your side reaches all of them.

Why a business would want its own server

Everything else in the agent-readiness stack makes your business easier to read: structured data, feeds, clean HTML. An MCP server is the layer that makes it possible to act. The distinction shows up at every step of a delegated purchase:

The economics follow from the last row. In agentic commerce, assistants preferentially route to merchants where the journey completes without friction, because a failed handoff reflects badly on the assistant. Callable beats readable, and the gap widens as more purchasing gets delegated. For appointment-driven businesses in particular, this is the mechanism behind AI agents booking service businesses: the booking happens because there was a tool to call.

What a good merchant server exposes

Resist the urge to expose everything. A tight, reliable tool set beats a sprawling one, because agents choose tools by their descriptions and trust servers that behave predictably. The core set for most businesses:

• Catalog tools: list services or products with live prices, durations, and options, so the agent never quotes from stale copy.
• Availability tools: real-time open slots or stock levels, scoped to what is actually bookable or buyable.
• Transaction tools: create a booking or order, returning an explicit confirmation and, where payment is due, a secure payment step rather than raw card handling.
• Policy resources: cancellation terms, service area, and FAQs as readable resources, so the agent answers policy questions from your canonical text instead of guessing.

Security and guardrails

Giving software the ability to act on your business deserves the same care as hiring a new front-desk employee. The guardrails are well understood: authenticate callers rather than running an open server, scope tools to the minimum needed (an agent that books appointments needs no refund tool), require explicit confirmation semantics for anything that moves money, log every call so you can audit what agents did, and rate-limit so a misbehaving client cannot flood your calendar. Treat any text an agent passes in as untrusted input, exactly as you would a web form.

Build one or get one

Building is genuinely accessible for a developer: official SDKs exist in the major languages, and a minimal read-only server (catalog plus availability) is a small project. The real cost is what comes after: hosting, authentication, keeping tools synced with your actual prices and calendar, and maintaining it as the spec and clients evolve. That maintenance tail is why most small businesses should not hand-roll one, the same way most do not hand-roll their payment stack.

The alternative is a platform that runs the server for you. Nexez publishes a per-merchant MCP server as part of its standard stack: your services, live pricing, and availability exposed as tools, with real Stripe checkout and Calendly-backed scheduling behind the transaction tools, alongside the readable layer (JSON-LD, agent.json, llms.txt, OpenAPI) and the shopping-surface feeds. One setup, and the same source of truth feeds everything, so the price an agent is quoted is the price on your page.

The pattern to remember: MCP is not a marketing channel, it is a socket. The businesses wiring into it now are not betting on an acronym; they are making sure that when an assistant is asked "book me the appointment," their calendar is one it can reach.