What Is an MCP Server? Definition, Function and Practice

Update, September 8, 2026: Uptimeify's MCP server has since grown a small set of write tools, on top of everything below, pausing a monitor, acknowledging an incident and similar. Each sits behind its own consent scope you grant separately from read access, area by area, so it changes nothing about the section below on security: the 33 tools this post describes are still all that reads, and nothing writes without that separate grant. Current tool list and scopes are on the MCP server page.

An MCP server is a standardised interface an AI assistant can use to call real tools instead of guessing. The Model Context Protocol defines how those tools are described, invoked and answered. Rather than composing an answer from model memory, the assistant calls a tool, receives a real result and works from there. This article covers the definition, how a tool call actually runs, the difference from a REST API, and what all of that means in day-to-day agency work.

What is an MCP server?

An MCP server is a service that provides an AI assistant with a set of clearly described tools it can call on its own during a conversation. It is the bridge between a language model that produces text and systems that produce facts: databases, APIs, file systems, network probes.

The word "server" is meant literally, but it is lighter than it sounds. An MCP server can be a small local program on your machine or a public HTTP endpoint on the internet. What matters is not where it runs but that it follows the same protocol as everything else.

Three roles work together:

• The host is the application you talk to, so the chat assistant or the development environment.
• The client sits inside the host and holds one connection per server.
• The server provides the tools and executes them.

One host can connect several servers at once. Anyone who makes a calendar, a ticket system and network checks available in the same chat has connected three servers and still talks to one assistant. The short version also lives in the glossary under MCP server.

Besides tools, the protocol knows two more building blocks: resources, meaning data a server offers for reading, and prompts, meaning ready-made text blocks. In practice tools are the building block almost every conversation is about, and therefore the focus here.

What is the Model Context Protocol?

The Model Context Protocol is the open standard that defines how assistants and tools talk to each other. Anthropic published and open-sourced it in 2024, and other vendors have since adopted it in their clients. It describes three things: how a client learns which tools exist, how it calls one, and what form the answer comes back in.

The benefit lies exactly in that standardisation. Before MCP, every combination of assistant and tool had to be wired up individually: a separate integration per vendor, a separate description, separate error handling. With a shared protocol a tool provider builds once and works with every compatible client, and a client vendor supports one protocol instead of a hundred one-off integrations.

There are two common transports. Local servers usually speak stdio, meaning the process's standard input and output. Servers on the internet speak Streamable HTTP. The second is the more interesting one for providers, because it needs no installation on the user's side: a URL is enough.

How does a tool call actually work?

A tool call is the moment the assistant stops composing and starts checking. Using an SSL check as the example, the sequence looks like this:

1. Connection and inventory. The client connects to the server and requests the tool list. It gets back names, descriptions and input schemas, so for instance check_ssl with the required field host and the optional field port.
2. The question. You write "Is the certificate for deinkunde.com expiring soon?".
3. The selection. From the description, the model recognises that check_ssl fits the question and proposes the call with the argument host: deinkunde.com.
4. The approval. Depending on the client you confirm the call, or it runs automatically because you approved that tool.
5. The execution. The server connects to the domain, reads the certificate and answers with issuer, validity dates, expiry date and certificate chain.
6. The answer. The model turns that into an answer in your language, now based on a measured result.

The difference from an answer without a tool is not cosmetic. Without a tool call a model can only estimate an expiry date or dodge the question, because it does not hold that information. With a tool call there is a date on screen that someone can verify.

Well-built servers return the answer twice: once as readable text and once as structured data following a published schema. That lets an application process the result programmatically, while a simple client sees the same text it saw before.

What happens when a call fails?

That is part of the protocol too. A tool can fail because a domain does not resolve, a port is closed or a limit has been hit. The server then answers not with an empty result but with a response flagged as an error and a plain-text message.

For you in the chat, that is the difference between "the host is not answering on port 443" and an answer that sounds as though everything is fine. A model that receives an error as an error can name it or suggest the next sensible step. That is exactly why a clean error shape belongs to the standard rather than to each individual provider.

What do you need an MCP server for in practice?

The value shows up wherever context switching costs time today. An agency looking after 40 client sites checks small things daily that nobody wants to open a dashboard for. Those are precisely the checks you can pull into the chat where the work is happening anyway.

Four patterns come up most often:

