MCP, AI tools and agents: what is the difference?

A tool is a function a model can call, an agent is a model choosing its next call, and MCP is a standard way to offer tools. The three are not alternatives. They sit at different layers of the same system, and most production systems that call tools use two of them or all three.

The confusion is understandable, because the words overlap in product names. A chat app may call its tools “agents”, and a vendor may sell an “MCP agent”. The test is simple: a tool runs once when called, an agent decides which calls to make, and MCP only carries the offer and the call.

The tool. A tool is a definition the model reads: a name, a description and a schema for its parameters. The model never runs it. In the words of Anthropic’s tool use documentation, “Claude determines when to call a tool based on the user’s request and the tool’s description.” It then returns a structured call, and your application runs it and sends the result back. OpenAI’s function calling guide describes the same round trip in five steps.

The agent. An agent puts that round trip in a loop. The model reads each result and picks the next call, until the task is done or a limit stops it. Anthropic’s Building effective agents says agents “are typically just LLMs using tools based on environmental feedback in a loop.” The AI agent article walks through that loop in detail.

The protocol. MCP standardizes where the tools come from. The specification defines hosts (the AI applications), the clients inside them, and servers that offer tools, resources and prompts over JSON-RPC 2.0. A host lists a server’s tools, hands them to the model as tool definitions, and forwards each call to the server. What is the Model Context Protocol? covers the protocol itself.

When a product or a design calls something a tool, an agent or an MCP server, four questions say which layer it is really at:

• Who decides? The model decides when to call a tool. In an agent it also decides the order of steps. In MCP the host decides which servers to connect. The specification lets the model choose tools, the application choose resources and the user choose prompts.
• What is standardized? A tool definition is a JSON Schema in each model vendor’s own request format. MCP standardizes how tools are listed and called across applications. The agent loop is not standardized at all: it is your code or your framework.
• Where are permissions checked? In the code that runs the tool, as the person who asked. The MCP specification says so plainly: “MCP itself cannot enforce these security principles at the protocol level.” A server may return fewer tools to a caller with fewer rights, but the check is the server’s own.
• What do you build, and what do you configure? You build a tool: a function and the description the model reads. You configure an agent: a prompt, a set of tools, a model and a limit. You build an MCP server once, around tools you already have, or you configure a client to use someone else’s.

Write a tool when the model needs one capability it does not have: find tickets by symptom, read a part record, draft a reply. Keep it narrow, so its description says exactly when to call it. A good description is most of the work, since it is all the model sees.

Build an agent when the steps cannot be known in advance. A question like “has this pump failed this way before, and why?” may need two searches or five. If the steps are always the same, write them as code that calls the model at fixed points. Anthropic’s guide recommends the simplest system that works, and a fixed workflow when the task is well defined.

Expose an MCP server when tools you already have should be usable from more than one AI application. A team that owns a system can publish its tools once. A coding assistant, a chat app and another team’s agent can then all call them. The tools stay where the data and its owners are.

Consume an MCP server when someone already offers the tools you need, and you trust them. Three questions come first. Who wrote the server? As whom do its tools run? What can its tools change? The specification treats descriptions of tool behavior as untrusted unless they come from a trusted server, and asks that a person can deny tool calls. A description is text the model reads, so it is also a way in for prompt injection.

You do not need MCP to give a model tools. A tool your own application defines and runs needs no protocol at all. MCP pays off when the same tools serve several hosts.

• An MCP server is not an agent. It offers tools and runs them when called. Some servers call a model inside a tool, but to the host that is still one tool call.
• MCP does not replace tool calling. The model still writes the same structured call. MCP decides where the definition came from and where the call goes.
• More tools is not better. Every definition takes room in the context window on every turn, and overlapping tools make the model unsure which to call. OpenAI’s guide suggests fewer than 20 functions at the start of a turn, as a soft limit. Our documentation suggests fewer than about 10 per agent. Choosing what the model sees is the subject of context engineering.
• A protocol is not an access policy. Connecting a server over MCP says nothing about whose rights its tools use. A server that runs every call under one service account gives every caller that account’s reach.

In Curiosity Studio, an AI tool is a C# class whose methods carry a description and described parameters. The model gets only those, never the code. Each call receives the user whose chat invoked it, and the built in tools search and read as that user, record by record.

An agent is a saved configuration: a system prompt, a set of tools and a chat model. Each run is stored as a record, and times out after 5 minutes by default. One agent can hand work to another through a tool that wraps it. A third piece, the skill, is a short Markdown document the assistant reads when it needs it. A skill changes what the model knows, a tool what it can do.

Studio also serves its AI tools over MCP, so an outside MCP client can list and call them. The client connects with an MCP token from Manage → Access → Tokens. The token acts as one user, so the client sees only the tools that user may call. New tools and agents are written in C#, or drafted by Sudo. He stages each change as a diff in his sandbox for a person to approve. The AI agents page has the developer view.