How a Call Actually Flows
Four steps, and nothing surprising in them:
- Connect. The host starts the tool server, or opens an HTTPS connection to a remote one.
- Discover. The client asks what the server offers. This happens live, every session, which is why a tool added yesterday works today with no update to the assistant.
- Call. The model picks a tool and the client invokes it. A well-built host asks your permission first.
- Return. The result comes back as text, an image, or a file reference, and gets added to the conversation.
One twist is worth knowing, because it is the thing a normal API genuinely cannot do: a server can ask a question back mid-call. If a tool needs your GitHub username, or needs you to approve something in a browser, it says so instead of failing. The assistant collects the answer and retries. Sensitive things like passwords, API keys, and payment details must go through a browser window rather than the chat, so they never touch the model's context.
For developers: the retry pattern
This is called MRTR (multi round-trip requests), and it replaced server-initiated requests in 2026-07-28 as a breaking change. Because the protocol is stateless, a server cannot hold a request open while it waits. It ends the request with resultType: "input_required", an inputRequests map, and an opaque requestState blob. The client gathers the input, then re-sends the original request with inputResponses and the echoed state, under a new JSON-RPC id.
Two rules that catch people: clients must echo requestState back byte-for-byte without inspecting it, and servers must treat it as attacker-controlled: sign it, bind it to a user and a short expiry, and reject anything that fails verification.