An MCP server is a program that connects to an AI model's client and answers the question "what can you do, and at what cost of context?" over the Model Context Protocol — the open protocol that standardizes how a model discovers tools, reads data, and reuses prompts. The definition has three parts, and all three must hold or the integration is a bespoke API wrapper, not an MCP server: it speaks the protocol (JSON-RPC framed, capability-negotiated), it declares what it offers up front (a typed catalog a client can enumerate before calling anything), and it runs as a separate process (or remote service) from the model, so the AI application and the capability can be written, deployed, and owned by different teams. This guide defines the term properly, shows how it differs from a plain REST API, maps the six capability classes the protocol specifies, and says where Devotel Orbit's shipped MCP surface sits.
The definition in plain language
When a developer connects an AI assistant to an external system — a database, a communications platform, a ticketing queue — the two sides need a shared way to answer one question: what can you do? Before MCP, every assistant framework answered that question with its own custom glue: a function-calling schema for one SDK, a plugin manifest for another, a one-off integration for each combination.
The Model Context Protocol (MCP) standardizes that answer. An MCP server is the program on the offering side: it declares a typed catalog — which actions it can run, which data it can serve, which prompt templates it carries — and any MCP client (an IDE assistant, an agent framework, a hosted agent runtime) discovers that catalog and calls into it over a defined transport. An MCP client is the program on the consuming side — usually embedded in the AI application — that connects, negotiates capabilities, and dispatches the model's requests.
The protocol is model-agnostic in one specific sense: the contract between client and server is fixed, so a server written once works with any client, and the client can sit in any assistant that implements it.
How an MCP server differs from a tool or a plain API
The analogy that lands: an API endpoint is a phone number; an MCP server is the directory. A REST API answers only the request it was sent — you have to know the number before you dial. An MCP server publishes the directory first, in a machine-readable form the model can enumerate before it decides what to call. That changes who can use the integration: with a plain API, wiring a model to your platform is a per-model, per-sdk integration project; with an MCP server, it is a posture question — the same catalog your own developers read is the one the model reads.
A tool in model vocabulary is a single callable function. An MCP server is the host that organizes tools — and the other capability classes below — behind one connection. So "MCP server vs tool" is a scope question (one catalog vs one function), and "MCP server vs API" is a discovery question (a stated contract vs implicit knowledge). Neither claim needs a platform mandate to hold true; they follow from the published protocol.
The six capability classes
The protocol specifies six classes of capability a server can offer or the two peers can negotiate, grounded in the published MCP documentation:
- Tools — executable functions the model can call with typed arguments and readable results, e.g. "send a message," "look up a contact." Tools are the capability that separates an assistant that reads from one that acts.
- Resources — addressable data the client can pull into the context window: files, records, configuration. A resource read gives the model grounded material to reason over instead of guessing.
- Prompts — reusable prompt templates a server exposes. A platform that already knows "here is the runbook for a failed webhook" can hand the assistant that scaffold instead of the user re-authoring it per session.
- Sampling — the reverse direction: a server asking the client to run a model call on its behalf. Sampling lets a capability mid-workflow request generation without owning the model connection itself.
- Roots — boundaries the client advertises for what the server may see: workspace directories, allowed scopes. Roots are how a server learns the edges of what it is allowed to touch.
- Transports — how the two sides carry the framed messages: stdio between local processes, or an HTTP-based transport for remote servers. The protocol defines the message layer independently of the wire it runs on.
Not every server implements every class. A read-only server has tools and resources and no sampling; a template server carries prompts and little else. The catalog tells the client which classes exist before anything is invoked.
Where Devotel Orbit's shipped MCP surface sits
Devotel Orbit ships an official MCP server: a read-write server whose tools call into the same conversations, campaigns, contacts, and knowledge base the dashboard uses, driven by the same LangGraph agent runtime that powers Orbit's own AI agents. The tool surface and the operational surface are one system, so an assistant connected over MCP can both look things up and complete an action — send a message, dial a number, create a contact — which is the dividing line that matters in the official-server comparison.
For the side-by-side scoring of the four official communications MCP servers, see the head-to-head comparison. For how MCP connects to the agent-to-agent protocol (A2A) used between agents (rather than model-to-server), see the A2A protocol explainer. The scope of what an agent may do through those tools — which actions require approval, which lanes are restricted — stays tenant-owned: the catalog defines what is callable; your policy defines what may be called.
Related reading
- MCP servers for communications, head to head — the four official servers scored on read-write coverage and agent-runtime depth.
- The A2A protocol for agent communications, explained — the sibling protocol that governs agent-to-agent traffic.
- MCP server for communications explainer — Orbit's own tool surface, walked endpoint by endpoint.
- MCP server for CPaaS communications — where the tool surface reaches for communications workloads.
- Multi-agent squads over A2A and MCP — where the two protocols split inside an account.
Frequently asked questions
What is an MCP server, in one sentence?
A program that speaks the Model Context Protocol and publishes a typed catalog — tools, resources, prompts — that any MCP client can discover before the model calls into it.
How is an MCP server different from calling the API directly?
A plain API answers only the request it was sent; an MCP server publishes a machine-readable catalog first, so the model can enumerate what exists before deciding what to call. That turns wiring a model to your platform from an integration project into a discovery step.
Do I need an MCP server to use an AI agent?
No — it is one integration shape among several. It earns its cost when you want the model to discover capabilities instead of learning them from injected schemas, or when the same capability should serve more than one assistant.
Which capability classes does a server have to implement?
None are mandatory. The class catalog is a menu: tools for actions, resources for data, prompts for templates, sampling for server-initiated generation, roots for scope boundaries, and transports for the wire. A server declares the subset it implements, and the client negotiates on connect.
Where does Orbit's MCP server sit relative to a custom integration?
It is the official server — the tools call into the same conversations, campaigns, contacts, and knowledge base the dashboard uses, on the same agent runtime. A custom integration against Orbit's REST API reaches the same account; the MCP server is the discoverable, pre-typed route in.