MCP servers: the proper way to plug AI into your systems

The Model Context Protocol (MCP) is an open standard that lets AI assistants use your systems through a defined interface instead of copy and paste. You build an MCP server that offers a small set of tools, such as "find a customer" or "draft an invoice". The assistant can discover those tools and ask to use them, and your server decides what is allowed, checks every input and talks to the real system with its own credentials.

Where MCP came from

Anthropic published MCP as an open standard in November 2024. In December 2025 it donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. By then it was supported in ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code, among others.

The specification moves quickly. The current revision, dated 28 July 2026, made the protocol stateless: every request now carries what the server needs to know, which makes servers simpler to run behind ordinary web infrastructure.

What a server offers

An MCP server can expose three kinds of things:

• Tools are actions or queries the model can ask to run: look up an order, create a draft, search the documentation.
• Resources are pieces of data the assistant can read, such as a file or a record.
• Prompts are reusable templates the user can pick from.

For a business, tools are where the value is, because they connect the assistant to the systems work actually happens in.

How one tool call travels

You

ask a question

AI assistant

MCP client

Your MCP server

tools you define

Your systems

CRM, documents, database

tools/list

1. 1The assistant asks your server which tools exist. Each comes with a name, a description and a schema for its inputs.
2. 2The model decides a tool would help and proposes a call. You see the inputs and approve it.
3. 3The assistant calls the tool. Your server checks the caller's permissions and validates the inputs.
4. 4Your server talks to the real system, with its own credentials, and returns only what the tool is meant to return.

What a tool looks like

A tool is described by a name, a description the model reads, and a JSON Schema for its inputs. This is a simplified version of what a server returns when an assistant asks which tools exist:

{
  "name": "find_customer",
  "title": "Find a customer",
  "description": "Look up a customer by company name or email address. Returns contact details and open orders. Read only.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Company name or email address"
      }
    },
    "required": ["query"]
  }
}

When the model decides to use it, the assistant sends a tools/call request with the tool name and the arguments. The server runs its own code (here, a query against your CRM with a read-only account) and returns only the fields the tool is meant to return.

The description matters more than it looks. It is what the model reads to decide when to use the tool, so it should say plainly what the tool does, what it returns and what it will not do.

Why not just give the assistant an API key?

Because an API key gives access to everything the key can do, and an MCP tool gives access to one narrow thing. With a server in between:

• Permissions are explicit. A tool that reads customers cannot delete them.
• Inputs are validated before anything reaches your system.
• Every call is logged on your side, with who asked and what came back.
• Credentials stay with you. The model never sees the database password or the API key.

The specification itself says servers must validate all tool inputs, implement proper access controls, rate-limit tool invocations and sanitise tool outputs, and that clients should ask the user to confirm sensitive operations.

When it is worth building one

An MCP server is worth it when people keep copying data out of a system into an AI chat and pasting the answer back, when several AI tools need the same access, or when you want one governed way in instead of a dozen ad hoc integrations.

It is not worth it for a one-off task, or when the vendor already provides an official MCP server that does what you need. In that case use theirs, and check where it runs and what it can access.

Who controls the data

An MCP server runs wherever you deploy it, in your own cloud account and in the region you choose. The credentials to your systems stay on that server. The model, wherever it runs, only receives what your tools choose to return. That makes MCP a practical way to use a capable model without handing it the keys to your business.

Sources

1. Tools, Model Context Protocol specification (2026-07-28) modelcontextprotocol.io
2. Key changes in the 2026-07-28 specification modelcontextprotocol.io
3. Donating the Model Context Protocol and establishing the Agentic AI Foundation Anthropic, December 2025
4. MCP joins the Agentic AI Foundation Model Context Protocol blog