AI AGENTS AND MULTI-AGENT SYSTEMS / INTERMEDIATE

Tools, Memory And The Model Context Protocol

How AI agents call tools, how they remember what they have learnt, and how the Model Context Protocol gives them a standard way to reach data and services.

Checked against primary sources and independently reviewed on . Sources are listed at the end.

An agent is only as useful as what it can reach. A language model that cannot look anything up or change anything outside the conversation can give advice, but it cannot finish a task that depends on current records or on changing something in another system. Tools give an agent hands, memory gives it continuity, and shared protocols decide how much custom wiring every new connection needs.

This article explains how a model calls a tool, the main kinds of agent memory, and how the Model Context Protocol (MCP) works, including its current version and who governs it as of October 2026. It assumes you have read What Is An AI Agent? or already know the basic agent loop.

How A Model Calls A Tool

Tool use, often called function calling, follows a fixed exchange. The developer describes each tool to the model: a name, a plain description of what it does, and a schema listing the inputs it accepts. For tools the developer defines, the model never runs the tool when it decides one would help. It replies with a structured request that names the tool and fills in the inputs, and the application carries out that request and sends the result back. Some providers also host a few built-in tools, such as web search, and run those on their own side, so the checks available there are the ones the provider supplies.1

  1. Describe The Tools

    The application tells the model which tools exist, what each does and what inputs it takes.

  2. Model Requests A Call

    The model returns the tool name and its inputs in a structured format instead of a normal reply.

  3. Application Runs It

    Code outside the model checks the request and executes it, for example querying a database.

  4. Result Goes Back

    The output is added to the conversation so the model can use it in its next step.

One round of tool use for a tool the developer defines. The model proposes the call; the application decides whether to run it.

That split between proposing and executing is useful. The application can refuse a request, ask a person to approve it, or record it before anything happens. It also means the written description of each tool carries real weight, because the model chooses tools largely from what those descriptions say. How many tools an agent has is only part of the story. In OpenAI’s experience, an agent given a large, well-separated toolset can cope, while one given a small set whose jobs blur together can keep choosing wrongly; the guide puts rough numbers on this, citing success with over 15 tools in some systems and trouble with under 10 in others.2

Memory: What An Agent Keeps Between Steps

Agents work with two broad kinds of memory. Short-term memory is the context window, the running record of instructions, messages, tool requests and results that the model sees on each turn. It is limited in size, so long tasks need a way to summarise or drop older material. Long-term memory lives outside the model, in files, databases or search indexes, and is fetched back when it becomes relevant. Some model providers now offer a memory tool for exactly this, which saves notes to files the developer controls so they can be read again in a later conversation.1

Research systems show how far this can go. The 2023 “Generative Agents” study by Joon Sung Park and colleagues gave each simulated character a running diary of everything it observed. From time to time the character drew broader conclusions from those entries, and when deciding what to do next it pulled out whichever entries and conclusions best fitted the moment.3

The practical lesson for builders is that memory shapes behaviour. An agent that retrieves an out-of-date policy or a wrong earlier conclusion may act on it as though it were correct. Decide what an agent may store, how long it keeps it, and how stored items are checked before they are reused.

What The Model Context Protocol Solves

Before shared standards, every pairing of an AI application with a data source needed its own connector. Anthropic released MCP as an open-source standard on 25 November 2024. The aim was a single, shared way for AI applications to reach the outside data and tools they rely on, with services acting as servers and AI applications acting as clients.4 A service exposes itself once as an MCP server, and any application that speaks MCP can use it.

The specification describes three roles.5 The host is the AI application a person works in. It creates one client for each connection, and each client talks to exactly one server. Servers offer specific capabilities and can run on the same machine or as remote services. The design principles say a server should receive only the context it needs, should not be able to read the whole conversation, and should not see into other servers. Enforcing those boundaries is the host’s job, so an application that hands a server too much is not protected simply because it uses MCP.

Host ApplicationModeland conversationClient 1Client 2Client 3MCPMCPMCPServer: FilesServer: DatabaseServer: Web ServiceLocal FilesRecordsOther System
MCP architecture. The host holds the model and the conversation, and creates one client per server. Each server sits in front of a data source or service.

Servers offer three kinds of capability, each controlled by a different party.6 The split matters because it decides who can trigger what.

PrimitiveWhat it offersWho decides when it is usedExample
ToolsFunctions that let the model take an action or fetch informationThe modelSending a request to a web service, writing a file
ResourcesData or content that gives the model contextThe host applicationFile contents, version history
PromptsPrepared templates that shape an interactionThe userA slash command or a menu option
The three MCP server primitives in the 2026-07-28 specification.

Versions, Governance And What Comes Next

MCP versions are dates in the form YYYY-MM-DD, marking the last time a change broke backwards compatibility. As of October 2026 the current version is 2026-07-28. In this revision every request states which protocol version it uses, and the server checks each request separately; if it does not support that version, it replies with an error listing the versions it does support. Older revisions, up to and including 2025-11-25, agreed a version once in a start-up handshake, and the specification keeps a compatibility path for them. A feature marked as deprecated stays in the specification for at least twelve months, or ninety days under an expedited exception, before it can be removed.7

Governance moved to a neutral home in late 2025. On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation, with MCP contributed by Anthropic, the goose project by Block, and the AGENTS.md convention by OpenAI as its founding projects. The foundation reported at that point that more than 10,000 MCP servers had been published, a figure it supplied itself rather than one measured independently.8

The project also publishes a roadmap, last updated on 22 August 2026. Its priority areas include messaging for long-running work, a single HTTP-based transport model, agent identity and enterprise security, clearer tool results and better developer kits. The maintainers state that it reflects current thinking and is not a set of commitments, so treat it as direction rather than a delivery plan.9

Connecting an agent to real systems also widens what can go wrong, from over-broad permissions to instructions hidden in retrieved content. Those risks are covered in Agentic AI Security.

Footnotes

  1. Anthropic, “Tool use with Claude” (developer documentation), accessed 7 October 2026. platform.claude.com ↩ ↩2

  2. OpenAI, “A practical guide to building agents”, April 2025. cdn.openai.com ↩

  3. J. S. Park, J. C. O’Brien, C. J. Cai, M. R. Morris, P. Liang and M. S. Bernstein, “Generative Agents: Interactive Simulacra of Human Behavior”, arXiv:2304.03442, April 2023. arxiv.org ↩

  4. Anthropic, “Introducing the Model Context Protocol”, 25 November 2024. anthropic.com ↩

  5. Model Context Protocol, “Architecture”, specification version 2026-07-28, accessed 7 October 2026. modelcontextprotocol.io ↩

  6. Model Context Protocol, “Server Features: Overview”, specification version 2026-07-28, accessed 7 October 2026. modelcontextprotocol.io ↩

  7. Model Context Protocol, “Versioning”, accessed 7 October 2026. modelcontextprotocol.io ↩

  8. Linux Foundation, “Linux Foundation Announces the Formation of the Agentic AI Foundation”, 9 December 2025. linuxfoundation.org ↩

  9. Model Context Protocol, “Roadmap”, last updated 22 August 2026. modelcontextprotocol.io ↩

Knowledge Hub content is general information. It is not legal advice, a compliance certification, a guarantee of security or a substitute for an assessment of your own systems. Standards and rules change; check the sources for the latest position.