An MCP server is a small program that lets an AI assistant such as Claude, ChatGPT or a coding tool reach one specific system through the Model Context Protocol, an open standard. It exposes named tools the assistant can call, resources it can read and prompts it can offer, and it decides who may use each. Your data stays where it is. The server is the supervised way in.
What problem does MCP solve?
MCP gives every AI app one way to connect to every system, instead of a custom integration for each pair. Before it, each assistant needed its own glue code for each system.
The protocol has three roles. The host is the app a person uses, such as Claude Desktop. Inside it, an MCP client connects to each MCP server, the part you build or install, which talks to one system and describes what it can do in a format every client understands. Build the server once and any compliant client can use it. Underneath, each client still hands the server's tools to its model through ordinary function calling. How the two layers differ, and when plain function calling is enough, is in MCP vs function calling.
Anthropic released MCP as an open specification, and in December 2025 donated it to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI. For a buyer, that means a server you commission is not tied to one vendor's assistant.
What are tools, resources and prompts?
They are the three things a server can offer. Tools do things, resources are things to read, and prompts are reusable instructions a person can pick from a menu.
- Tools are functions the model decides to call, each with a name, a description and a typed list of inputs. "Search contacts by company", "create a room booking" and "draft an email" are tools.
- Resources are data the client can read into context, such as a file or a record, usually chosen by the app or the person.
- Prompts are templates the server publishes, such as "summarize this account". The person chooses to run one.
Most business servers are mostly tools. Not every client supports all three, so check the client's documentation before designing around resources or prompts. Beyond the core, the protocol now has optional extensions, including MCP Apps for interactive views such as charts and forms inside the conversation, and Tasks for long-running jobs. Both need support in the client as well as the server.
What is the difference between a local and a remote MCP server?
A local server runs on the user's own computer and talks to the app directly. A remote server runs on the internet, at a URL, and people connect to it by signing in.
| Local server | Remote server | |
|---|---|---|
| Where it runs | On each user's machine, started by the app | On a hosted service, reached over HTTPS |
| How it connects | Standard input and output (stdio) | HTTP, usually the Streamable HTTP transport |
| How it gets credentials | From the local environment, such as a key in a config file | OAuth sign-in in a browser |
| Setup per person | Install and configure on every machine | Paste a URL, sign in |
| Good for | Local files, developer tools, one person's experiments | Shared business systems used by a team |
| Who maintains it | Whoever set up that machine | One owner, one deployment |
For a team, remote is usually right: one copy to update, one place to log activity, and no API key in a text file on somebody's laptop.
How does sign-in work on an MCP server?
Remote servers use OAuth, the same sign-in pattern behind "Sign in with Microsoft" or "Sign in with Google". The person clicks connect, a browser window opens, they sign in, and the app receives a token that works only for that server.
For the technical reader: the MCP authorization specification is built on OAuth 2.1. Authorization is optional in the protocol, but when an HTTP server uses it, the server acts as an OAuth resource server, answers an unauthenticated request with a 401 and a WWW-Authenticate header, and publishes Protected Resource Metadata (RFC 9728) that tells the client which authorization server to use. Clients use PKCE and send a resource parameter (RFC 8707) so the token is bound to that one server. The server must reject tokens not issued for it and must not pass them through to other APIs. For registering the client, the current revision prefers Client ID Metadata Documents and marks Dynamic Client Registration as deprecated. Local stdio servers skip all of this and read credentials from their environment.
The current revision of the specification, dated July 28, 2026, also made the protocol stateless: there is no connection handshake or session, and every request carries what the server needs to answer it. For a business that mostly means remote servers are easier to scale, because any copy of the server can answer any request.
For the business reader: because the server knows who signed in, it can apply that person's permissions, record what they did, and write as a named person rather than a shared key.
Which AI apps support MCP?
Most major AI assistants and developer tools now act as MCP clients. The protocol's own site lists Claude, ChatGPT, Visual Studio Code, Cursor and many others, and Google's Gemini CLI documents MCP server support as well.
In Claude, remote servers are added as custom connectors, and Anthropic's help center says they work in Claude, Cowork and Claude Desktop on free, Pro, Max, Team and Enterprise plans. Free accounts are limited to one custom connector. On Team and Enterprise, only an Owner can add a custom connector for the organization, and each person then connects and signs in individually. The server has to be reachable over the public internet from Anthropic's IP ranges, because Anthropic's side makes the connection, so a server that only exists inside your office network will not work as a custom connector. Claude Code connects to MCP servers too, including local ones.
Support is not uniform: clients differ in transports, primitives and sign-in flows, and those details change between releases. Test against the exact clients your team uses.
Where is the security boundary?
The boundary is the server, not the model. Anything a tool can do, the model can be talked into doing, so the limit has to be enforced in code the model cannot change.
- Scope each tool to one job. "Read order history" and "issue a refund" are two tools with two permission levels, not one tool with a flag.
- Treat content as untrusted. A customer email or web page the model reads can contain instructions. This is prompt injection, and the defense is that the dangerous action is not available, or needs approval, regardless of what the text says.
- Put people before consequential writes. Draft instead of send. Offer a dry run. Require a confirmation step for money, access and anything external.
- Log every call: who, which tool, what inputs, what happened.
- Vet third-party servers like any vendor with access to your data.
When does a business need its own MCP server?
You need one when people keep copying information between an AI assistant and a system it cannot reach. If the task only needs better instructions, a Skill is enough. If a vendor already publishes a connector for the tool, start there.
A custom server earns its place when the system is internal or niche, when several tools must combine into one workflow, when you need your own permission rules over a vendor's API, or when the data is public but scattered.
At altr we build remote MCP servers on Cloudflare Workers. For spARK Labs, one Worker connects Claude and Claude Cowork to four operations tools behind Microsoft sign-in, with a dry run flag on building access and email left as drafts (case study). For Tampa commercial real estate, a connector puts four counties of property records inside Claude (case study). Why Workers, and how one stateless deployment serves several teams, is in our architecture write-up. The design rules we follow for tool boundaries, schemas and audit are in MCP server design for internal AI tools.
An MCP server is only as safe as its narrowest tool. Decide what the assistant may do, write that into the server, and let sign-in decide who may ask.
Common questions
What is an MCP server in simple terms?
An MCP server is a connector, built on the Model Context Protocol (MCP), that lets an AI assistant use one of your systems, such as a CRM, a database or a booking tool. The server tells the assistant what actions are available, runs them when asked, and checks who is signed in first.
Is MCP only for Claude?
No. Anthropic created the Model Context Protocol, but it is an open standard now governed under the Linux Foundation, and clients including ChatGPT, Visual Studio Code, Cursor and Gemini CLI support it. A server built to the specification can be used from any compliant client, though each client supports a different subset of features.
Is an MCP server the same as an API?
No. An API is how software talks to a system. An MCP server usually sits in front of one or more APIs and describes them in a form an AI model can discover and call, with names, descriptions and typed inputs, plus the sign-in and permission rules for AI use.
Does my data leave my system when I use an MCP server?
The data stays in your system until a tool is called. When the assistant calls a tool, the result is returned into the conversation and processed by the AI provider under that provider's data terms. Design tools to return only what the task needs.
Do users need API keys to connect to a remote MCP server?
Not when the server uses OAuth. The user pastes the server URL into their AI app, signs in through a browser, and the app holds a token scoped to that server. Local servers often do use keys stored in a configuration file.
What is the difference between an MCP server and a Claude Skill?
An MCP server gives Claude access to a system it could not reach before. A Skill is a set of instructions and files that teaches Claude how to do a task well with the access it already has. Many workflows use both.