MRTR: inputRequests is a closed enum of three methods — add an extensible / reverse-DNS-namespaced member type #2919

Summary

Under the 2026-07-28 MRTR (Multi Round-Trip Request) model, the members of InputRequiredResult.inputRequests are restricted to a closed set of three JSON-RPC methods: elicitation/create, sampling/createMessage, roots/list. There is no extension hook.

Problem

Application-defined "input required" interactions cannot be modeled natively. The motivating case is an external human-approval step: a server wants to pause a tools/call until an out-of-band approver (a different human, a ticketing/approval system) acts, then resume. Conceptually this is exactly an MRTR round trip — "I need input before I can finish, here's the request, retry with the result" — but because inputRequests is closed, it can only be tunneled through url-mode elicitation/create, which:

• loses the semantics (the client renders it as "open this URL", not "an approval is pending"),
• forces the approval payload through the elicitation shape rather than an application-appropriate one,
• prevents clients from offering type-specific UX (e.g. "approval pending" status, approver identity, deadline).

Request

Allow a reverse-DNS-namespaced member method in inputRequests (e.g. com.example/approval), mirroring how _meta keys are already namespaced in MCP. Semantics:

• Servers MAY emit a namespaced member; the params shape is defined by the namespace owner.
• Clients that don't recognize a namespaced member MUST ignore it (and, per existing rules, the server MUST NOT require a capability the client didn't declare).
• The existing three methods remain the reserved/standard set.

This keeps the closed standard set while giving the ecosystem a forward-compatible extension path — the same trade-off _meta namespacing already makes elsewhere in the spec.

Use case

External/asynchronous approval gating ("AARM"-style) before a sensitive tool proceeds — a common enterprise pattern that today has no first-class MRTR representation.