MCP & AI TOOLS
What is MCP?
An open standard that lets AI apps connect to outside tools and data the same way, so a data source is integrated once instead of once per AI tool.
The problem it solves
Three AI tools and three data sources make 9 integrations. Each tool had its own plugin format, its own way of describing what a data source could do, its own way of passing results back. A team that wanted ChatGPT, Claude and Cursor to see the ERP, the CRM and the accounting system had to build the connection three times over, and build it again when a fourth tool arrived. N tools times M sources, and both N and M grow.
MCP, the Model Context Protocol, replaces the multiplication with addition. Each tool speaks MCP once. Each data source has one MCP server. Any tool that speaks the protocol can use any server, so a new tool costs one integration and a new source costs one server.
The three parts
The host is the AI application - the chat window, the desktop assistant, the code editor. It is where the person types and where the model runs or is called from. The host decides which servers it is connected to and shows the person what the model is doing with them.
The client is the connection the host keeps open to one server. One host can hold several clients, one per server, and each client handles the back-and-forth: listing what the server offers, sending calls, receiving results. For most purposes "client" and "the AI tool" mean the same thing, and this site uses them that way.
The server is the program that exposes something: a data source, a system, a set of operations. It publishes what it can do in a form the model can read, and it does the work when called. The server knows nothing about which model is on the other end, and does not need to.
Keeping the three apart matters when something goes wrong. A tool that is not found is a server question; a tool that is called with the wrong arguments is a model question; a server that cannot be reached is a host question. Most confusion about MCP in practice comes from blaming the wrong one of the three.
What a server offers
Three kinds of thing. Tools are operations the model can call, each with a name, a description in plain language, and a schema for its arguments: search a collection with these filters, count records by this field. Resources are things the model can read: a document, a record, a file, addressed by a URI. Prompts are ready-made instructions the server offers to the host, for tasks it knows how to guide.
For business data, tools are the part that matters. A question about orders is answered by calling a search or a facet tool with the right arguments and reading the structured result, and the quality of the answer depends on how well the tools are described and how well their results are shaped. Resources and prompts are useful; tools are the point.
A plain-language walkthrough
You ask Claude for the top products in the North region. Claude has a client connected to a server that exposes your indexed collections, and when the conversation started it fetched the server's tool list, so it knows there is a tool that searches collections and takes a collection name and filters. It decides that tool fits, fills in the arguments - collection products, region North - and sends the call. The server runs the search against the data and returns rows, as structured data rather than prose. Claude reads them and writes the answer: a sentence and a short table.
- You askIn the AI client, in plain language."Top products in the North region"
- The model picks a toolIt reads the server's tool list and chooses one, with arguments.
search(collection: "products", filters: {region: "North"}) - The server does the workIt runs the search against the data and returns structured rows.rows and counts, as data
- The model writes the answerA sentence and a table, from what came back."The top products in North are…"
Two things are worth noticing. The model chose the tool; nobody wrote code that said "when asked about products, call search". And the server did the work; the model never saw the whole collection, only the rows that came back for that call. That division - the model decides, the server executes - is what makes MCP useful for data, and it is the same division an assistant built into a product uses. How can AI answer questions about business data? follows it in more detail.
Local vs remote servers
The first MCP servers ran as a process on one person's machine, started by the host, talking over standard input and output. That is still how a developer connects an editor to a local tool. It does not suit a company. The server has to be installed on every laptop, it has the credentials of whoever is running it, and there is no central place to see who asked what.
A remote server is an HTTP endpoint that a team shares. It is deployed once, inside the company's infrastructure, next to the data it serves. Every client connects to the same address with its own key, the server is updated in one place, and the access log is in one place. For business data that is the shape companies want, because the data is already inside the boundary and the server can sit beside it.
The two are not rivals; they are stages. A developer prototypes against a local server, and the team runs the same tools from a remote one once more than one person needs them. The protocol is the same over both, so a tool written for one is served by the other without change.
Keys and control
A remote server is reached with an endpoint and an access key. The client gets only what the server exposes - the tools it publishes, over the data those tools can reach - and nothing else, because nothing else is on the wire. Keys are issued by whoever runs the server, so a team or a tool can have its own, a key can be rotated on a schedule, and a key can be revoked the moment it should be. No key, no connection. The access decision lives with the server's owner, not with the AI tool's vendor.
What MCP is not
It is not a model: it carries calls to and from one, and any model that a host supports can use it. It is not RAG: RAG retrieves passages for the model to read, and MCP could be used to fetch them, but the protocol itself retrieves nothing. It is not a database: it is a way to ask one, through tools someone chose to expose. The plug, not the appliance. What the appliance does - search, count, read a document, send an email - is entirely up to the server behind it.
Who supports it
ChatGPT, Claude, Cursor and a growing list of other MCP-compatible clients, including assistants companies build for themselves. Because the protocol is open and published, support does not depend on a partnership between any two vendors: a client that implements it can connect to a server that implements it. The specification is maintained in the open at modelcontextprotocol.io.
What goes over the wire
MCP is a message protocol built on JSON-RPC. When a client connects, the two sides exchange an initialize handshake that states which version of the protocol and which capabilities each supports. The client then asks for tools/list and receives every tool's name, description and argument schema. A call is tools/call with the tool name and arguments, and the response carries the result as structured content. Resources and prompts have matching list and read or get messages.
Two transports carry those messages. A local server speaks over standard input and output, which is why a host can start it as a child process. A remote server speaks over HTTP, which is what makes a shared endpoint possible, and authentication rides on that connection the way it does for any other HTTP service - a bearer key in the request. Everything above the transport is identical, which is why a tool written for one can be served over the other.
The description text of each tool is not decoration. It is what the model reads when it decides which tool to call and how to fill the arguments, so a server for business data is largely a well-written description of what its collections contain. MCP server explained covers what such a server should publish and what it should keep back.