MCP 2026-07-28: What Multi Round-Trip Requests Change About Approvals

The significance of MCP’s 28 July 2026 release is not that it solves approvals, but that it moves more input into the live request path. The Model Context Protocol Blog announced that release on 28 July 2026 and listed Multi Round-Trip Requests, authorization hardening, and a stateless protocol core among the changes. A server can ask for more information while the original work is still unresolved. That is useful. It is also easy to mistake for evidence.

What MCP Multi Round-Trip Requests add

The announcement text is the cleanest starting point, because it names the change without pretending it is only an implementation detail.

The 2026-07-28 Model Context Protocol specification is out, bringing a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs.

— The 2026-07-28 Specification | Model Context Protocol Blog, 28 July 2026

The same Model Context Protocol Blog says server-to-client requests for sampling and elicitation are being redesigned to use Multi Round-Trip Requests, removing the need for constantly open bidirectional streams. That is the operational fix. A server no longer has to finish, fail, or hold a separate channel open simply because the next safe step needs more input.

The draft MRTR page gives the pattern its narrow shape: the server encodes needed context into requestState, and the client echoes that value back on retry. The client is not supposed to understand that state. It is the carrier, not the judge.

Clients MUST NOT inspect, parse, modify, or make any assumptions about the requestState contents.

— Multi Round-Trip Requests - Model Context Protocol draft, 30 August 2026

That matters for approvals. If a tool is about to release a payment, delete a record, or change a customer’s credit limit, the server can interrupt the path and require more input before continuing. The approval request can sit inside the same live exchange rather than being bolted on as a separate workflow.

That does not make the client an approval authority. The draft MRTR rule makes the opposite point. The client returns server state; it does not interpret it. If your design depends on the client understanding the state and deciding that the transfer is acceptable, the design is already outside what this particular rule supports.

The MCP Python SDK page describes the basic reason in plainer terms: sometimes a tool cannot finish in one round trip. The MCP C# SDK page also says a tool can perform multiple rounds of interaction across retries. Those are implementation-facing statements, not control evidence. They explain how a conversation can continue. They do not prove why the final act was allowed.

This distinction is easy to lose because the user experience can look complete. The agent asks. A human answers. The tool continues. The downstream system changes state. Everyone watching the trace sees an approval-shaped event and moves on.

The failure appears later. A reviewer asks why the payment release was allowed. The answer cannot be “because the retry succeeded”. A successful retry tells you the protocol path completed. It does not, by itself, tell you the policy that authorised the outcome, the approver’s authority, or whether the same action would have been blocked under different conditions.

For more on the narrower tool-call question, the earlier Crelis piece on who authorizes an MCP tool call separates identity, permission, and proof. The MRTR change moves the timing of the permission conversation. It does not collapse those categories.

The MCP authorization spec around the call

The 28 July 2026 authorization page says authorization servers and MCP clients should support OAuth Client ID Metadata Documents. It also says MCP authorization servers must provide at least one discovery mechanism. Those are real requirements in the authorization layer. They are not a record-retention policy.

The draft authorization page states the boundary even more directly.

This specification defines the authorization flow for HTTP-based transports.

— Authorization - Model Context Protocol draft, 30 August 2026

A transport-level authorization flow can be necessary and still insufficient. It can decide whether the client can proceed against an MCP server. It can support discovery. It can carry the client through the expected authorization steps. None of that automatically records the business authority behind a specific act.

Take a deleted record. The authorization layer may be satisfied that the client can call the server. The live request may pause and gather extra input. The final tool may delete the record. The evidence problem starts after that, when someone asks whether this record, in this account, under this retention rule, could lawfully be removed.

The 28 July 2026 MCP authorization spec also says authorization servers and MCP clients may support OAuth 2.0 Dynamic Client Registration. Earlier MCP authorization text says clients must include the resource parameter in authorization and token requests. These requirements harden and structure the flow. They still do not say that an approval decision must be kept in a tamper-evident business record.

That is not a criticism of MCP. A protocol does not have to be an audit system to be valuable. The mistake is to let a working protocol path stand in for a control record, because the protocol object is the newest and most visible artefact in the room.

The public Crelis Model Context Protocol topic page exists because this boundary keeps reappearing in agent designs. MCP gives engineers a shared way to connect models, clients, servers, tools, and resources. The compliance question is different. It asks whether the authority for a particular outcome survives the outcome itself.

The MCP authorization flow and step-up approval

The draft authorization page says a client may attempt the step-up authorization flow or abort the request immediately. The same draft says clients acting on behalf of a user should attempt the step-up authorization flow. That is the part of the story most relevant to approvals, because it acknowledges that the first level of authority may not be enough.

