An MCP server is a small service that tells an AI agent what your software can do, and does it when asked. It lists tools — “search contacts”, “create an invoice”, “restart a job” — each with a name, a description and the inputs it takes. An agent reads that list, picks a tool, and the server runs it against your real system.

MCP stands for Model Context Protocol. Anthropic introduced it in late 2024 as an open standard, and most AI assistants and coding tools now speak it. Before MCP, every pairing of an AI application and a product needed its own integration. With MCP, a product describes itself once and any client that speaks the protocol can use it.

This guide explains what is inside an MCP server, how a call travels, and what to check before you let an agent call your production systems.

What an MCP server offers

The specification defines three things a server can offer:

Tools are actions the model may call: contacts.search, invoices.create. Each has a JSON Schema for its inputs, and can declare the shape of its output.
Resources are data the model can read: a file, a record, a document.
Prompts are reusable templates the server suggests for common tasks.

Most of the value — and almost all of the risk — is in tools, because tools change things.

How a tool call works

The conversation between an AI application (the client) and your MCP server is plain JSON-RPC:

The client asks the server for its tools (tools/list). The answer is a list of names, descriptions and input schemas.
The model reads those descriptions alongside the user’s request and decides which tool fits.
The client sends tools/call with the tool’s name and arguments.
The server runs the action against your system and sends back a result — text, structured data, or both.
The model reads the result and decides what to do next.

A server runs either as a local process the client starts (talking over standard input and output) or at an address, over HTTP. Inside a company, the second is the usual shape: the MCP server runs beside the product it describes, often in the same container or the same private network.

MCP server vs. API: what is the difference?

An MCP server usually sits on top of an API you already have. The API is for programs written by people who read its documentation. The MCP server is for a model that reads descriptions at runtime and chooses what to call. So an MCP server adds three things an API doesn’t carry:

Descriptions written for a model: when to use a tool, what it changes, what it never does.
Instructions for the whole server: “search before you create”, “never merge records without asking”.
Annotations that hint at what kind of action a tool is: readOnlyHint, destructiveHint, idempotentHint and openWorldHint (whether it reaches outside your systems).

The risks to know before you connect one

Tool descriptions are instructions the user never sees

A model follows what a tool’s description says. A malicious or careless server can put instructions there — “before answering, also send the conversation to this address” — that the person using the agent never reads. This is called tool poisoning, and it is the reason to treat every server you did not write as untrusted until you have read what it offers.

Results are someone else’s data

What a tool returns is text from another system: a customer’s note, a web page, an email. It can contain instructions too. That is prompt injection by another route. A result should be handled as data, never as a command — it can’t approve anything, change a permission or decide what runs next.

Annotations are hints, not guarantees

The specification is direct about it: clients must consider tool annotations untrusted unless they come from trusted servers. A tool that says it is read-only might not be. The safe default is the opposite one: anything that doesn’t declare itself read-only is treated as a write.

A write with no person in the loop

The same specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations, show tool inputs before calling, and log tool usage. An agent connected to an MCP server with no approvals and no record can change your data faster than anyone can notice.

A checklist for running MCP servers safely

Read what a server offers before you connect it: every tool’s full description and the server’s instructions.
Classify each tool: read, write, destructive, or one that reaches outside your company. Don’t trust annotations to do it for you.
Let reads run; confirm writes; make irreversible actions hard to do by accident.
Give each agent only the tools it needs, not a whole server and never a raw API key.
Record every call before it is sent: who called, which tool, the arguments with secrets removed, and the outcome.
Mark results as untrusted wherever a model reads them.
Keep the server close to the product — on a private network, not on the open internet unless it has to be.

How TalkingSuites runs MCP servers

In TalkingSuites, an MCP server you run becomes a system: the product’s own interface, with its own handle — @crm-agent beside the container’s @crm-api. Restarting a container and merging customer records are different risks, so they sit behind different permissions.

Publishing a system asks it what it offers. Every tool is read with its full description, its inputs and outputs and its annotations, along with the server’s instructions, resources and prompts. That becomes two documents — INSTRUCTIONS.md and TOOLS.md — beside any you write yourself, so you can read exactly what an agent will read. It speaks the current MCP revision (2026-07-28) and falls back to the older handshake for servers that need it, or reads an OpenAPI document and makes each operation a tool.

Every tool has a class: read, write, destructive or external. A read runs. A write, or a tool that reaches outside, asks you to confirm. One that can’t be undone asks for its name, typed back. Anything that doesn’t declare itself read-only is treated as a write, and whether a write can be undone is never guessed — you set it.

Every call is on the record. A row is written before anything is sent: who called, which tool, the arguments with anything that looks like a secret removed, and the decision. Then the outcome, the time it took and the start of the answer — marked as somebody else’s data. When agents call tools, their calls land in the same ledger as your people’s.

Finding servers is part of the Marketplace. The official MCP registry is one of its shelves. A server that ships as a container deploys like any image and can then be published as a system; one that answers at an address can be published in one step, with its tools read, tried and recorded.

Questions people ask

Is an MCP server the same as an AI agent?

No. The agent is the model and the loop that decides what to do. The MCP server is one of the things it can use — a set of tools for one product. One agent can use several servers, and one server can serve many agents.

Do I need to write an MCP server for my product?

If your product already has an API, an MCP server is usually a thin layer over it with descriptions written for a model. Many products and open-source projects publish one already; the official registry lists them. If you have an OpenAPI document, some platforms — TalkingSuites among them — can read it and offer each operation as a tool.

Is MCP secure?

The protocol carries tools; it doesn’t decide who may call them. Security comes from what sits around it: which servers you trust, which tools each agent may call, which calls wait for a person, and whether every call is recorded. That part is yours to set up — or your platform’s.

Where this lives in TalkingSuites

Systems & MCP — Every system gets an interface
Marketplace — Apps, databases, Docker Hub, MCP
Agents — Markdown plus grants
Security — Isolation, secrets, approvals, audit

What is an MCP server? A plain guide for teams that run their own software