How AI Models Learned to Use Tools: A Protocol History

A model that could only talk

A language model that can only emit text is, from the point of view of anything else in the world, mute in a specific sense: it can describe an action in prose, but nothing downstream of it is obliged to notice, let alone execute what it described. Between 2023 and 2025 that changed, and it changed through a specific, datable sequence of interface decisions — not through a single breakthrough in what models could reason about, but through a sequence of answers to a much narrower and more mechanical question: what, exactly, is the shape of a call a model is allowed to propose, and who checks it before anything happens?

That question is the subject of this article, and it is deliberately narrower than the history of agent architecture — the reasoning loops, planners and multi-agent topologies that decide when and why a model acts are a different, adjacent history, told elsewhere in this publication. This one stays on the wire: the calling convention itself, dated to the actual announcements, specifications and documentation that introduced each one, rather than to a general sense that models “got agentic.” Four such conventions appear in the documented record, and each is a real change in where the type-checking, the discovery mechanism and the execution boundary lived: a manifest file borrowed wholesale from an existing web-API format; a schema built directly into the model’s own request; a proliferation of incompatible, framework-specific wrappers around that schema; and a single, openly governed protocol built explicitly to replace the wrappers with one connection every side implements once.

The plugin era: borrowing someone else’s format

The first documented system letting a widely used conversational model reach outside itself was OpenAI’s ChatGPT plugins, launched in alpha on March 23, 2023. Plugins, as TechCrunch reported at the time, “extend the bot’s functionality by granting it access to third-party knowledge sources and databases, including the web,” with an initial roster of partner plugins from “Expedia, FiscalNote, Instacart, Kayak, Klarna, Milo, OpenTable, Shopify, Slack, Speak, Wolfram and Zapier” alongside OpenAI’s own hosted web-browsing and code-interpreter plugins ^[1].

The mechanism is the part of this history worth dwelling on, because it is a reuse decision rather than an invention. OpenAI’s own reference implementation for third-party plugin developers, published as the plugins-quickstart repository, ships a .well-known folder alongside an openapi.yaml file ^[2] — that is, a plugin was described using a manifest discovered at a fixed, well-known network path plus an OpenAPI document, the same format web developers had used for years to describe REST endpoints to tooling built for humans, rather than any format designed for a language model. ChatGPT read a plugin’s OpenAPI specification and the natural-language description fields written into it, and decided when to call one of the plugin’s endpoints based on that English text.

Two structural consequences follow, and they are consequences of the specific engineering choice rather than editorializing about it. First, discovery happened per-domain, through the fixed well-known path: a plugin had to already be a hosted REST API with a written OpenAPI description, not a local function a developer wanted to expose. Second, execution ran substantially through infrastructure OpenAI itself hosted — the code-interpreter plugin, for instance, provided “a working Python interpreter in a sandboxed, firewalled environment along with disk space” ^[1], run on OpenAI’s own servers rather than by code the calling application supplied and controlled the way every convention after it would require. OpenAI was, in this first system, the manifest reader, the router and frequently the executor all at once, with only a handful of plugins enabled per conversation and a waitlist gating who could try any of it.

Native function calling: the schema moves into the API

Less than three months later, the convention changed completely. On June 13, 2023, independent developer Simon Willison documented OpenAI’s announcement the same day it happened: developers could now “send JSON schema defining one or more functions to GPT 3.5 and GPT-4,” and “those models will then return a blob of JSON describing a function they want you to call” ^[3]. Willison also characterized the new capability structurally, describing it as effectively “an implementation of the ReAct pattern, with models that have been fine-tuned to execute it” ^[3] — a description of the reasoning behavior riding on top of the new interface, not of the interface itself, and this article leaves that reasoning-loop history to the companion piece that covers it in depth.