The MCP Apps authorization page calls this a practical application of the step-up authorization flow described in the spec. It also describes per-server authorization as the entire MCP server requiring authorization at connection time. Those are different control shapes. One is broad access before use. The other is an escalation when the attempted action needs more authority.

A finance agent illustrates the split. Reading invoice status may be allowed under the agent’s ordinary access. Releasing a payment to a changed bank account should not be treated as the same act. A step-up flow gives the system a place to ask for more authority before it proceeds.

MRTR makes that interaction fit the request path more naturally. The request can pause. The missing input can be obtained. The handler can retry. The user experience improves, and the engineering model becomes cleaner.

But “approved during the request” is not the same as “provable after the request”. The approval may be visible to the client and server while the interaction is alive. The risk owner needs a different artefact: a durable account of the policy, actor, subject, resource, time, and outcome that can be produced after memories and dashboards have changed.

The MCP Python SDK page makes one further point that risk teams should notice. It says inconsistent verifier components can change the principal mid-flow, and in-flight rounds are rejected. That is a safety property for the active interaction. It prevents one kind of confused continuation. It does not answer whether the original approval record remains available months later.

The draft MRTR page also says that if requestState influences authorization, resource access, or business logic, servers must protect its integrity. That is a serious requirement. It means the state carried back into the retry cannot be treated as harmless decoration. It also confirms the larger point: if the state affects authority, it belongs in the control model, not merely in the convenience layer.

What this means if you have to produce evidence

Evidence begins where the protocol transcript stops being enough. A transcript may show that the server asked for more input and that the client came back with it. It may show that a retry happened. It may show that the tool eventually returned success. Those are useful facts, but they are not the whole control.

A reviewer will ask a different sequence. Who was the acting agent. Which user, if any, was represented. Which policy applied. What changed in the target system. Who approved the exception. What would have happened if the answer had been no. Whether the record can be altered after the fact without the alteration showing.

The Multi Round-Trip Requests change helps with the moment of interruption. It gives the server a protocol-shaped way to say: not yet, I need more input. It can make approval less awkward to implement. It can reduce the temptation to finish the call first and ask governance to reconstruct the decision afterwards.

It does not remove the need to design the evidence path. If the payment release is later disputed, the organisation has to prove more than successful completion. It has to prove authority. Completion is a system fact. Authority is a control fact.

Crelis states the gap bluntly on its GREENLIGHT knowledge base: MCP can authorize an individual tool call and pause mid-call for a human decision, but it cannot record which policy permitted the action or keep that record after the call returns. That is a Crelis position, not a line in the MCP specification. It is still the right test for the reader who has to answer an auditor.

There is a reasonable objection. A team can build its own evidence store around MCP. Nothing in this argument says otherwise. If the server records the decision, binds it to the business object, and preserves it in a tamper-evident way, MCP can be part of a good control architecture.

The weak design is the one that assumes the protocol exchange itself has done that work. It has not. The exchange can carry an approval step. It does not automatically preserve the authority behind the approval.

Practical steps for approval design

1. Record the revision you are relying on. The Model Context Protocol Blog announced the 28 July 2026 release as including Multi Round-Trip Requests and authorization hardening. Treat that revision as a design input, not background noise.
2. Separate connection authority from action authority. The draft authorization page defines an authorization flow for HTTP-based transports. That does not decide whether a particular payment, deletion, or credit-limit change should proceed.
3. Treat requestState as server-owned state. The draft MRTR page says clients must not inspect, parse, modify, or make assumptions about requestState contents. Do not build an approval scheme that depends on the client understanding that value.
4. Design the denial path. An approval mechanism is not complete until the rejected payment, refused deletion, or blocked credit change is handled cleanly. The rejected path is usually where missing evidence shows first.
5. Persist the reason, not only the result. A successful tool result says the action completed. The evidence record should say which policy allowed it, which authority satisfied the step-up, and which system object changed.
6. Test continuity across retries. The MCP Python SDK page says inconsistent verifier components can change the principal mid-flow and cause in-flight rounds to be rejected. A retry that changes the actor is not an approval continuation.
7. Put the audit consumer in the room. Ask what a compliance officer would need to see after a disputed release, deletion, or account change. If the answer is scattered across runtime traces, the control is not ready.

Crelis builds for the gap between an allowed request and an evidenced authority decision. GREENLIGHT is the Crelis permission step, and the Crelis product demonstration asks where agents touch money, customers, records, or infrastructure. The point is not to replace MCP; it is to keep the approval record alive after the MCP exchange has ended, and a demo should be judged on that narrow claim.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Who Authorizes an MCP Tool Call? — separates identity, permission, and later proof for a single tool call.
• Model Context Protocol — the Crelis topic page for MCP.
• GREENLIGHT — the Crelis permission step for agent actions.
• Request a demo — where to test the evidence path against your own agent actions.