MCP OAuth dynamic client registration rejects due to invalid tos_uri/policy_uri

[nulljosh]

When authenticating the hosted Primitive MCP server (https://www.primitive.dev/mcp) from an MCP client, dynamic client registration fails validation before the OAuth flow can start.

Server-returned client registration response includes invalid values:

[
  {
    "code": "invalid_value",
    "values": [""],
    "path": ["tos_uri"],
    "message": "Invalid input: expected \"\""
  }
]

and

{
  "expected": "string",
  "code": "invalid_type",
  "path": ["policy_uri"],
  "message": "Invalid input: expected string, received null"
}

tos_uri comes back as [""] (array containing empty string) and policy_uri as null, where RFC 7591 dynamic client registration expects these to be optional strings (or omitted entirely). This breaks OAuth for any client with strict schema validation on the registration response.

This worked as of about a week ago and appears to be a regression on the hosted MCP OAuth server. Since this repo only contains the SDKs/CLI (generated from the OpenAPI spec) and not the hosted MCP server itself, filing here as the closest public channel — please route to whoever owns the MCP OAuth endpoint.

Expected: tos_uri/policy_uri should be omitted or returned as valid strings/null-omitted per spec, not [""] / null.

[nulljosh]

Additional debugging notes that might speed up the fix:

Full validation error (from a second reproduction just now, via Claude Code's /mcp connect flow):

[
  { "code": "invalid_type", "path": ["client_uri"], "message": "Invalid input: expected string, received null" },
  { "code": "invalid_union", "path": ["logo_uri"], "message": "Invalid input" },
  { "code": "invalid_union", "path": ["tos_uri"], "message": "Invalid input" },
  { "code": "invalid_type", "path": ["policy_uri"], "message": "Invalid input: expected string, received null" }
]

Pattern worth noting: some fields come back as null (client_uri, policy_uri) while others come back as a 1-element array containing an empty string, e.g. "tos_uri": [""], instead of either a plain string or being omitted. That specific shape — a scalar URI field wrapped in an array — smells like a bug in how the registration response is being assembled server-side, e.g.:

• a field going through URLSearchParams.getAll() / multi-value query-param parsing instead of .get(), or
• a Postgres array-typed column being used for what should be a single nullable text column, or
• a form/JSON serializer defaulting empty optional fields to [""] instead of null/omitting them.

Timeline: this flow worked when we set it up ~1 week ago (around 2026-07-07) and has been broken since at least today (2026-07-14) — so likely traceable to a registration-endpoint or client-metadata-storage change shipped in that window.

Not a client-side issue: confirmed via two independent MCP clients hitting https://www.primitive.dev/mcp's dynamic client registration endpoint, both rejecting on the same fields, so this isn't a single client's parsing quirk — the server itself has RFC 7591 client metadata in null/array shapes where plain optional strings are expected.

Happy to provide more repro detail if useful.

[etbyrd]

Thanks for the detailed report. Confirmed and diagnosed; a server-side fix has landed and will go out with an upcoming production deploy.

What's actually happening: the registration endpoint echoes optional RFC 7591 client metadata fields (client_uri, logo_uri, policy_uri, tos_uri) as explicit JSON null when the registering client didn't supply them, instead of omitting them as RFC 7591 section 3.2.1 expects. MCP clients validate the registration response with a schema that treats these fields as string-or-absent, so the explicit nulls fail validation with exactly the invalid_type: expected string, received null errors you saw.

One correction on the debugging notes: the server never returns tos_uri: [""]. The "values": [""] in that error is part of Zod's issue format: for an invalid_value issue, values lists the expected literal values of the schema branch (here z.literal("") inside a union), not what the server sent. A fresh registration against the live endpoint returns plain nulls:

"client_uri": null, "logo_uri": null, "policy_uri": null, "tos_uri": null

So the multi-value query param and array-column theories don't apply; it's a plain null-vs-omitted issue.

On the timeline: nothing changed on the registration path server-side in the window you mention, so this most likely surfaced through an MCP client update that tightened response validation, or because your original setup cached its client registration and only performed a fresh registration recently.

The fix omits unused metadata fields from the registration response, per the RFC. I'll update this issue once it's deployed; a fresh MCP connect should then complete normally.

[etbyrd]

Deployed. Fresh registrations now omit unused metadata fields, so strict MCP clients validate the response and the OAuth flow completes. If you still see a failure, clear any cached client registration in your MCP client and reconnect. Closing; reopen if it recurs.

[nulljosh]

😄 👍