When an AI agent uses a tool through MCP, the app first asks a server which tools exist, the model picks one, the app sends the request to the server, and the result goes back to the model. The model never touches the tool directly. Software in the middle does the work.
TL;DR
- MCP is a standard way for an AI app to talk to outside tools.
- There are three parts: the host app, a client inside it, and the server that offers the tools.
- A tool call is a short, structured message with a tool name and some inputs.
- Each step is a place to check, approve, or log. Most safety comes from those checkpoints.
Definition box. The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. Its introduction compares it to a USB-C port: one standard plug that lets many different devices connect the same way. A tool in MCP is an action a server offers, such as "get the weather" or "create a ticket," described with a name, a plain description, and the inputs it needs.
Who are the players in an MCP setup?
The MCP specification describes three roles.
- The host is the AI application you use, such as a chat app or a coding assistant. It controls which connections are allowed and handles your approvals.
- The client lives inside the host. Each client keeps a one to one connection with a single server.
- The server offers the tools. It can be a small program on your own computer or a service on the internet.
Picture a hotel. You are the guest. The host is the front desk. The client is the desk clerk assigned to one department, such as the restaurant. The server is the restaurant kitchen. You never walk into the kitchen. You ask the desk, and the desk passes on a clear request.
The specification also says servers should not be able to read the whole conversation or see into other servers. The host keeps the full conversation, and the host decides what each server gets to know.
What happens when you ask an agent to do something?
Here is the full path, in order. The example request is "What is the weather in New York, and should I bring an umbrella?"
- Discovery. When the connection starts, the client asks the server for its list of tools. The server replies with each tool's name, description, and the inputs it accepts. In the MCP specification, the example is a tool called get_weather that takes a location.
- Offering. The host gives the model the list, along with your question. The model now knows what it may ask for.
- Choice. The model decides the weather tool fits and returns a request to use it, with the input "New York."
- Check. The host may show you the request and ask for a yes. The specification says there should always be a human in the loop with the ability to deny tool invocations, and that applications should present confirmation prompts for operations.
- The call. The client sends the request to the server.
- The result. The server does the work and returns the answer, such as temperature and conditions. If it fails, it returns an error that the model can read.
- Using the result. The host passes the result back to the model, which writes your answer in plain words.
The model made a choice in step three. Everything else was software following rules. That split is the reason checkpoints work. You can put a rule at steps one, four, five, and six without trusting the model's judgment.
Where can something go wrong along the way?
Each step has its own weak spot.
| Step | What can go wrong | A simple defense |
|---|---|---|
| Discovery | A server lists a tool that was not on the approved list, or changes the list later | Keep an allowlist of tools and review changes |
| Offering | A tool description hides instructions meant for the model | Treat descriptions and annotations as untrusted text |
| Choice | The model picks a tool or inputs a person would not | Narrow tools, limits on inputs |
| Check | People click yes without reading | Show the full inputs, keep prompts rare and meaningful |
| The call | The call goes out with too much power, such as a token with every permission | Give each agent only the access it needs |
| The result | The result holds hidden instructions or private data | Check results before they reach the model |
The tools section of the specification backs several of these. It says clients must treat tool annotations as untrusted unless they come from trusted servers. It says clients should show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration, which means data leaving without permission. It also says clients should validate results before passing them to the model, set timeouts, and log tool use for audit purposes. Servers must validate all inputs, apply access controls, limit how often tools can be called, and sanitize outputs.
Worked example: an invented ticket tool
The following numbers are invented for illustration.
Say a team connects an agent to a ticket server with four tools: search tickets, read ticket, add comment, and close ticket. During a one hour test, the agent makes 40 calls.
- 28 calls are search or read.
- 9 calls add comments.
- 3 calls try to close tickets.
The team reviews the log and sees the three close attempts all came right after reading tickets that contained the phrase "please close this." Two of the three were on tickets the agent had no reason to close. The team now has a clear finding. They remove the close tool from the agent, and they require a person to approve any close request in future. Without the log, they would never have seen the pattern. Without the narrow tool list, the damage could have been larger.
For a closer look at the rules that apply to tool results, read MCP tool errors: protocol versus execution and are MCP tool descriptions and annotations trustworthy.
What should a beginner do first?
- Write down which MCP servers your team uses. If you cannot name them, start with find AI agents already running in your company.
- For each server, list the tools it offers and mark which ones only read and which ones change something.
- Turn off the tools that change things unless there is a clear need.
- Make sure approvals show the full inputs, not just the tool name.
- Turn on logging for tool calls and decide where the logs live.
- Test with a harmless server first, using the MCP Inspector.
Where does Safeguard fit?
Safeguard offers MCP Guardrail, which governs the traffic between agents and MCP servers, and agent identity, which records which agent holds what access at what level. Its asset discovery helps find the agents and MCP servers in use across a company. Together these give you the checkpoints from the table above in one place, with records. You can try the free scan at gold.safeguard.sh/scan.
Try it yourself
In the demo, follow how an MCP server is set up and connected. Watch for the moment the list of tools appears, because that is step one above.
Click through it at your own pace, or open it full screen.
Quick check
Does the model run the tool itself?
No. The model asks for a tool by name with some inputs. The host app and client carry out the request and return the result.
Can a server see my whole conversation?
The MCP design principles say servers should not be able to read the whole conversation or see into other servers. The host keeps the full history and decides what each server receives.
Is a confirmation prompt enough protection?
It helps, but it is only one checkpoint. People get tired of prompts, so pair them with narrow tools, limited access, and logs.
Sources
Last reviewed: 19 October 2026.