What changed in the calling convention is precise and worth stating plainly. There was no manifest file, no well-known network path, and no hosted execution layer. Current OpenAI documentation describes the resulting loop in five steps: “Send a request with available tools… Receive a tool call from the model… Execute the corresponding function… Return results to the model… Get the final response” ^[4], with each function described by a name, a description and a parameters field holding a JSON schema of the arguments ^[4]. The type system moved from a document hosted on a third party’s server and read by OpenAI’s infrastructure into the model request itself, and execution moved from OpenAI’s hosted plugin runtime to whichever application was making the API call. Every application became its own tool host, and every application’s own code became the place where a proposed call was checked before anything ran.

Other major model providers converged on the same underlying shape within roughly a year, each with its own dialect. Anthropic’s tool use, after a beta introduced alongside Claude 2.1 in November 2023, reached general availability across the Claude 3 model family on May 30, 2024, with Claude able to “select the appropriate tool to fulfill the task and, when appropriate, execute the corresponding action” ^[5]; Anthropic’s dialect names the model’s proposal a tool_use block and requires the caller to answer with a tool_result block, rather than using OpenAI’s function-call envelope. Google’s Gemini API added the equivalent capability in the same window — a December 22, 2023 account of the newly released feature described a model that, lacking information, “will request that you call an external function that you describe” ^[6], and current Google documentation confirms that the model “returns a function_call step with type, name, and arguments,” explicitly noting that the model “doesn’t execute the function itself” ^[7]. Three vendors arrived at one underlying idea — declare a typed function, let the model propose a call, execute it in the caller’s own code, return the result as data — through three incompatible field names and JSON envelopes for expressing exactly that idea, converging by imitation rather than by any shared specification.

Frameworks paper over the differences — and multiply them

LangChain predates all of this. Harrison Chase, its creator, wrote in an October 2025 retrospective that he pushed the first code “almost exactly 3 years ago,” placing the project’s start in the fall of 2022, and noted plainly that “a month later, ChatGPT launched, and everything for langchain changed” ^[8]. Its earliest tool abstraction, by the project’s own account, was deliberately primitive: “a model would generate two strings: 1. A tool name 2. An input string for the chosen tool,” with input “restricted to a single string” ^[9]. As the underlying models improved and, within the same window, native function calling arrived, LangChain replaced that single-string constraint with structured tools accepting “an arbitrary number of inputs of arbitrary types,” announced in May 2023 — essentially in step with OpenAI’s own change the following month ^[9].

The point worth naming precisely is that LangChain’s Tool class, Anthropic’s tool_use block and OpenAI’s function-call envelope are three separately evolving type systems, each attempting to describe the same underlying object — a named, typed, callable unit — in its own shape. A LangChain tool wraps whichever vendor’s function-calling schema happens to sit underneath it; a change to one is not automatically reflected in the other. Comparable tool and toolkit abstractions proliferated across the wider application-framework ecosystem in the same period, each independently reinventing a wrapper around whichever vendor schema it targeted, and each wrapper living in application code that then had to be rewritten per framework, per vendor and often per version.

The structural cost of this, stated without inventing a figure for it, is straightforward: every new tool or data source an agent should be able to reach had to be wired, separately, into every framework that wanted to expose it, and every framework had to be wired, separately, into every model vendor’s own function-calling dialect. This is exactly the shape of problem Anthropic would name eighteen months later as its own stated reason for building something new: “every new data source requires its own custom implementation, making truly connected systems difficult to scale” ^[10].

A standard for the connection itself

Anthropic introduced the Model Context Protocol on November 25, 2024, framing the problem in terms of isolation rather than incompatibility: “even the most sophisticated models are constrained by their isolation from data — trapped behind information silos and legacy systems” ^[10]. The protocol’s mechanics, read from its own specification rather than from marketing, are a JSON-RPC 2.0 message layer connecting three roles — hosts, clients and servers ^[11] — where JSON-RPC itself is described in its governing document as “a stateless, light-weight remote procedure call (RPC) protocol” designed, in the specification’s own words, “to be simple” ^[12]. The specification is explicit about where the design came from: “MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools” ^[11]. LSP’s own documentation states the problem it was built to solve in nearly identical terms to MCP’s: “Traditionally this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature,” solved because “a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort” ^[13].

