`authorization-code-grant` never sends the RFC 8707 `resource` parameter

[tylerklose]

In the authorization scenarios the runner is the MCP client. The spec:

The resource parameter:

1. MUST be included in both authorization requests and token requests.

and, further down:

MCP clients MUST send this parameter regardless of whether authorization
servers support it.

src/scenarios/authorization-server/authorization-code-grant.ts sends it in
neither. There's no --resource flag and no resource field on
AuthorizationServerOptionsSchema, so --file can't supply it either.

The suite asserts this in the other direction — token-endpoint-auth.ts emits
resource-parameter-in-authorization and resource-parameter-in-token (#118).
So the harness fails a requirement it enforces elsewhere.

An authorization server that mishandles resource can't fail these scenarios:
the parameter never arrives.

Why a flag rather than discovery

#110 suggested getting resource via discovery. That works in the client
direction, which has protected-resource metadata. This direction has none:
--url is the authorization server issuer, and the only document fetched is
RFC 8414 server metadata, which never names the MCP server. So it has to come
from the operator.

Not proposing a new AS-side assertion

RFC 8707 §2 makes AS audience restriction a SHOULD, and MCP puts no resource
obligation on authorization servers at all. This isn't "the AS must honor it" —
it's the harness sending what a client sends. The PR adds no check IDs.

Open question: what should a run without --resource do?

If clients MUST always send it, why is sending it optional? Three options:

1. Silent — nothing changes for existing users, but the MUST goes
   unexercised and the report doesn't say so.
2. Fail — matches the MUST → FAILURE rule in AGENTS.md, but every existing
   authorization run fails until operators pass the flag.
3. Untestable at WARNING (untestableCheck, per Standardize how scenarios report setup/execution failures #248) — visible rather than
   silently green, but softer than the keyword rule implies.

The PR does (1). Happy to switch — your call.

Related

• Requirement origin: chore: Add requirement for RFC8707 modelcontextprotocol#734
• Client-side precedent: feat: add resource parameter validation tests (RFC 8707) #118
• Request: make resource parameter OPTIONAL (RFC 8707-aligned) modelcontextprotocol#1614 is an open request to make
  resource OPTIONAL. If that lands this becomes conditional; today's text is a
  MUST.

PR: #466