field note
first published 2026-10-09
What is an MCP server? A plain explanation from someone who runs one on this site
An MCP server is a small program that gives an AI model a set of named tools it can call. What the Model Context Protocol is, what a server actually does, how to build one, what it means for a business website, and the one running behind this page.
1,014 words · 5 min read · ai systems
If you have searched for this phrase you have probably read three explanations already and still cannot picture what the thing is. So, concretely: an MCP server is a small program that tells an AI model "here are some tools you may use, here is what each one does, here is the shape of the input", and then does the work when the model calls one.
This website runs one. When a model connects to jamiemckaye.com/api/mcp/ it is offered five tools: grade a website's AI readiness, fetch the site map, ask the concierge a question, file an engagement brief, and get a contact channel. The model does not scrape pages to find those capabilities. It is handed a menu.
The protocol, in two paragraphs
The Model Context Protocol is an open standard that Anthropic published in November 2024. It defines how an AI client (a chat app, an IDE, an agent) discovers and calls capabilities exposed by a server. The server declares tools, each with a name, a description written for the model, and a JSON schema describing the arguments. It can also expose resources (things to read) and prompts (templates). The client lists what is available, the model decides when to call something, the client sends the call, the server returns the result.
Transports are deliberately boring. A server can speak over standard input and output, which is how local tools attach to a desktop client, or over HTTP, which is how a website offers tools to the world. The one on this site uses the streamable HTTP transport, which is the standard for remote servers.
That is the whole idea. What made it matter is adoption: once the major AI clients and coding tools spoke the same protocol, anyone could publish a server and have it usable everywhere, the way publishing a website once meant every browser could read it.
What a server actually does, step by step
- Starts and announces itself. The client connects; the server replies with its name, version and the capabilities it supports.
- Lists its tools. For each tool: a name like
grade_site, a description the model will read to decide whether the tool fits the task, and a schema for the inputs, such as{ "url": string }. - Waits. Nothing happens until a model, in the middle of a conversation, decides a tool is the right move.
- Executes a call. The client sends
grade_sitewith a URL; the server runs the real code, in this case a crawler and a scoring model, and returns the result as text or structured content. - Enforces its own limits. A well-built server rate-limits callers, validates every input, refuses anything out of scope, and logs what it did. Mine caps grader runs per caller, throttles engagement briefs site-wide, and never executes anything a visitor couldn't do by hand on the site.
Notice what is missing: no integration code on the model's side, no bespoke prompt teaching the model your API, no screen-scraping. The description does the teaching.
How to build one
The official SDKs exist for TypeScript, Python and several other languages, and a minimal server is a few dozen lines. The sequence that produces a server worth shipping is longer than the code:
- Decide the jobs. Write down the two or three things a model should be able to do with your system. Not everything it could do. Every tool is a permission.
- Name and describe them for a reader who is not you. The description is the interface. "Grade a public website's readiness for AI search and agents; returns a score, a letter grade and findings" tells a model exactly when to reach for the tool.
- Type the inputs tightly. A URL is a URL, with a length cap and a scheme check. A free-text field is an invitation.
- Implement, then wrap in limits. Rate limits per caller, timeouts, output size caps, and a refusal path that returns a clear error instead of a stack trace.
- Choose the transport. Stdio for local tools; streamable HTTP, behind your normal authentication and firewall rules, for anything public.
- Log and watch. Who called what, how often, with what result. On this site every call is counted, and the counts are published on the lab page.
If you are building in Next.js, the server on this site is one route handler plus the five tool functions, which are the same functions the human-facing pages use. That is the pattern I would recommend: the tools are not a second product, they are the existing product with a machine-shaped door.
What it means for a business website
Agents already read websites. The guestbook on this site's lab page counts ChatGPT, Claude, Perplexity and the rest by product, and they visit every day. Today they read. Increasingly they act: check whether something is available, compare options, file an enquiry on a person's behalf. A site with an MCP server can meet that behaviour with a defined, limited, logged set of actions instead of hoping the agent fills in a contact form correctly.
Two cautions. First, make the site legible before adding tools: if a crawler cannot extract what you do from the HTML, no agent will get far enough to find the server. Second, treat every tool as a liability decision. The web is about to find out what happens when a tool description can be read by a model and written by an attacker; keep the surface small and the inputs typed.
What this site's server is for
Five tools, public, counted. grade_site runs the Agent-Ready Grader, which is also the instrument I run for clients. site_map returns the same map a human gets from llms.txt. ask_concierge answers from the site's facts and nothing else. request_engagement files a brief that lands with me directly, throttled so a runaway agent cannot flood it. contact_channel says how to reach a human.
It is there because the readers multiplied, and because the best way to explain what an MCP server is turned out to be running one where anyone, or anything, can call it.
asked straight — answered straight
01What does MCP stand for?
Model Context Protocol, an open standard Anthropic published in late 2024 for connecting AI models to external tools and data. It is now supported by the major AI clients and development tools, which is why 'MCP server' turned into a job description so quickly.
02What is the difference between an MCP server and an API?
An API is for programmers; an MCP server is for models. The server wraps whatever it does, often an API, in named tools with typed inputs and plain descriptions, so an AI client can discover them and call them without anyone writing integration code. Underneath, it is still just software answering requests.
03How do I build an MCP server?
Pick the official SDK for your language, define each tool with a name, a description and an input schema, implement the function behind it, and expose the server over stdio for local use or streamable HTTP for the web. Keep the tools few, scoped and rate-limited. The hard part is deciding what a model should be allowed to do, not the code.
04Does my business website need an MCP server?
Most don't yet. If agents are already reading your site, which the logs will tell you, a server that exposes the two or three things an agent should be able to do, such as check availability or file an enquiry, turns passive reading into a channel. Start by making the site readable; add tools when there is a job for them.
next step — ai search optimisation
AI search optimisation as engineering.
Make your site legible to ChatGPT, Perplexity and AI Overviews — then measure it. Send a brief — a few lines about the site, the problem and the evidence you have — and the reply is a straight read on fit and shape, from the person who does the work.
no forms · no funnels · jamie@jamiemckaye.com
written by
Technical SEO consultant and full-stack developer in Hersham, Surrey, in practice since 2007. One person, no handoffs: the audits, the code and the writing come from the same pair of hands. This site is the working proof — it grades itself on the same instrument it runs for clients.