What is an MCP server?

OBTO Team · Insights from the Glass Box

An MCP server is a program that gives an AI model access to tools, data, and prompts through the Model Context Protocol (MCP) — an open standard for connecting AI assistants to the systems where work actually lives. In plain terms: it's the adapter that lets a model like Claude, ChatGPT, or your own agent use your database, your API, or your files through one common interface, instead of being limited to what it was trained on.

If you've heard MCP described as "USB-C for AI," that's the right intuition. Before a standard port existed, every device needed its own cable; before MCP, every AI app wired up every integration its own bespoke way. An MCP server is the standard plug on your side of the connection — expose a capability once, and any MCP-speaking client can use it.

Why MCP servers exist

A language model on its own is sealed off from your world. It can reason and write, but it can't read your latest support tickets, query your warehouse, or file a ticket — unless something hands it those abilities at runtime. The old way to do that was point-to-point: every AI product hand-built a Slack integration, a database integration, a GitHub integration, each in its own shape. N clients times M tools is a combinatorial mess, and almost none of it was reusable.

MCP collapses that. It defines one protocol for how a client and a server talk, so a tool you expose works with any compliant client, and a client you build can use any compliant server. Introduced by Anthropic in late 2024 and since adopted across the major AI clients, it's quickly become the common language for giving models real-world capabilities.

What's actually inside an MCP server

An MCP server exposes three kinds of things, and it helps to keep them straight:

Tools — actions the model can take. A tool is a named function with an input schema: search_incidents(query), create_invoice(customer, amount), send_email(to, subject, body). When the model decides it needs to do something, it calls a tool.
Resources — data the model can read. Think read-only endpoints: a file, a database record, a document the model can pull into context.
Prompts — reusable prompt templates the server offers to the client, so common workflows don't have to be re-typed every time.

Most of the attention goes to tools, because that's where a model stops being a chatbot and starts being able to do things.

How a call actually flows

The mechanics are simpler than they sound. It's a client–server relationship over a transport:

The client (the AI app — Claude Desktop, Cursor, your agent) connects to the server and asks what it offers. The server replies with its list of tools, resources, and prompts.
During a conversation, the model decides it needs one of those tools and produces a structured call.
The client forwards that call to the server.
The server runs the handler — which hits your real database, API, or service — and returns the result.
The model reads the result and continues.

The model never touches your systems directly. It asks; the server decides what's allowed and does the work. That indirection is the whole point — it's where security and control live.

Local vs remote MCP servers

There are two flavors, and the difference matters more than it first appears.

A local MCP server runs on your own machine and talks to the client over standard input/output (stdio). The classic example is a filesystem server that lets Claude Desktop read files on your laptop. One user, one machine, no network — simple and low-stakes.

A remote MCP server runs somewhere else and talks over HTTP, so it can serve many users, agents, and clients at once. That convenience comes with real requirements a local server gets to ignore: it has to authenticate callers it doesn't control, version its tools so an update doesn't break a running agent, and record what happened for debugging and trust. We go deep on that in our guide to hosting a remote MCP server.

What separates a toy from a production MCP server

Standing up a server that works is easy. Standing up one you'd run in production is the actual job, and it comes down to a few things:

Narrow, well-scoped tools rather than one do-everything endpoint — easier for the model to call correctly and easier for you to secure. (More on that in how to build an MCP tool.)
Authentication and least-privilege access, so the server can only ever do what it's supposed to.
Versioning, so you can change a tool without breaking the clients depending on it.
Observability — a record of which tool ran, with what inputs, and what it returned — because an agent you can't inspect is one you can't trust.

Where OBTO fits

This is the layer OBTO is built for. On OBTO an MCP tool is a record you create and version at runtime rather than a binary you redeploy; the server is hosted and secured for you; and every call leaves a Glass Receipt — an inspectable record of exactly what happened. The result is an MCP server you can put real work through, governed by default. If you'd like to see it, getting started walks through your first tool and pricing starts at zero. (For the enterprise framing, see MCP server as a service.)

But you don't need OBTO to use one. The whole point of MCP is that the protocol is open: the server you build, wherever it runs, will speak to any client that speaks MCP.

Frequently asked questions

What is an MCP server in simple terms?

An MCP server is a program that exposes tools, data, and prompts to AI models over the Model Context Protocol. It's the adapter that lets an AI client (like Claude or ChatGPT) use external systems — a database, an API, your files — through one standard interface instead of a custom integration.

What is the Model Context Protocol (MCP)?

MCP is an open standard, introduced by Anthropic in late 2024, that defines how AI applications connect to external tools and data. It's often described as "USB-C for AI": one common port so any compliant client can talk to any compliant server.

What's the difference between an MCP server and an MCP client?

The client is the AI application (Claude Desktop, Cursor, an agent) that wants capabilities. The server is the program that provides them. The client discovers what a server offers and calls it; the server runs the work and returns the result.

What are tools, resources, and prompts in MCP?

Tools are actions the model can call (functions with an input schema). Resources are data the model can read (like read-only endpoints). Prompts are reusable templates the server offers. Tools are what let a model do things rather than just talk.

What's the difference between a local and a remote MCP server?

A local server runs on your machine over stdio for a single user (for example, a filesystem server). A remote server runs over HTTP and serves many clients and agents at once — which means it also needs authentication, versioning, and observability.

Do I need to be a developer to run an MCP server?

To hand-build one, yes — it's code. Platforms like OBTO let you create and host MCP tools as versioned records without standing up and maintaining the server infrastructure yourself, which lowers the bar considerably.