Chapter 2 of 14 · Understand · 5 min read
How agents use tools, MCP and the context window
A language model on its own is a very well-read brain in a sealed room. Tools are the doors. This chapter looks at how a model actually uses a tool, what the Model Context Protocol (MCP) adds, and why the context window, the model’s working memory, is the resource that shapes almost every design decision in agents and skills.
Anatomy of a tool call
Every tool an agent can use is described to the model in three parts: a name, a plain-language description of what it does, and a schema listing the inputs it accepts. The model reads these descriptions alongside your request, and when it decides a tool would help, it writes a structured request instead of ordinary text.
A tool definition, as the model sees it (simplified)
name: get_weather
description: Get the current weather for a city. Use when the user asks about weather conditions.
input:
city: string, required. The city name, e.g. "Lisbon".
units: "metric" or "imperial", optional.If you ask “Do I need an umbrella in Lisbon?”, the model might reply with a request like get_weather(city: "Lisbon"). The agent program runs the real function, gets back something like “light rain, 17°C”, and adds that result to the conversation. The model then reads it and answers you. The model never touched the weather service. It only asked.
- The model reads the request and the list of available tools.
- It chooses a tool and fills in the inputs.
- The agent program checks permissions, runs the tool and captures the output.
- The output goes back into the context as a tool result.
- The model decides whether to call another tool or give its answer.
Tool descriptions work exactly like skill descriptions, which you’ll meet in the next chapter: the model picks a tool by reading what it says it does. Vague descriptions lead to tools being ignored or misused.
Common kinds of tools
| Kind | Examples | Why it matters |
|---|---|---|
| Read | Read a file, list a folder, fetch a web page, query a database | Lets the agent ground its work in real data instead of memory |
| Write | Edit a file, create a ticket, update a record | Lets the agent change things, so it needs more care |
| Execute | Run a shell command, run tests, execute code in a sandbox | Very powerful, and the main reason agents need permission prompts |
| Communicate | Send an email, post a message, open a pull request | Actions other people see; often worth a human approval step |
What MCP adds
Every agent needs tools, and every company has systems agents might want to reach: issue trackers, design files, databases, calendars. Before a common standard, each agent had to build its own integration with each system. The Model Context Protocol is an open protocol that fixes this. A service exposes its tools through an MCP server once, and any agent that speaks MCP (an MCP client) can use them.
- An MCP server is a small program that offers tools, and sometimes resources and prompt templates, over the protocol. It can run on your machine or be hosted remotely.
- An MCP client is built into the agent or app. When you connect a server, its tools appear in the agent’s tool list.
- The agent still decides when to call those tools, and the client still decides whether to allow each call.
A useful way to think about it: MCP is how an agent gets new abilities and access, like plugging in a new device. It doesn’t tell the agent how to do a job well. That’s what skills are for, and Chapter 4 compares the two side by side.
An MCP server runs with whatever access you give it. A server connected to your email or production database can read and change real things. Install servers only from sources you trust, prefer read-only access where it’s enough, and keep approval prompts on for write actions.
Build MCP Server GuideAgent skillA skill that guides an agent through building an MCP server.Agent skill · Apache-2.0
Awesome MCP ServersOpen sourceA community list of MCP servers to explore.★ 97.2k · MIT
GitHub MCP ServerOpen sourceGitHub’s official MCP server for repos, issues and pull requests.★ 34.2k · MITThe context window: the agent’s working memory
The context window is the total amount of text a model can consider in one request, measured in tokens (chunks of a few characters each). Everything competes for that space: the system prompt, tool definitions, your messages, every tool result and every loaded skill. On a long task the window fills up fast, because tool outputs such as file contents, logs and web pages can be large.
Why a full context hurts
- Cost and speed: each step resends the whole context, so a bloated context makes every step slower and more expensive.
- Attention: models handle focused context better than sprawling context. Important instructions can get lost among irrelevant tool output.
- Hard limits: when the window is full, something has to go. Agents may summarise or drop older material, and details can be lost.
How good agents protect it
- They read parts of large files instead of whole files, and search before they read.
- They load instructions only when relevant, which is exactly how skills work.
- They hand self-contained subtasks to subagents with their own fresh context and take back only a summary.
- They compact or summarise old conversation when it is no longer needed in full.
Tools also take up room. Every connected MCP server adds its tool definitions to the context, whether or not you use them in a given session. Connecting dozens of servers “just in case” can quietly eat into the space available for the actual work. Connect what you need for the job at hand.
If an agent starts forgetting earlier instructions or repeating itself on a long task, the context is probably crowded. Start a fresh session with a short summary of where things stand. It often works better than pushing on.
Putting it together
Tools let an agent act. MCP is a shared way to plug in tools from other systems. The context window is the limited desk where all of it has to fit. Skills, which we turn to next, are designed around that last constraint: they let you give an agent a large library of know-how while keeping almost none of it on the desk until it’s needed.
Key takeaways
- A tool has a name, a description and an input schema; the model requests calls and the program runs them.
- MCP is an open protocol that lets any compatible agent use tools from any compatible server.
- The context window holds everything the model sees, and tool definitions and outputs consume it.
- Good agents and good skills are designed to keep the context small and focused.
Put it into practice
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Written by the AI Tool Garage editors. Tool details link to their catalogue pages, which are refreshed weekly; spotted something out of date? Tell us.