That parallel is precise enough to formalize, and doing so exposes the actual economic assumption both protocols are making rather than merely asserting it. Let $M$ be the number of distinct hosts — editors, for LSP; agent frameworks and model-serving applications, for MCP — and $N$ be the number of distinct targets — languages, for LSP; tools and data sources, for MCP. Wiring every host to every target independently, the way plugins and early framework wrappers did, requires

separate integrations, because nothing built for one pair transfers to any other. A protocol that both sides implement exactly once instead collapses this to

The assumption a shared protocol is betting on is that the fixed cost of building and maintaining the standard itself is smaller than the integrations it removes, and that those removed integrations were genuinely redundant rather than differently necessary. When $M$ and $N$ are both large and still growing, the gap between $M \times N$ and $M + N$ dominates every other consideration; when either is small — a single application talking to a handful of tools it controls — a bespoke integration can still be cheaper than adopting a shared protocol at all, and treating standardization as free in that case would be cargo-culting rather than economizing.

MCP’s own specification lists tools, resources and prompts as the primitives a server may expose ^[11], and it is candid about the boundary of what the protocol itself can guarantee: “MCP itself cannot enforce these security principles at the protocol level” ^[11] — the specification’s own admission, not an outside critique of it.

Adoption: a standard only works if competitors use it

A protocol is worth little until parties with no obligation to use it, do. According to Wikipedia’s dated timeline, “In March 2025, OpenAI officially adopted the MCP, after having integrated the standard across its products, including the ChatGPT desktop app” ^[19], and OpenAI’s own Agents SDK documentation describes the protocol in its own words as “a standardized way to connect AI models to different data sources and tools,” letting developers “reuse existing MCP servers or build your own to expose filesystem, HTTP, or connector backed tools to an agent” ^[17]. This is the same company that had built a structurally different, hosted-manifest plugin system two years earlier and its own separately branded function-calling schema after that; adopting MCP meant OpenAI’s own agent tooling took up a wire format it had not designed.

A month later, on April 9, 2025, Google DeepMind’s chief executive was quoted by TechCrunch describing MCP directly: “MCP is a good protocol and it’s rapidly becoming an open standard for the AI agentic era” ^[20] — a vendor executive’s own characterization, and it should be read as exactly that, a claim rather than a settled fact. The follow-through was concrete regardless: by December 2025, Google Cloud had released “fully-managed, remote MCP servers” for BigQuery, Google Compute Engine, Google Kubernetes Engine and Google Maps, stating that its BigQuery server “enables agents to natively interpret schemas and execute queries against enterprise data without the security risks or latency of moving data into context windows” ^[18].

The clearest evidence that MCP had stopped being one company’s project came a year after its announcement. On December 9, 2025, Anthropic donated stewardship of the protocol to a newly formed, vendor-neutral Agentic AI Foundation under the Linux Foundation, describing the move as securing “vendor-neutral governance for the protocol’s future,” comparable to the stewardship models behind “Kubernetes, PyTorch, and Node.js” ^[16]. The foundation was “co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg” ^[16] — companies that compete directly on model quality agreeing to share governance of the wire format connecting their products to everyone else’s tools. Anthropic’s own account at the time of the donation reported “over 97 million monthly SDK downloads” and “10,000 active servers,” with “first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more” ^[16] — a vendor’s self-reported figure, not an independently audited one, and nothing in the sources gathered for this article confirms or disputes it from outside.

Governance formalized on a similar timeline. A process introduced on July 31, 2025 replaced ad hoc maintenance with Specification Enhancement Proposals, “inspired by projects like Python PEPs or Rust RFCs” and reviewed by a steering group of maintainers on a fixed, publicly noted cadence ^[14]. Heading into 2026, the protocol’s own roadmap describes MCP as running “in production at companies large and small” and states plainly that “production deployments have different needs than the early experiments that got us here,” naming transport scalability, a Tasks primitive gaining “retry semantics and expiry policies,” a governance contributor ladder, and enterprise readiness — audit trails and single sign-on — as the year’s priorities ^[15]. That “retry semantics” still appears on a 2026 priority list, rather than in the base specification, is itself a fact worth sitting with: it means the protocol’s own maintainers regard reliable retry behavior as unfinished, not solved.

