Forty years of calling someone else's code

Imagine a function call within a single program. You call refund(order); it runs and returns. If it fails, you know immediately. Now, move refund to a different machine. The function call must transform into a message, travel across a network, execute on the remote machine, and return as another message.

Bruce Jay Nelson is widely recognized for coining the term “remote procedure call” in 1981¹. He and Andrew Birrell at Xerox PARC developed “Lupine”, which “automatically generated stubs, providing type-safe bindings”¹. A stub is a small, generated code segment. To the caller, it appears to be the local function. In reality, it packages arguments into a message and transmits it. Birrell and Nelson intended RPC to “remove unnecessary difficulties, leaving only the fundamental difficulties of building distributed systems: timing, independent failure of components, and the coexistence of independent execution environments”².

Their 1984 paper openly discusses what the stub cannot conceal. If the call returns, the procedure executed exactly once. “Otherwise, an exception is reported to the user and the procedure will have been invoked either once or not at all—the user is not told which”². Worse: “If an exception is reported, the user does not know whether the server has crashed or whether there is a problem in the communication network”².

Sun’s RPC, documented as RFC 1057 in 1988, offered servers a partial defense. Each message includes a transaction ID, and a server “may choose to remember this ID after executing a call and not execute calls with the same ID in order to achieve some degree of execute-at-most-once semantics”³. Even over TCP, if the caller “receives no reply message, it cannot assume the remote procedure was not executed”³.

This means the caller bears the burden. For some procedures, this is simpler: “Idempotent procedures (those that have no additional effects if called more than once) are easily handled”¹. Reading an account balance twice does not change it. Sending a refund twice does. This distinction—between calls you can safely repeat and those you cannot—will be important throughout our course and for an agent’s tool list.

Birrell and Nelson’s callers were programmers working in the same lab. A new problem arose with strangers: how can a program from one company call a service from another? You need a shared way to describe the service and a way to find it.

CORBA 1.0, released in October 1991, included an “Interface Definition Language (IDL)” and an “Interface Repository”⁶. An IDL is a neutral language. You use it to write down what a remote object offers, including its operations and argument types. An interface repository lets a program ask, at run time, what interfaces are available. A standard “out of the box” interoperability architecture became available only with CORBA 2.0, in August 1996⁶.

The web then shifted remote calls to HTTP. The XML-RPC specification of 1999 states it clearly: “An XML-RPC message is an HTTP-POST request”⁷. SOAP 1.1, a W3C Note from May 2000, added an envelope and “a convention for representing remote procedure calls and responses”⁸. WSDL 1.1, from 2001, described a service using XML “as a set of endpoints operating on messages”⁹.

The final component was discovery: a public directory where any company could publish its services and any other could find them. This was the UDDI Business Registry. Microsoft, IBM, and SAP shut it down. Publication was “disabled as of January 12, 2006”⁵. By Microsoft’s own count, it had managed “over 50,000 replicated entries” over five years⁵. An analyst at ZapThink explained why the vision failed: “there’s always a human element to establishing a relationship”⁵. The format for describing services survived. Automated trust between strangers did not.

Meanwhile, in 2000, Roy Fielding’s dissertation described REST. Its stateless constraint means “each request from client to server must contain all of the information necessary to understand the request” and “Session state is therefore kept entirely on the client”¹⁰. Hold on to that sentence; MCP arrives at the same place in 2026. REST’s constraints say how to talk to a service, not how to describe one; OpenAPI later gave HTTP APIs a standard description. Version 3.0.0, published in July 2017, “allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic”⁴. In 2015 Google open-sourced gRPC¹¹ and Facebook began open-sourcing GraphQL, whose servers “can be queried for the types it supports”¹².

Until recently, every caller was a program. A programmer would read the IDL or OpenAPI document, write code based on it, and that code would send the exact call it was designed to send. In 2022, the caller began to change.

ReAct, posted in October 2022, prompted language models to produce “reasoning traces and task-specific actions in an interleaved manner” and showed the approach “interacting with a simple Wikipedia API”¹⁴. The action was text in the model’s output, and the surrounding program had to find and run it. Toolformer, in February 2023, trained a model “to decide which APIs to call, when to call them, what arguments to pass, and how to best incorporate the results”¹⁵. At inference, decoding pauses when the model produces a special token, the program calls the API, and decoding continues with the response inserted¹⁵. Gorilla, in May 2023, named the new failure: a hallucinated call is “an API call that is not a sub-tree of any API in the database – invoking an entirely imagined tool”¹⁶. All three are research systems built on 2022–2023 models.

