For a long time I was fine with a lazy analogy: an MCP tool is basically an API.

Request in. Schema on the door. Something typed comes back. You name the verb after the business intent and you move on. It stuck because it was useful. Frontend and TypeScript people already think in contracts. An MCP that exposes check_availability or open_incident feels like the tidy surface we already glue behind once.

I wrote that energy into earlier posts without much guilt. Tools as business intents. Package discipline. Zod on the way in. All still true.

What stopped being true is the one-shot part.

The 2026-07-28 MCP spec adds Multi Round-Trip Requests (MRTR / SEP-2322). In ordinary words: a tools/call doesn’t have to finish in one round trip anymore.

The server can come back with an InputRequiredResult. Mid-flight it can ask for elicitation, sampling, or roots. The client gathers that input, then retries the same tool call with inputResponses and an opaque requestState the server sent. The retry is a new JSON-RPC id. The server reconstitutes what it needs from the echoed state. No shared storage between server instances required for the basic pattern.

So the tool is allowed to be a conversation with the outside world, not a single RPC. It can elicit a field, sample a judgment, check roots, then continue and finish.

That is a process wearing a tool name.

I don’t mean "process" as corporate wallpaper. I mean an owned workflow with a beginning, mid-flight input, and an end the protocol can express.

An MCP tool can now own the sequence. The model decides when to enter it, and what language to put around it. The process decides what happens next: ask the human, ask another model, read a root, continue, return.

That split is what I keep coming back to. Language and judgment stay with the LLM. Sequencing stays with the tool. You stop pretending the chat loop is a workflow engine.

Here’s the adjacent danger.

If you tell the model "call A, then B, then C if the status is open, else D," you’ve put the control plane in natural language. That’s brittle. It’s non-deterministic when the wording drifts. It’s hard to audit. It fails closed or open in ways you can’t unit test the way you unit test a real workflow. The model is good at language. It’s a mediocre, expensive, unlogged orchestrator.

REST and gRPC call graphs don’t belong in the system prompt. They belong behind a process the tool owns, or behind real orchestration outside the model entirely: durable steps, explicit branches, retries you can see, and auth that isn’t "the model remembered to pass the token again."

An MCP with multi-turn tools makes that preference practical. You don’t need the LLM to mime a saga. You need it to decide whether to start resolve_billing_complaint, then let that process elicit what it needs, call the boring APIs in order, and come back with a result a human can read.

I’m not saying every tool should be a multi-step saga. Plenty of business intents are still one shot and should stay that way. list_open_incidents doesn’t need elicitation theatre.

I’m also not saying MRTR means you get free durability across every hosting shape. The basic pattern leans on requestState echoed by the client. Read the security notes. Treat that state as attacker-controlled input. Protect it if it influences auth or business logic.

Once tools can pause mid-flight, using the LLM as the sequencer for your company’s private HTTP dialect starts looking like a habit we should quit.