Backwards-compat quick pass: audit current draft against @tobinsouth's auth concerns (SEP-2742) before finalizing the limited shape

[tadasant]

🤖 Drafted by Claude Code (an AI coding agent) on behalf of @tadasant. The substance was reviewed by a human before filing.

Summary

Before we finalize the initial limited-shape Server Card SEP, do a quick pass over the current draft to make sure nothing in it is backwards-incompatible with the auth concerns @tobinsouth raised in modelcontextprotocol/modelcontextprotocol#2742. This is step 1 of the plan in #13 — the gating, do-it-now item — as distinct from the post-ratification work of actually incorporating the full auth shape (#13 steps 2–3).

The point of this pass is not to design the auth block now. It's to confirm the minimal shape we're about to lock makes no commitment that would have to be broken (rather than additively extended) to later accommodate Tobin's scenarios. We'd rather catch a forward-incompatible decision now than ship it and have the fast-follow require a breaking change to server.json / the Server Card.

What Tobin is proposing (the thing we must stay compatible with)

SEP-2742 adds an auth block to the Remote shape shared by server.json and Server Cards. From the PR description:

This SEP adds an auth block to the Remote shape shared by server.json and Server Cards (SEP-2127), so a remote MCP server can declare which authentication methods it supports — and what an OAuth client needs that RFC 8414 / RFC 9728 discovery cannot provide — before the first MCP request.

It declares (verbatim from the PR):

• Authentication posture — none / optional / required …
• A method menu — the server can offer OAuth and/or static-header authentication, and the consumer picks one.
• OAuth registration mode — dynamic (RFC 7591 DCR), client-metadata (CIMD I-D), or static …
• Client credential type — none, client_secret, private_key_jwt, tls_client_auth …
• Out-of-band Authorization Server endpoints …
• Input.pattern / Input.maxLength — two small validation hints for configuration UIs, additive to the existing Input shape.

Crucially, Tobin frames the whole thing as purely additive (PR description):

MCP authorization spec — this is purely additive. The default (registration: "dynamic", posture: "required") matches the spec's recommended DCR + PKCE flow exactly. Servers that comply with the auth spec need declare nothing.

He also explicitly flags the layering question that lands on this WG:

Tagging @dsp-ant, @SamMorrowDrums, and @tadasant for thoughts on whether this is the right shape and where it should live (this SEP, a follow-up to #2127, or an extension).

So the compatibility question for us is narrow and answerable now: does the current Server Card draft already say anything about Remote, Input, or auth that would collide with adding this block additively later?

The audit checklist

Go field-by-field over the current draft (schema.ts → generated schema.json, docs/discovery.md, and the SEP-2127 shape) and confirm each item:

• No conflicting auth field today. Confirm the current Remote shape has no auth (or authentication, oauth, etc.) field that would clash in name or semantics with Tobin's proposed auth block. If there's a stub, make sure its shape is a strict subset of (or trivially widenable to) the proposed one.
• Remote is open to additive growth. Confirm the schema doesn't forbid the future auth block — e.g. no additionalProperties: false on Remote that would make a card carrying auth invalid against the v1 schema. (If we lock additionalProperties: false, adding auth later is a schema-breaking change, not an additive one — this is the single most likely forward-incompat trap.)
• Input shape won't collide. Tobin adds Input.pattern and Input.maxLength as additive hints. Confirm the current Input definition (a) doesn't already use those keys for something else, and (b) isn't sealed against new optional members.
• Existing auth-adjacent fields are consistent. SEP-2127 already declares headers / URL templates but (per Tobin) "no OAuth declaration of any kind." Confirm whatever auth-adjacent surface we do have (e.g. header declarations) is something the proposed auth method-menu can sit alongside without contradiction.
• Defaults don't preempt the posture model. Tobin's default is posture: "required", registration: "dynamic". Confirm the current draft doesn't bake in a conflicting implicit assumption (e.g. "remote servers are unauthenticated by default") that the prose would then contradict once auth lands.
• server.json ↔ Server Card parity holds. Because the auth block targets the shared Remote shape, confirm our split between ServerCard and Server (the packages-bearing superset) doesn't put Remote in a place where one side could take auth and the other couldn't.

Outcome

This issue is satisfied when we've walked the checklist and either (a) confirmed the current draft is cleanly forward-compatible with SEP-2742's additive auth block, or (b) identified the specific fields/constraints that need adjusting before the limited-shape SEP is finalized, and filed/fixed those. Then #13 steps 2–3 (finalize the limited shape, then fast-follow the full auth incorporation) can proceed without risking a breaking change.

Blocks #13. This is the step-1 prerequisite called out in #13; the broader auth incorporation tracked there is the post-ratification fast-follow.

Links: SEP-2742 (PR #2742) · #13 (incorporate comprehensive auth scenarios) · SEP-2127 (PR #2127).