• Post-launch verification. Follow redirects, look at the security headers of the destination, check DNS propagation. One sentence instead of four tabs.
• Diagnosing mail deliverability. Check SPF, DKIM and DMARC in one go when a client reports that mail is landing in spam.
• Preparing an onboarding. Query certificate validity, domain expiry and reachability for a new client domain before the monitor is even created.
• First triage during an outage. Is the domain reachable, does the port answer, does resolution look right? The finding is there before anyone writes the ticket.

The time saved does not come from one faster check but from the context switch that never happens. Checking a certificate in a browser might take 30 seconds. Getting there, finding the right tab again and picking up your original task costs several times that. Getting the same finding inside the running conversation means you never drop the thread.

On top of that sits a second layer: servers that read your own data with an API token. The assistant then answers not only questions about arbitrary domains but questions about your own portfolio, such as which monitors are down right now or what availability looked like for a client last month.

One thing to be clear about: an MCP server does not replace monitoring. It checks on request, not on an interval, and it wakes nobody at three in the morning. It is the tool for the question in between, not the watch running in the background.

What separates an MCP server from a REST API?

Technically the same logic often sits underneath. Many MCP servers are a thin layer over an existing REST API. The difference is who the interface is written for.

A REST API is written for developers. Someone reads the documentation, understands it, and writes code that calls a specific endpoint at a specific time. An MCP server is written for a model. The tool therefore has to describe itself, and describe itself well enough that a model can infer from the description when calling it makes sense and which arguments belong in it.

A second difference concerns state. Over Streamable HTTP a server usually runs stateless: there is no session state between two calls, and every request stands on its own. That keeps operations simple and the server easy to scale, but it moves responsibility for conversational context where it belongs, into the client.

The practical consequence for providers: a good tool description is not decoration, it is the actual interface. A precisely named tool with a clear schema gets called at the right moment. A vaguely described one gets ignored or misused.

How secure is this?

The honest answer: it depends on three questions you should answer per server before connecting it.

What is the server allowed to do? A tool that only reads can at worst show you something wrong. A tool that writes or deletes can do damage. Read-only is therefore the safe starting point, and a provider should say clearly which of its tools can write. The Uptimeify MCP server does exactly that: 33 tools only read, and a further 43 write tools exist behind their own consent scope, granted separately from read access and unchecked by default, so nothing writes unless you check that box yourself.

Whose data does it see? With anonymous tools, none: they check publicly reachable domains and need neither an account nor a token. As soon as a server reads your own data, access decides the scope. A customer-scoped token should see exactly one customer, and an OAuth connection exactly what the approving account sees itself. Check as well that you can revoke a connection at any time.

Where do requests and results end up? A remote server is a service like any other: location, operator and sub-processors are part of what you have to be able to tell your own clients. The Uptimeify MCP server runs on a European stack in Frankfurt, without US sub-processors. That takes a whole discussion off the table in tenders and data protection conversations.

A fourth point concerns not the server but the way you work: results from tools are data, not instructions. An assistant reading the content of a third-party page should not execute instructions it finds there. Good clients keep that separation; anyone building automation should keep it too.

How do you connect one?

For a remote server, the URL is enough in most assistants. For the Uptimeify MCP server that URL is https://uptimeify.io/mcp. You add it as a remote MCP server and the 20 anonymous check tools are available without an account and without a token. If you also want to read your own monitors, an OAuth approval or an API token comes on top.

Clients that speak stdio only need a small configuration file and a bridge to the HTTP endpoint. Whether a server is reachable, and which tools it offers today, is answered by a single call to the tools/list method.

The step-by-step guide with ready-made configuration, tool list and rate limits lives in its own article: connect an MCP server to Claude. If you just want to look up the terms, the glossary has an entry on the Model Context Protocol.

Where do you find MCP servers?

There is no single official catalogue, but several routes. Many assistants now ship a directory of their own where connected services are added with one click. Alongside those, public collections and registries exist that providers list their servers in.

For a server to appear cleanly there, it publishes two description files at fixed locations: a server card with its capabilities and tool metadata, and a registry manifest for directories. On the Uptimeify MCP server they live at /.well-known/mcp/server-card.json and /.well-known/mcp/server.json.

It is worth a look in both directions before you connect. The server card tells you what a server can do before you add it. And if you build a server yourself, it decides whether clients and directories can present it usefully at all.