Vercel Connect → Builder.io OAuth authorize redirect missing required resource parameter (RFC 8707)

Help
1

Vercel Connect → Builder.io OAuth authorize redirect missing required resource parameter (RFC 8707)

Summary

We’re trying to stand up a Vercel Connect–managed OAuth connector to Builder.io’s MCP server (https://mcp.builder.io/mcp/publish) so an internal AI agent can read and write CMS content. The connector is correctly created and linked to our Vercel project, but the actual OAuth consent flow always dead-ends on Builder.io’s own authorize page with:

Authorization Error resource parameter is required (RFC 8707)

This happens on every attempt, for every user, and blocks the connector from ever being authorized. We believe the redirect Vercel Connect constructs to Builder.io’s /app/oauth/authorize endpoint is missing a resource query parameter that Builder.io’s authorization server requires (RFC 8707 Resource Indicators), and Builder.io’s authorize page is rejecting the request before any login/consent screen is shown.

Environment

  • Connection definition (unmodified from Vercel Connect’s documented Eve integration pattern):

    import { connect } from "@vercel/connect/eve";
import { defineMcpClientConnection } from "eve/connections";

export default defineMcpClientConnection({
  url: "https://mcp.builder.io/mcp/publish",
  auth: connect("mcp.builder.io/builder"), // defaults to principalType: "user"
  // ...
});

Setup steps completed (for context)

  1. vercel link — project linked.
  2. vercel connect create mcp.builder.io --name builder — connector created.
  3. vercel connect attach scl_b8GPrGgPqa9B63gdQrUKfg --yes — succeeded, attached the connector to content0 for all three environments (production, preview, development). This resolved a separate, earlier error (Connector is not enabled for this environment, HTTP 403) that we were hitting before this step was completed.
  4. Attempting to actually authorize the connector (either by triggering it live through our deployed Slack-based agent, or via vercel connect token scl_b8GPrGgPqa9B63gdQrUKfg --yes from the CLI) redirects to Builder.io’s OAuth authorize page and fails as described below.

Steps to reproduce

  1. With the connector created and attached as above, trigger any flow that requires end-user authorization of the mcp.builder.io/builder connector (e.g. vercel connect token <connector-id> --yes, or a live user-scoped tool call through the connected agent).

  2. This redirects the browser to a URL of the form:

    https://builder.io/app/oauth/authorize?client_id=5e5e2427-e062-46ad-81ce-4d7cf8fb6607&code_challenge=<PKCE challenge>&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fconnect.vercel.com%2Fcallback&response_type=code&state=<state>

    Note there is no resource parameter in this query string.

  3. Builder.io’s own app (builder.io’s React/MobX app shell) renders:

    Authorization Error resource parameter is required (RFC 8707)

    immediately, with no login or consent prompt ever shown. There’s no network/fetch error logged in the browser console for this — Builder.io’s authorize page appears to validate the incoming query parameters client-side (or via an immediate server response) and reject before any further interaction is possible.

Expected behavior

The OAuth authorize redirect should either include whatever resource value Builder.io’s authorization server expects (e.g. the MCP server URL, https://mcp.builder.io/mcp/publish), or Builder.io’s authorize endpoint should not require it for this client. Completing the redirect should reach a normal Builder.io login/consent screen.

Actual behavior

100% reproduction rate across multiple independent attempts, on different dates, from different entry points:

  • Interactively through our deployed Slack-based agent (principalType: "user", the default/documented config).
  • Directly via vercel connect token <connector-id> --yes from the Vercel CLI (same client_id, different device-code/request-code each time).
  • Also previously tried switching the connection to principalType: "app" as a fallback — that path fails differently (Connector is not enabled for this environment, a 403 from resolveScopedToken), which is a distinct issue from the one described here and appears to be about whether an app-level grant has ever been completed for this connector (blocked on this same authorize-page issue, since app-scoped grants also can’t complete when the initial OAuth handshake itself never completes).

In every user-scoped attempt, the flow reaches Builder.io’s authorize page and stops there with the RFC 8707 error — the OAuth grant can never be established.

Impact

We cannot complete authorization for this connector at all, in any environment (local dev, preview, or production), which blocks our agent from ever writing to Builder.io content through the MCP server. Read-only access to Builder.io content (via separate, non-OAuth API-key-based tools) is unaffected — this only blocks the OAuth-gated write/publish path.

Ask

We’d appreciate help from both sides here, since this is at the boundary between the two products:

  • Vercel Connect: please check whether the OAuth authorize request built for the mcp.builder.io/builder connector type includes a resource parameter, and if not, whether one can be added (and what value Builder.io expects).
2

Your reproduction narrows this down well. The missing resource parameter is not cosmetic: the current MCP authorization specification requires the client to include it in both the authorization and token requests, using the canonical URI of the MCP server.

Because the same incomplete redirect is produced by both the deployed agent and vercel connect token, I would take the application code and principalType out of the investigation for now. Both paths appear to converge before Builder.io receives the authorization request.

The remaining distinction is whether Vercel Connect is failing to discover the protected resource identifier or whether the managed Builder connector has no way to propagate it into the authorization and token exchanges. I would verify the protected resource metadata first and confirm that the same canonical resource value survives both requests.

I have implemented similar OAuth and MCP integration paths before. If Connect owns that redirect and exposes no resource override, the agent itself cannot repair this flow. At that point the practical choices are a correction in the managed connector or containing the workaround at the connector layer rather than changing the agent.