What is an MCP server? A plain-English guide to tools, resources and prompts

The problem MCP servers solve

Before MCP, connecting an assistant to a product meant writing an integration for each pair: a ChatGPT plugin for your tracker, a separate extension for Cursor, a custom function set for Claude, and so on. Each assistant had its own format, and each integration was maintained by whoever cared enough.

MCP, published by Anthropic in November 2024 and now governed as an open specification, replaces the pairs with a standard. A product writes one server. Any assistant that speaks MCP (Claude, ChatGPT, Cursor, Codex, VS Code and dozens of others as of October 2026) can connect to it. The assistant does not need to know how the product works underneath, only what the server says it offers.

The analogy that holds up best is the USB port. Before it, every device needed its own connector; after it, any device could plug into any computer. MCP is that connector for AI assistants and the systems they act on.

The three things a server offers

The specification (current revision 2025-11-25) defines three kinds of thing a server can expose. A server does not have to offer all three; many offer only tools.

Tools

A tool is a function with a name, a description, and a JSON Schema that says which arguments it takes. The model reads the descriptions, decides a tool fits the request, fills in the arguments, and the application asks you before running it. Tools are the part of MCP that lets an assistant act rather than only answer.

Our own server exposes 85 tools. A few, to give the flavour: projects_list and project_status read the state of a product; work_create_issue and work_set_issue_status change the backlog; crm_list_deals and crm_move_deal touch the pipeline; calendar_find_time looks for a free slot across people; people_find resolves a colleague by name. Each is marked read or write and names the permission scope it needs.

Resources

A resource is something the model can read for context: a document, a record, a file. The difference from a tool is who chooses. A tool is model-controlled, meaning the model decides to call it. A resource is application-controlled: the app or the person attaches it to the conversation, like dropping a file into a chat. Good servers expose the documents people would otherwise paste in by hand.

Prompts

A prompt is a template the server offers for a common task, with slots for arguments. It appears in the assistant as a command or menu item, the person picks it, and the server fills in the text. They are the least used of the three, and the most useful for turning a server's tools into a workflow someone can repeat without writing the instruction every time.

How an assistant discovers a server

The protocol is JSON-RPC 2.0, the same request-and-response format that language servers in code editors use. A connection goes like this:

1. Initialize. The client sends initialize with the protocol version it supports and its own capabilities. The server replies with its version and what it offers (tools, resources, prompts, and whether it can notify the client when those change).
2. List. The client calls tools/list, and usually resources/list and prompts/list. The server returns each tool's name, description and input schema. The model now knows what it can do.
3. Call. When the model picks a tool, the client sends tools/call with the name and arguments. The server does the work and returns a result: a list of content items (text, usually) and optionally structured data matching an output schema.
4. Notify. If the server's tool list changes, because a person approved a new permission, say, it can send a notification and the client lists again.

A tool that fails in a way the model should know about, such as a refused write or a bad argument, returns a normal result with isError: true and a message. The model reads the message and can try something else, rather than the whole connection breaking.

There is a security principle folded into this: the specification tells applications to treat tool descriptions from a server they do not fully trust as untrusted, and to keep a person in the loop on tool calls. A tool description is just text the server wrote; a malicious server could write a misleading one.

Local and remote servers

Servers come in two shapes, and the difference matters when you choose or build one.

A local server runs on your own machine. The assistant launches it as a subprocess and talks to it over standard input and output (the stdio transport). It usually reads credentials from environment variables. This is how most of the first MCP servers worked: a file-system server, a Git server, a database server you point at your own Postgres. Good for a developer; awkward for a team, because every laptop needs the server installed, updated and given a key.

A remote server runs on the internet at one HTTPS endpoint, using the Streamable HTTP transport, and is shared by many users. You add it to the assistant by URL, sign in through OAuth in the browser, and the server keeps each user's data separate. This is how a hosted product should offer MCP, because nobody wants to install anything or paste an API key into a config file. The Atrix server is remote-only, at https://atrix.dev/api/mcp, for that reason: a workspace is shared, so the connection has to be per-person and revocable.

The MCP server glossary entry goes deeper on the transports; the short version is that stdio is for your machine and Streamable HTTP is for everything shared.

A real tool call, start to finish

Here is what happens when someone connected to our server over Claude Code types "file a bug: the export button on the invoices page does nothing in Safari".

