What is the Model Context Protocol (MCP)?
A plain guide to MCP: what the Model Context Protocol is, how MCP servers and clients talk, what tools, resources and prompts are, and how to host a server.
In this post
- What MCP is and the problem it solves
- Hosts, clients and servers
- Tools, resources and prompts
- Local and remote servers, and where hosting comes in
The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need. Instead of every AI app writing its own integration for every service, a service is wrapped once as an MCP server, and any app that speaks MCP can use it.
Why MCP exists#
Before MCP, giving a model access to a ticket tracker, a database or an internal API meant a custom integration for each AI app: one plugin for a chat app, another for an IDE, another for your own agent. Ten apps and ten services meant up to a hundred integrations. MCP turns that into one server per service and one client per app.
Anthropic published MCP as an open specification in November 2024. OpenAI, Google, Microsoft and others have since added support, and in December 2025 Anthropic donated it to the Agentic AI Foundation, a fund under the Linux Foundation.
Hosts, clients and servers#
- Host: the AI application a person uses, such as Claude Desktop, ChatGPT, Cursor or VS Code
- Client: the connection a host opens to one server; a host can hold many at once
- Server: a program that offers tools, resources or prompts, such as a ticket tracker or a database wrapped for MCP
Client and server exchange JSON-RPC 2.0 messages. When they connect, they agree on a protocol version and on what each supports, then the client asks the server what it offers.
Tools, resources and prompts#
| Primitive | What it is |
|---|---|
| Tools | Functions the model can call, each with a name, a description and a JSON Schema for its input |
| Resources | Data the application can read into context, such as a file, a document or a record |
| Prompts | Reusable templates a person can pick, such as "summarise this incident" |
Tools are what most people mean when they talk about MCP. The model reads each tool's description, decides when to call it, and gets a structured result back. A call looks like this:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "create_ticket",
"arguments": { "summary": "Checkout fails on Safari" }
}
}Good tools have a narrow input and return only what the model needs. A vague description is the most common reason a tool is never called.
Local and remote servers#
MCP defines two standard transports. With stdio, the host starts the server as a local process and talks to it over standard input and output, which suits tools that work on files on your own machine. With Streamable HTTP, the server runs on the network and clients reach it by URL, so one server can serve many people and many apps.
Remote servers need sign-in. MCP's authorization builds on OAuth 2.1: the client discovers the server's authorization server, registers itself and gets an access token for the user, so nobody pastes API keys into a chat app.
Building and hosting an MCP server#
Official SDKs for TypeScript, Python, Go and other languages let you write a server yourself. Running it for other people takes more: a public HTTPS endpoint, OAuth, secrets for the APIs your tools call, deploys, scaling and logs. Self-hosted vs managed MCP servers compares the two ways to run that part.
On Glxymesh, a project is one MCP server. You describe each tool in a tool.yml, add a run function in Go, TypeScript or Python if it needs code, and push. The platform builds and tests it, runs it in the project's own AWS Lambda, and serves every tool from one authenticated endpoint over Streamable HTTP.
$ gxmesh init --lang node --project helpdesk $ gxmesh new create-ticket $ gxmesh push
The MCP server tutorial walks through it step by step, and connecting MCP servers to AI clients covers what happens when Claude or ChatGPT signs in.
