What MCP Is - and When a Small Business Actually Needs One

People now say “we need MCP” the way they said “we need a chatbot” two years ago. The letters stand for Model Context Protocol. The useful sentence is shorter: it is how an agent is allowed to touch your tools without inventing the API from a blog post from 2024.

A chatbot produces text. An agent picks a tool and runs it. MCP is the plug between them - names, argument schemas, results. I already wrote why you should not give the model the till. This piece is the missing plug: when that list of tools should speak MCP, and when a typed function on your own server is enough.

1. USB, not a personality

You do not “install MCP” the way you install ChatGPT. You expose tools through a standard socket. Any compatible agent - Cursor, Claude, a bot inside your Next.js app - can list those tools and call them.

That is the whole trick. Before this, every vendor had a different way to hand a model a function. Now the socket is shared. Shared sockets grow ecosystems: registries, install commands, and a wave of products that sell you a “gateway” before you have a single tool worth plugging in.

2. What actually happens in one call

Three steps. Then you can stop reading vendor diagrams.

• The agent asks the server which tools exist. It gets names and JSON schemas. Example: create_invoice, with amount, currency, customer id.
• It calls one tool with arguments that match the schema. Not a paragraph. Not SQL it invented.
• The server runs your code. The model never sees the Stripe key. The result comes back as data the interface can show.

If that sounds like an API

It is an API, written for a model you cannot trust with a shell. The protocol is plumbing. Safety still lives in which tools you expose and which ones wait for a human. Shipping MCP on a server does not make the product safe. I wrote that line about agents this month. It applies here without a new religion.

3. Why it is loud this August

Next.js 16.3 went stable on 3 August 2026 with an MCP endpoint on the dev server. A coding agent can read live errors, routes, and logs instead of guessing your App Router from last year’s docs. Figma exposes files, components, and variables as tools - that is the “Figma-to-code via MCP” line on my site, not a screenshot and a prayer. Registries now treat MCP servers like packages. Vendors sell gateways: one place to authenticate, audit, and police a whole “fleet” of agents.

For a ten-person company most of that fleet does not exist. The useful part of the noise is the socket. The expensive part is buying governance for employees you have not hired.

4. When you actually need it this month

Wire MCP when the agent must see a live system you already have, and a prompt is not a substitute.

• A coding agent on a Next.js site: it should read this version’s docs and this process’s errors, not invent cache APIs from 2024. I wrote what I would do on an existing site after 16.3.
• Figma to production UI: the file is the source. The agent should query the file, not a PNG of the file.
• Several tools, one product agent: booking, CRM, FAQ retrieval. One schema per tool beats a new adapter per chat vendor.
• You already have an allowlist and a confirm button. MCP does not replace those. It stops the model inventing the function names.

5. When you should not

A FAQ bot with retrieval does not need MCP. A server action that creates a booking from a form does not need MCP. “The keynote said every product will be agent-native” is not a spec.

Do not buy a gateway, a registry, and a browser built for agents because a roundup called this the npm moment. You need a gateway when you have many agents, many people, and an auditor who will ask who called refund at 02:14. Until then the server that holds the keys is the gateway.

Do not replace a working form with an agent that speaks MCP. Forms are still how money should move. I keep the agent on draft and extract. A person presses send.

6. How I would wire it

Three sockets, not a platform.

• Figma MCP into the repo I am hired to build. I still read the diff. Pixel-perfect is a human standard. The protocol only stops the model inventing spacing from a screenshot.
• next-devtools-mcp against the running Next.js app so the agent sees real routes and real errors. AGENTS.md points at the docs in node_modules. I already covered that release.
• In the product: a short tool list as typed server functions. MCP in front if the caller is an external agent - Cursor, a desktop app, a second model. A plain function if the caller is your own Next.js route. Same allowlist, same confirm, same audit log either way.

Keys stay on the server

The model never holds Stripe. Idempotency keys on charge and book. A log a non-engineer can read: who asked, which tool, which id, who confirmed. MCP does not write that log for you. You still do.

Conclusion: buy the socket, skip the fleet

MCP is a socket. It got loud because sockets get ecosystems, and ecosystems get invoices. A small business needs it when an agent must talk to Figma, to a live Next.js app, or to a short list of your tools without inventing the API. It does not need it as a personality, a chatbot upgrade, or a gateway for a fleet of one.

I wire the socket where it saves a week and skip it where a form already works. Write via the form which system the agent must see - Figma, the running site, the booking calendar - and which action must never run without a person. We will not start by buying you a gateway. :)