What actually changed, and what is still a claim

Four changes across this history are documented fact rather than framing. Discovery moved from a fixed well-known path on a third party’s server to declarations sent inside the model’s own request. Execution moved from infrastructure the model provider hosted to code the calling application supplied and controlled. The type system moved from an externally authored OpenAPI document into a purpose-built JSON schema, then fractured across incompatible per-vendor and per-framework dialects before a single specification set out to reunify it. And governance moved from one company’s product roadmap to a multi-vendor foundation with a public specification-change process.

What is not a documented fact, and should be read as a claim rather than settled history, is that MCP’s particular technical design is the correct one, that its self-reported adoption numbers are complete or independently verified, or that its security posture — which the specification itself says it “cannot enforce… at the protocol level” ^[11] — is adequate for the highest-stakes systems now being connected through it. Vendors who compete directly on model quality have agreed to share a wire format; they have not thereby vouched for each other’s servers, and the specification’s own text makes no such claim on their behalf.

What follows is analysis, offered as analysis rather than as sourced fact: each of the four stages in this history changed exactly one axis — where discovery happens, where execution happens, how many incompatible shapes exist, who governs the shape — while the underlying object stayed essentially constant since June 2023: a named, typed call with a description a model reads and a result a caller checks. That continuity is easy to miss because each stage arrived under new vocabulary — plugins, functions, tools, servers — but read as calling conventions rather than as products, three of the four stages are minor variations on the same idea, and only the fourth, moving governance itself outside any single vendor, changed something other than the wire format.

Predictions, and what would falsify them

These are forecasts, kept separate from the sourced history above. Horizon: August 2028.

One. MCP’s retry and idempotency semantics — currently a named but unfinished 2026 roadmap priority ^[15] rather than a normative requirement in the base specification — will move into the base specification as required behavior, because production deployments the same roadmap describes already expose the gap between advisory guidance and what operators actually need. Disconfirmed if, by the horizon, the relevant retry and deduplication behavior remains confined to an optional extension with no required caller-supplied identity mechanism in the core specification.

Two. The number of independently designed, mutually incompatible tool-calling schemas in wide production use will keep shrinking, not because of any new technical result but because switching costs increasingly favor the specification with foundation-level, multi-vendor governance over any single company’s dialect. The assumption behind this forecast is that the $M \times N$ integration cost named above continues to bind as more hosts and more tools are built, making a shared protocol progressively cheaper relative to bespoke wrappers even for teams with no particular loyalty to any one vendor. Disconfirmed if, by the horizon, a majority of newly launched agent frameworks still ship a bespoke tool-definition format with no MCP interoperability layer at all.

What to take away

The ability of an AI model to use a tool was never a single invention. It was assembled across four dated, documented changes to a calling convention: a manifest that borrowed a web-API description format wholesale and ran execution through the model provider’s own servers; a typed schema moved directly into the model’s request, handing execution to whichever application made the call; a wave of framework-level wrappers that made building an agent easier while multiplying the number of incompatible shapes a tool definition could take; and a JSON-RPC-based protocol, explicitly modeled on a decade-old solution to the identical integration-count problem in code editors, now governed by a foundation that includes the vendors who once competed on incompatibility.

None of that history required a new capability inside the models themselves. Every stage is a decision about where discovery lives, where execution happens, how many shapes a call may take, and who gets to change the answer to those questions later — decisions made in blog posts, specifications and governance documents, not in a training run. Reading a new tool-use announcement against that structure, rather than against the vocabulary it ships with, is the only way to tell whether it is a real change to the wire or a new name for a convention that has not moved since June 2023.