Frameworks and APIs then gave the call a structure. LangChain’s history shows that “In the early days, tool use was simplistic”: a model generated a tool name and one input string¹⁷. On May 2, 2023 LangChain introduced structured tools that “can take in an arbitrary number of inputs of arbitrary types”¹⁷. OpenAI’s ChatGPT plugins, launched March 23, 2023, asked developers to describe their API with an OpenAPI specification and a manifest¹⁸. Its red team had already “discovered ways for plugins—if released without safeguards—to perform sophisticated prompt injection, send fraudulent and spam emails, bypass safety restrictions, or misuse information sent to the plugin”¹⁸.

On June 13, 2023 OpenAI moved this structure into the API itself. Developers describe functions “via JSON Schema”, and the model can “choose to output a JSON object containing arguments to call those functions”¹³. The same post warned that “untrusted data from a tool’s output can instruct the model to perform unintended actions”¹³. Google’s Gemini API listed function calling among its launch features on December 13, 2023¹⁹. In November 2023, OpenAI released the Assistants API with hosted tools such as Code Interpreter, and function calling gained “the ability to call multiple functions in a single message”²⁰.

The caller has changed. A traditional program sends exactly what its author wrote. A model, however, reads a plain-language description and makes a guess. It might choose the wrong tool, invent a tool that does not exist, or follow an instruction hidden in text that a tool returned. The description is no longer just documentation a programmer consults once. It is the input the caller acts on every time.

Before MCP, each agent application wrote its own connectors. Anthropic’s announcement on November 25, 2024 named the problem: “Every new data source requires its own custom implementation, making truly connected systems difficult to scale”²². Their solution was the Model Context Protocol (MCP), designed to replace “fragmented integrations with a single protocol”²².

The design has three roles. The first specification, dated 2024-11-05, defines hosts as “LLM applications that initiate connections”, clients as “Connectors within the host application”, and servers as “Services that provide context and capabilities”²¹. The current architecture page explains the mechanics clearly: “The MCP host accomplishes this by creating one MCP client for each MCP server”²³. All messages “MUST follow the JSON-RPC 2.0 specification”²⁴, a “stateless, light-weight remote procedure call (RPC) protocol” that is “transport agnostic”²⁵. The first version specified two transports: “stdio, communication over standard in and standard out” and “HTTP with Server-Sent Events (SSE)”²⁶.

The first specification also stated what MCP would not do. “While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD” build “robust consent and authorization flows into their applications”²¹. MCP standardizes how you describe and call a tool. The host still decides whether a call should run.

Within six months the large vendors adopted it: OpenAI’s Agents SDK on March 26, 2025²⁷, Google’s Agent Development Kit at its April 9, 2025 launch²⁸, Microsoft at Build on May 19, 2025, where it also joined “the MCP Steering Committee”²⁹, and OpenAI’s Responses API on May 20, 2025³⁰.

MCP published five versions between November 2024 and July 2026: 2024-11-05²⁶, 2025-03-26³¹, 2025-06-18³³, 2025-11-25³⁴ and 2026-07-28³². Lay them side by side and two kinds of parts appear.

Some parts kept moving. The transport changed in the second version, which “Replaced the previous HTTP+SSE transport with a more flexible Streamable HTTP transport”³¹. The same version added JSON-RPC batching³¹; the next version removed it³³. Authorization went from absent (“Authentication and authorization are not currently part of the core MCP specification”²⁴) to OAuth 2.1^31,35, then to servers acting as OAuth resource servers that accept only tokens meant for them^33,36, then to a new client registration mechanism^34,37, with the old one deprecated in 2026^32,38.

The 2026 version made the biggest break. It removed “the initialize/notifications/initialized handshake” and “protocol-level sessions”³². The maintainers explained their reasoning: “Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage”³⁹. They stated that a server needing state across calls should “mint an explicit handle from a tool and have the model pass it back as an argument”³⁹. Fielding argued for statelessness in 2000¹⁰; MCP arrived at the same design in 2026. We observe this parallel; the maintainers do not claim it.

Other parts stayed. Tools were a server feature in the first version²⁴. In the 2026 version servers still return them from tools/list³². Tool annotations, added in 2025³¹, are still there, and clients “MUST consider” them untrusted “unless they come from trusted servers”⁴⁰. The data layer of the current architecture still lists “core primitives, such as tools, resources, prompts and notifications”²³. One year in, the maintainers called MCP “the de-facto standard” for providing context to models⁴¹.

