What is an MCP server? A plain-English guide

If you’ve spent any time around AI tools lately, you’ve seen the phrase MCP server turn up everywhere, usually with no explanation. This is the explanation. No jargon you don’t need, and a straight answer to the question people actually ask next: do I have to build one?

MCP, in one sentence

MCP, the Model Context Protocol, is a shared language that lets an AI talk to your software. It’s an open standard (introduced by Anthropic in late 2024) that a lot of the industry has now adopted. Before MCP, every AI-to-app integration was a bespoke, one-off wiring job. MCP replaced that with a single, consistent way for an AI to discover what a tool can do and then do it.

Think of it like USB. Before USB, every device had its own connector. After it, one shape fit everything. MCP is that standard shape, but for connecting AI to the tools your business runs on.

So what is an MCP server?

An MCP server is a program that exposes one system’s capabilities (its data and its actions) in the MCP language, so an AI can use them.

That’s the whole idea. On one side sits the MCP client: the AI app you’re actually talking to, like Claude. On the other side sits the MCP server: the thing that knows how to talk to a specific system: your Xero account, your Notion workspace, your Slack. The server presents a menu of tools (list_invoices, send_message, create_contact) and, when the AI asks, it carries out the request against the real system and hands back the result.

So the server isn’t “a server” in the big-datacenter sense. It’s a translator and a gatekeeper. It turns “email that customer their overdue invoice” into the exact API calls Xero and Gmail expect. And, done properly, it decides what the AI is and isn’t allowed to touch.

How an MCP server actually works

Walk through a single request end to end:

1. You ask. In plain English: “What did we invoice Acme last month?”
2. The client picks a tool. Claude sees the tools the MCP server advertises, and chooses list_invoices with a filter for the customer and date range.
3. The server does the work. It authenticates to the underlying system, makes the real API calls, handles pagination and rate limits, and assembles the answer.
4. The result comes back. The server returns structured data; the AI turns it into a sentence you can read.

The AI never touches the underlying API directly, and it never needs to know how Xero’s or Slack’s API is shaped. It only speaks MCP. The server absorbs all the messy, vendor-specific detail behind that clean interface.

Local vs remote (hosted) MCP servers

There are two places an MCP server can run, and the difference matters.

Local MCP servers run on your own machine, usually launched by a desktop app. They’re great for developers wiring up files, a local database, or a dev tool. But they only exist while your machine is on, they’re yours alone to maintain, and connecting them to real business systems means storing API keys and OAuth tokens on your laptop.

Remote (hosted) MCP servers run on the internet at a URL. The AI connects to them over HTTP. This is what you want for real business software: it’s always available, it’s shared across your team, it handles authentication centrally, and nobody has to run anything locally. When Claude talks about adding a custom connector, this is exactly what it means: a remote MCP server it reaches by URL.

Custom connectors: how you add one to Claude

Claude calls this feature Connectors. Some connectors are built in; others you add yourself. To add your own, you go to Settings → Connectors → Add custom connector and paste a remote MCP server’s URL. From that point on, that server’s tools are available to Claude, and it appears in your Connectors list alongside everything else.

So “custom connector” and “remote MCP server” are two names for the same thing seen from two sides: connector is what Claude calls it, MCP server is what it technically is.

Do you have to build one? No.

Here’s the part the tutorials skip. Building a production MCP server for a real business system is not a weekend project. To connect one tool properly you have to handle its OAuth flow, refresh tokens safely, respect rate limits, page through large result sets, map plain-English requests to the right API calls, and, the part that really matters, make sure the AI can only do what you’ve allowed. Then you do all of that again for the next tool. And the next.

That’s the reason hosted platforms exist. FloConnector is a hosted MCP server that already speaks to 50+ business platforms (Xero, HubSpot, Notion, Slack, Shopify and more) behind a single endpoint. You add one custom connector to Claude, switch on the tools you want, and decide exactly what each one is allowed to touch. Your credentials stay encrypted on our side of a wall the AI can’t reach across; the model gets the capability, never the keys.

If you want to see what’s on the menu, the connector directory lists every platform and every tool. If you’d rather understand the safety model first, we wrote about why the AI never sees your passwords.

The short version

• MCP is the standard language between an AI and your software.
• An MCP server exposes one system’s data and actions in that language.
• A remote (hosted) server is one you reach by URL: what Claude calls a custom connector.
• You can build your own. For real business tools, connecting to a hosted one is faster, safer, and something you don’t have to maintain.

That’s an MCP server. The rest is just deciding which tools you want your AI to reach, and how much you want it to be able to do.

Written by

David List

Founder, FloConnector

Building the hosted MCP layer that lets a business's AI actually run its software. Previously deep in field-service and accounting integrations.

floconnector.com