What is an MCP server — and does your business need one?

I run a small MCP server against this website. It lets an AI assistant check whether every page loads, list the page titles against my own SEO rules, read the price list and confirm that nothing private has become public. It cannot change a single file. Building it taught me more about what MCP is for than any spec, so this guide uses it as the example throughout.

The short answer

An MCP server is a small program that sits between an AI assistant and one of your systems, and gives the assistant a fixed menu of things it is allowed to do there.

MCP stands for Model Context Protocol. It is an open standard, first published by Anthropic in late 2024 and now supported by many AI clients: Claude Desktop, Claude Code, Cursor, VS Code and others. The point of a standard is that you build the server once, and any assistant that speaks MCP can use it.

Without it, every connection between an AI and a business system is a one-off: custom code for this chatbot, a different plugin for that tool, copy and paste for everything else. With it, the system gets one well-described front door, and you decide exactly what is behind it.

The three things a server can offer

An MCP server can expose three kinds of thing. Most business servers only need the first.

• Tools are actions: “check the site’s health”, “find a customer by email”, “create a draft invoice”. Each tool has a name, a plain-language description the AI reads to decide when to use it, and a typed list of inputs.
• Resources are things the assistant can read, like a document, a record or a file, addressed by a URI.
• Prompts are ready-made instructions a person can pick from a menu in their AI client, such as “summarise this week’s support tickets”.

The assistant (the client) asks the server what it offers, reads the descriptions, and calls a tool when the conversation needs it. The server does the work with its own code and credentials and sends back a result. The model never touches your database directly. It only ever sees what the tool returns.

What I built for my own website

My server is written in TypeScript with the official MCP SDK and runs on the same machine as the site. It talks to the assistant over stdio, which means it is started on demand by the AI client and is not reachable from the internet at all. It has ten tools:

Tool	What it answers
site_health	Does every page in the sitemap load, how fast, and which security headers are missing?
list_pages	Every page’s title, description and keyword, checked against my length rules.
get_services	The six services and their published USD prices, from the same file the website uses.
check_public_surface	A list of paths that must never be served (secrets, logs, internal tools). Are any of them answering?
list_submissions	Recent contact form entries, with email addresses masked.
agent_usage	How the chat agent on the site is being used: mode, tools called, timing. No chat text exists to return.
repo_status	How far the live site has drifted from its last commit, and whether anything that looks like a secret is tracked.
email_manager_status	Is the inbox triage worker alive, and when did it last run?
page_outline	One page’s structure: headings, sections and word counts.
site_structure	Which pages link to which, and what is in the menu, footer and sitemap.

Every one is read-only. Here is roughly what one tool looks like in code. The description is written for the AI, not for me, because it is what the model reads to decide whether this tool fits the question it was asked:

server.registerTool(
  "slicklab_get_services",
  {
    title: "Get services and prices",
    description: "Return the six services SlickLab sells, with USD price range "
      + "and one-sentence description. This is the single source the website "
      + "and the chat agent use, so it is always the published price list.",
    inputSchema: {
      slug: z.string().optional().describe('Service slug, e.g. "mcp". Omit to list all six.'),
    },
    annotations: { readOnlyHint: true, destructiveHint: false },
  },
  async ({ slug }) => { /* read the price list, filter, return it */ },
);

Now I can ask “is anything on the site that shouldn’t be?” in plain words, and the assistant picks check_public_surface, runs it and tells me what it found. That question used to mean a dozen manual curl commands I would forget to run.

What it taught me

The description is the interface

My first descriptions were one line each, and the assistant picked the wrong tool about as often as the right one. Writing each description as if for a new colleague (what it returns, what it does not, when to use it instead of the neighbouring tool) fixed most of that. If a tool gets misused, I rewrite its description before I touch its code.

“Read-only” has to be true in the code, not just in the label

MCP lets a server mark a tool as read-only or destructive. Those markers are hints for the client. They do not stop anything. What makes my server safe is that none of its code paths write to the site, and the account it runs under is the only thing it can use. Treat the annotations as documentation and enforce the limits yourself.

Tests from the server’s point of view can lie

My server checks the site from the same machine the site runs on, and that machine is on the site’s own allow list. Paths that were locked to outsiders looked wide open from where the server stood. The fix was to probe the locked paths from a second network address that is not on the list. If your server checks access, make sure it checks it as a stranger would.

Small is a feature

Ten narrow tools beat one tool called run_query that accepts anything. Narrow tools are easier for the model to choose between, easier to test, and when something goes wrong you know exactly which door it came through.

Does your business need one?

MCP is worth it when three things are true at once:

1. People already use an AI assistant at work, or want to. MCP is how that assistant reaches your systems. If nobody uses one, there is nobody to call the server.
2. The answers live inside a system the assistant can’t see. Order status in your shop database, case history in your helpdesk, stock levels, bookings. Things that are not on a public web page.
3. The question changes each time. If the same steps run on the same trigger every day, a fixed automation is cheaper and more predictable. MCP earns its keep when a person asks something new and the assistant has to choose what to look up.

Some good fits I see often:

• A support team that wants to ask “what did we promise this customer last time?” and get the answer from the helpdesk and the CRM together.
• An operations lead who wants an assistant to read ServiceNow incidents, group them and draft a summary, without giving it the ability to close anything. My ServiceNow AI integration guide covers where this fits next to Now Assist.
• An owner who wants to ask about sales, stock or bookings in plain language instead of building a dashboard for every question.

And some cases where you probably don’t need one:

• You want a chat widget on your website for customers. That is an agent with a few built-in tools, like the one in the corner of this page. MCP is mostly for your team’s assistant, not your visitors. The difference is covered in agentic AI vs chatbots.
• You want the same report every Monday. Schedule it with an automation tool; see n8n vs Make vs Zapier.
• The assistant only needs to answer from documents. That is retrieval, which I explain in RAG explained for business owners. It can sit behind an MCP server, but it doesn’t have to.

The security questions to ask first

An MCP server is a door into a business system, so it deserves the same thought as giving a new staff member a login. Before building one, I go through this list with the owner:

1. Whose credentials does it use? A server running with an admin account can do whatever an admin can, whatever the tool descriptions say. Give it its own account with the smallest role that works.
2. Read or write? Start read-only. Add writing one tool at a time, and make anything irreversible (sending, deleting, paying) need a person to confirm.
3. Where does it run? A local stdio server like mine never faces the internet. A remote server over HTTP needs proper sign-in, and the current MCP spec describes OAuth for that.
4. What can reach the model? Text a tool returns goes into the conversation. An email or ticket written by an outsider can contain instructions aimed at the AI. Return only the fields the question needs, and never let returned text alone trigger a write.
5. What gets logged? Log which tool ran, with which inputs, for whom. My agent logs keep mode, tools and timing, and no message text.
6. How is it tested? Call every tool in a script on each change. My server has a smoke test that calls all ten.

How to start without overbuilding

Pick the one question your team asks most that needs a look inside a system. Build a server with two or three read-only tools that answer it. Use it for two weeks. You will learn which descriptions confuse the model, which fields people actually want, and whether writing anything is worth the risk. Then decide on the next tool.

If you want help choosing that first question, my scoping method is the same one I use with clients, and the free 2-minute automation audit will tell you whether an MCP server, an agent or a plain automation fits your situation. When you are ready to build, this is what my MCP server development service is for. It sits inside the bigger picture in agentic AI for small business.

Questions people ask