The model reads the tool descriptions it was given at tools/list and picks work_create_issue. The MCP tool glossary entry describes the general shape; the specific call looks like this:

{
  "method": "tools/call",
  "params": {
    "name": "work_create_issue",
    "arguments": {
      "projectId": "Billing",
      "title": "Export button does nothing in Safari (invoices page)",
      "priority": "HIGH"
    }
  }
}

Three things happen before anything is written. Claude Code shows the call and asks the person to approve it. The server checks that the token presented has the work.write scope. The server then checks that the person behind the token is allowed to create issues in that project; a token can never do more than the person who made it. If any check fails, the result comes back with isError: true and a message naming the missing scope, and the model tells the person what to add.

If all three pass, the issue is created, and the result carries its id and link:

{
  "content": [{ "type": "text", "text": "Created BIL-142: Export button does nothing in Safari (invoices page)" }],
  "structuredContent": { "issueId": "BIL-142", "href": "/dashboard/projects/billing?issue=BIL-142" }
}

The call is also audited: which tool, which outcome, which record, never the contents. That audit trail is the difference between an assistant you can give to a team and one you can only give to yourself.

Note that "Billing" was passed as a name, not an id. A server written for assistants should accept names where it can, because the model usually has the name and not the id, and should refuse clearly with the candidates listed when a name is ambiguous.

MCP server vs API vs plugin

People reasonably ask why a server is needed when the product already has a REST API. The three solve different problems.

An API is for programs. A plugin is for one assistant. An MCP server is a thin layer on top of the API, shaped for any model to read: tool names and descriptions a model can choose between, schemas it can fill in, and results it can understand. In practice our server calls the same functions our REST API does; it just describes them differently.

The honest limit: a model choosing from 85 tools is choosing from descriptions, and poorly written descriptions lead to wrong calls. Building a server is less about the protocol, which any SDK handles, and more about naming and describing tools so a model picks the right one.

When a small team should use one

You do not need to build an MCP server to benefit from one. The common case for a team of five to fifteen is connecting an assistant you already pay for to the tools you already use.

Reach for a server when you find yourself copying context into a chat window: pasting the last three issues, the customer's deal stage, the requirements page. A connected assistant reads those itself. It also makes sense when you want to act from the assistant, filing issues or booking time, without switching apps.

Hold off when the server is local-only and you would have to install it on every laptop, or when it asks for a pasted API key with no scopes; a key that can do everything, stored in a config file on five machines, is a liability. And remember that the assistant still only does what its tools allow. Our server, for instance, has no tool that reads a salary, by design.

The MCP feature page lists which assistants connect to Atrix today, and the developer overview has the setup for each.

FAQ

What does MCP stand for?

Model Context Protocol. It is an open specification, published by Anthropic in November 2024, that defines how AI applications connect to outside systems through servers that expose tools, resources and prompts. The current revision is 2025-11-25.

Is an MCP server the same as an API?

No. An API is an interface for programs, documented for developers. An MCP server is a layer on top that describes itself to a language model in a standard format, so the model can discover tools with tools/list and call them with tools/call without anyone writing custom glue. Most servers call an API underneath.

Do I need to write code to use an MCP server?

Not to use one. Remote servers are added to an assistant by URL and authorised in the browser; local servers are usually installed with one command. Building your own server does need code, though the official SDKs (TypeScript, Python, and others) handle the protocol.

Is it safe to connect an assistant to my company's data over MCP?

It depends on the server. Look for per-person sign-in with scopes you choose, permissions resolved on every call so the assistant can never do more than you can, an audit log, and the ability to revoke access. Avoid servers that want a single all-powerful key pasted into a file.

What is the difference between a tool and a resource?

A tool is a function the model decides to call, with the user's consent, and may change data. A resource is data the application or the user attaches for the model to read, and cannot change anything.

Which assistants can connect to MCP servers?

As of October 2026: Claude (web, desktop and Claude Code), ChatGPT, Cursor, OpenAI Codex, VS Code with GitHub Copilot, and many others. Support for remote servers with OAuth varies by assistant; check each one's connector settings.

Next step

If you want to see a server from the inside, the developer overview walks through connecting Claude Code, ChatGPT or Cursor to the Atrix server, with the exact command for each and a list of every tool with its scope. The MCP feature page is the non-technical version. For the vocabulary, the glossary has entries on MCP servers and MCP tools.