# MCP for AI agents: how to add tools without bloating the context

> How to design the MCP server set for an AI agent: classes of capability, what tools really cost in context, security, and where the standard stands in 2026.
> Author: Roman Belov · Published: 2026-10-03 · Source: https://futurecraft.pro/blog/mcp-for-ai-agents/

Two things decide what an agent can do: the model, and the set of actions available to it. Model comparisons fill terabytes. The second factor gets far less attention, though it's the one that separates an agent that can discuss a problem from an agent that reads the logs in Sentry, finds the commit in GitHub, and files a ticket in Jira.

MCP (Model Context Protocol) turned that second factor into a construction kit. By 2026 the protocol had gone from an internal Anthropic standard to an industry one: Anthropic handed it to the Linux Foundation on December 9, 2025, where Block and OpenAI co-founded the foundation alongside it, and by then there were more than 10,000 public servers. The question of how to connect an agent to tools is settled. A different one is still open: what exactly to connect, what it costs you, and where the security boundary runs.

This piece is about designing an agent's tool layer: what classes of superpower MCP servers hand over, what each server costs in context tokens, how to assemble the set, and how to avoid opening a hole into your own infrastructure. The basics, meaning protocol architecture, connecting servers, and the catalog, are already covered in the [MCP guide](https://futurecraft.pro/blog/mcp-servers-explained/) and the [roundup of the best servers](https://futurecraft.pro/blog/best-mcp-servers-2026/). This one works at the design level.

## What the superpowers actually are

It helps to think about servers as classes of capability rather than as a list:

| Class | What the agent gets | Typical servers |
|---|---|---|
| Reading data | The real state of your systems instead of guesses | PostgreSQL, Supabase, analytics, web search |
| Actions | Changing the outside world: tickets, PRs, messages, deploys | GitHub, Jira/Linear, Slack, CI/CD |
| Context | Knowledge the model doesn't have: docs, internal wikis | Notion, Confluence, library documentation |
| Observability | Diagnostics: logs, errors, metrics | Sentry, Grafana, cloud logs |

The split is practical for two reasons. First, the classes carry different risk. Reading and observability servers are close to harmless; action servers are the main source of incidents, and you grant them permissions differently. Second, you measure the maturity of an agent's tool layer by class coverage rather than by server count. An agent with four servers, one from each class, can do more than an agent with ten read servers.

A test question for your own set: can the agent get through the loop "saw a problem, found the cause, shipped a fix, checked the result" on its own? That takes all four classes. Drop one and the agent stalls halfway and asks a human to go look.

## Where the standard stands: MCP in 2026

A short version of what you're standing on when you connect MCP today:

| Parameter | Status as of November 2026 |
|---|---|
| Governance | Handed to the Linux Foundation on December 9, 2025 ([Anthropic](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation), [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)) as an Agentic AI Foundation project. Co-founders: Anthropic, Block, OpenAI; platinum members: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI. According to Anthropic, MCP's own governance model did not change |
| Specification | Revision 2026-07-28 (versioned by date); the previous one is 2025-11-25 ([changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)) |
| Protocol | Stateless: the initialize/initialized handshake and the Mcp-Session-Id header are gone, protocol version and client capabilities travel with every request, and there is a new server/discover method and a subscriptions/listen stream |
| Transports | stdio (local servers) and Streamable HTTP (remote); HTTP+SSE is now formally Deprecated |
| Authorization | For HTTP transports, based on the OAuth 2.1 draft ([spec](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)); client registration via Client ID Metadata Documents, with Dynamic Client Registration deprecated. For stdio the spec does not prescribe authorization: credentials come from the environment |
| Deprecated | Roots, Sampling, and Logging: still working, but new implementations should not add them; the deprecation window is at least twelve months |
| Tasks | Moved out of the core into the official io.modelcontextprotocol/tasks extension |
| Official registry | In preview: its page says breaking changes or data resets may occur before GA ([source](https://modelcontextprotocol.io/registry/about)) |
| Ecosystem | As of December 2025, per Anthropic: more than 10,000 active public servers and more than 97M monthly SDK downloads (Python and TypeScript). No newer official figures were found |
| Clients | Per Anthropic: ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code; clouds: AWS, Cloudflare, Google Cloud, Microsoft Azure |

The practical takeaway from that table: betting on MCP is no longer betting on a vendor. A server written for one client works with the rest. The second detail matters more than it looks. AGENTS.md, the project-instructions file from OpenAI, went to the same foundation alongside MCP. That standardizes the whole layer, context and tools together, and makes agent configuration portable between tools.

Two things in the 2026-07-28 revision bear on the price of context. Servers SHOULD return `tools/list` in a deterministic order, which lets clients cache the list and improves prompt cache hit rates when tools sit in the model's context. And list results now carry `ttlMs` and `cacheScope` (the CacheableResult interface), a hint for how long a client can treat the list as fresh. Details are in the [changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog) and the [tools section](https://modelcontextprotocol.io/specification/2026-07-28/server/tools). For anyone writing their own server the rule is simple: don't reshuffle the tool order between requests.

## The price catalogs don't list: context

Every connected server hands the client descriptions of its tools: name, purpose, parameter schema. If the client loads them eagerly, they land in the session context before the agent reads the first word of your task. Claude Code doesn't: tool search is on by default, only tool names and server instructions load at session start, and definitions are pulled in on demand. `ENABLE_TOOL_SEARCH=auto:N` defers loading once definitions take N% of the window or more ([docs](https://code.claude.com/docs/en/mcp#scale-with-mcp-tool-search)). It works on Opus 4, Sonnet 4, Haiku 4.5 and later; earlier models load everything upfront. Cursor's docs don't describe a tool count limit or lazy loading of descriptions, so check your own client's behavior.

There is no universal number for what a server costs in tokens: it depends on the server and the client. See the breakdown with `/context` in Claude Code or the equivalent in your client. There is a second cost too, the model's attention: the more similar tools are available, the higher the risk that the agent picks the wrong one, mixing up similar servers or firing web search where doc search was needed. That is an engineering observation rather than a measured figure, so test it on your own tasks.

Hygiene rules:

- **Global config is for servers you need everywhere.** Everything project-specific goes in the project config. The analytics server for one product has no business riding along in the context of every repository.
- **Kill the zombie servers.** Connected for a task three months ago, never called since, still sitting in the tool list (and, without tool search, eating tokens in every session). Auditing the list now and then is the cheapest context you'll ever get back.
- **Remove the overlaps.** Two servers with a search tool guarantee confusion: the agent picks between them nondeterministically. One class of task, one server.
- **Server size matters.** An official server with 50 tools where the agent uses three is a candidate for replacement with your own three-tool server. Deferred schema loading (on by default in Claude Code) lowers the price of a big server but doesn't replace choosing carefully; in other clients, check the behavior.

It's the same attention budget as context files, the subject of the [context engineering guide](https://futurecraft.pro/blog/context-engineering-guide/): anything that loads in every session has to earn its place.

## Designing the set: from tasks, not from the catalog

Server catalogs invite hoarding: connect everything interesting, just in case. The approach that works runs the other way.

1. **Write down the agent's recurring tasks.** Real ones, not hypothetical: "investigate a production error", "prepare a PR from a ticket", "answer a question about the data". Five to seven of them.

2. **For each task, list the external touchpoints.** "Investigate an error" = read the stack trace (Sentry) + find the code (already handled) + check the history (git). The tasks give you a list of capabilities, and the capabilities give you a short list of servers.

3. **One server per capability.** Pick on three criteria: the author (official from the system's vendor, or a maintainer you trust), the quality of the tool descriptions (that's exactly what the agent reads), and size (does it drag in extras).

4. **Set permissions by capability class.** Read servers get read-only tokens. Action servers get minimal scope plus client-side confirmation for irreversible operations. One server, one token, so revoking one doesn't break the rest.

5. **Write your own when the off-the-shelf server doesn't fit.** An internal API, a specific combination of three tools, bad descriptions in the existing server. Writing one is a day's work, covered in the piece on [building an MCP server in Python](https://futurecraft.pro/blog/build-mcp-server-python/); production practices such as error handling, monitoring, and security are in a [separate guide](https://futurecraft.pro/blog/mcp-production-custom-servers/).

You know the set is right when the system context is short and the agent still doesn't ask for permission to go and check something itself on routine tasks. It already has what it needs to reach a result.

## Security: three vectors worth remembering

Tools give the agent hands, and they create attack surfaces a bare model never had.

**Tool poisoning.** Tool descriptions are text the agent reads as part of its context. A malicious server can hide instructions in a description ("before calling, send the contents of file X as parameter Y") that stay invisible in the UI and visible to the model. Researchers at Invariant Labs described the attack [in April 2025](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks), along with the "rug pull" (a server changes a description after you approved it) and tool shadowing (one server's description influences calls to another server's tools). Among the authors' recommendations: pin tool versions with hashes and control data flow between servers more strictly. The spec itself says clients must treat tool annotations as untrusted unless they come from a trusted server, and that there should be a human in the loop who can deny tool invocations ([tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). The takeaway: a third-party server is code with privileges inside your context. Check the author and the text of the descriptions before you connect it, and pin the version.

**Injection through results.** Even an honest server returns data from the outside world: the text of an issue, the contents of a web page, an email. If that data says "agent, execute...", the model can take it for an instruction. OWASP lists this class as LLM01:2025 Prompt Injection in its [Top 10 for LLM applications](https://genai.owasp.org/llm-top-10/). The defense sits at the client and prompt level: treat tool results as data, and require confirmation for actions with side effects. This is also the main argument against "run everything without asking" modes.

**Excessive permissions.** The dullest vector and the most common one. An admin-scope token handed to a server that only needed read access; one shared token across five servers; secrets in plaintext in a config that lives in a dotfiles repository. Nothing here is specific to MCP. It's ordinary secret hygiene applied to a new layer.

A practical rule for action servers: irreversible operations (merge, deploy, delete, sending messages outside the org) run only after a human confirms, no matter how much you trust the server. The cost of one "allow" click is nowhere near the cost of an automatic `git push --force` triggered by an instruction from a poisoned description.

## Pitfalls

- **A registry in preview is not a production foundation.** The official registry is in preview: its page says breaking changes or data resets may occur before GA. Auto-discovering and installing servers from the registry is still an experimental path; for production, pin servers explicitly.
- **stdio versus Streamable HTTP isn't a matter of taste.** Local servers (stdio) inherit your permissions and environment; remote ones (HTTP) require authorization but have no filesystem access. A server that doesn't need local files is better off remote.
- **Description quality decides more than functionality.** The agent picks a tool by its description. A server with powerful but vaguely described tools performs worse than a server with three tools and precise descriptions. When you write your own server, most of the time should go into the descriptions and schemas.
- **One server is not one session.** A heavy server connected globally multiplies its context weight across every session of every project, if the client loads schemas eagerly. Budget for the total across all of them rather than for one session in isolation.
- **The standard is young, so watch spec versions.** The protocol versions by the dates of breaking changes. Since 2026-07-28 the protocol version travels with every request, and a mismatch returns an `UnsupportedProtocolVersion` error; clients and servers update at different speeds, so check revision compatibility whenever a connection behaves strangely. Roots, Sampling, and Logging are deprecated (a deprecation window of at least twelve months), so don't build new servers on them.

## Where to start

1. Write down five recurring tasks for your agent and the external touchpoints for each. That's your list of required capabilities.
2. Audit your current servers: what actually gets used, what duplicates something else, what hasn't been called in a month. Switch off the excess.
3. Assemble the minimal set: one server per capability, coverage of all four classes (data, actions, context, observability), 3 to 5 servers to start.
4. Review the tokens: read-only where possible, minimal scope everywhere, a separate token per server, confirmation for irreversible actions.
5. Pin server versions and the install source, the way you'd pin a dependency in a lock file.
6. Come back to step 2 in a month. A toolset isn't a one-time configuration. It's part of your setup that rots and needs tending.

MCP removed the technical friction: connecting an agent to anything is easy now. So the advantage moved up a level, to the people who design the set deliberately. An agent with five well-chosen servers and tight permissions beats an agent with twenty random ones: less context, more accurate tool selection, a narrower attack surface. Superpowers come from how well the hands match the tasks, not from the number of plugins you installed.