The address, and — only on a second attempt — the client credential the server needs.
No auth-mode chips. The client credential is a LATER step by design, offered only after every
automatic path has been tried and refused: asking for it up front would make the common case
(96.2% of hosts register automatically) look like the hard case. The dashboard does not show the
fields until a start has come back with MCP_CLIENT_CREDENTIALS_REQUIRED or
MCP_PUBLIC_CLIENT_ID_REQUIRED, and then it resubmits this same body with them filled in. The
second code is what makes the secret optional on that form, for a service that issues none.
A secret never arrives without an id. A lone secret is a 422, not a partial credential; a
lone id is a public client, and only the discovered server can say whether that is one this
service issues.
An empty secret is read as none supplied; a whitespace-only one is refused. Those are
different answers on purpose: an empty field is somebody who has no secret, and spaces are a
mistyped one. An empty client id is refused either way. The generated types cannot express any of
this on their own — they describe two independent optional strings, which is what a second
consumer would build against.
The pair, its bounds and both of those rules are INHERITED from
:class:services.mcp_oauth.PastedClientCredentialFields, which is the only implementation. This
body adds the three fields the console has and the chat setup lane must not: the address, the
account to re-consent, and the audience.