In 2022 every application wrote its own loop: ask the model, run the tool it requested, paste the result back, ask again. OpenAI made a first attempt to host part of that loop with the Assistants API in November 2023, whose threads let developers “hand off thread state management to OpenAI”²⁰. That API shut down on August 26, 2026³⁰.

By then both large providers offered the whole loop as a product. Anthropic launched Claude Managed Agents in public beta on April 8, 2026, as “a fully managed agent harness for running Claude as an autonomous agent with secure sandboxing, built-in tools, and server-sent event streaming”⁴³. OpenAI released its Agents API in public beta on September 10, 2026, with “a managed Codex harness while OpenAI handles session orchestration, context compaction, and recovery”³⁰. OpenAI’s documentation says the Agents API “manages the agent loop for you”⁴⁴.

When someone else runs the loop, their defaults become your behavior. In Claude Managed Agents, “the agent toolset defaults to always_allow, and MCP toolsets default to always_ask“⁴², and custom tools sit outside these policies because your application runs them⁴². A later release added an auto policy in which “the server evaluates each agent or MCP tool call and runs it, denies it, or pauses for your approval”⁴³.

Now you can read MCP as a sum of older parts. Its messages are JSON-RPC 2.0^24,25. Its first version opened every connection with “Connection initialization, capability negotiation, and session control”²⁴, the pattern of the Language Server Protocol, where “The initialize request is sent as the first request from the client to the server”⁴⁵. The specification itself says “MCP takes some inspiration from the Language Server Protocol”²¹. A tool definition carries a name, a description and an inputSchema in JSON Schema^40,46, the format function calling already used^13,47. Asking a server what it offers repeats an idea as old as CORBA’s interface repository⁶.

Let’s be precise about the benefits of LSP’s design. A language server can “be implemented once and have different tools take advantage of it”⁴⁸. This means an implementation can be reused. Each running server still serves a single development tool: “The protocol currently assumes that one server serves one tool”⁴⁵. MCP’s local servers work the same way, usually serving a single client²³, but “remote MCP servers that use the Streamable HTTP transport will typically serve many MCP clients”²³.

What MCP did not take was an answer to the questions from 1984. Did the call run? The 2026 transport says that when a stream breaks, the client “MUST re-issue it as a new request with a new request ID”³²; if the first request had already taken effect, a re-issued call can run it again. That consequence is our inference, the same one Birrell and Nelson spelled out². Where did the tool come from, and can you trust its description? Annotations stay untrusted unless the server is trusted⁴⁰. Who may call it? The first specification left enforcement to implementors²¹.

A new protocol arrives every few years, and each one is sold as the answer. How do you decide what to learn deeply and what to treat as this year’s packaging? Yan Wang gave our class a ruler in his October 2 guest lecture: “Every hot noun bundles a lasting problem with packaging from its year”⁴⁹. The lasting problem is “The underlying need that remains whatever the model does; understanding it appreciates.” The packaging is “The brand-name implementation shaped around the limits of its year; it depreciates”⁴⁹.

He splits them with two questions: “If the model were 10x better, would this still matter?” and “What problem is it actually solving, and do I still have it?”⁴⁹ For MCP, his split puts “Giving agents clear, safe interfaces and deciding what plain code should handle” on the lasting side, and “Routing every tool definition and result through the context window, MCP-first” on the packaging side⁴⁹.

Let’s apply this test to what we covered in this chapter. “Did it run?” passes both questions: a smarter caller still cannot see a lost reply. Describing a service and deciding who can call it also pass; these have been re-solved since 1991. Protocol sessions fail the second question: the need they served, keeping state across calls, can be met with a handle the model passes back, and MCP removed them in 2026^32,39. That shows the pattern of a packaging decision.

This guideline has a limit. “Packaging” means you should not base your entire judgment on it. It does not mean you can ignore it: a change in transport can break every server you operate. Also, the distinction is a judgment, not a measurement. Two careful engineers might categorize the same feature differently and should be able to explain their reasoning.

1. Tell the story of remote calls in five sentences, one per era: 1984, the 2000s, 2022–23, 2024 and 2026. Then name the three questions that are still open.
2. Choose one feature from a tool protocol you use. This could be a transport, a registry, or a permission prompt. Apply Yan Wang’s two questions to it and determine if it represents a lasting problem or merely packaging.
3. Imagine your agent’s send_email tool timed out. Explain to a teammate why simply retrying isn’t automatically safe. Then, describe what the tool would need to make a retry safe.