Blog

Gmail MCP 'does not support dynamic client registration': what it means and what to do

Aperisa ยท 8 min read

Google's Gmail MCP server will hand a client with no token its full tool list. It won't hand that client an OAuth client ID.

That second part is what the error means. "Does not support dynamic client registration" says your harness tried to register itself as an OAuth client on the fly, using RFC 7591, and Google's authorization server has no endpoint for that. Google expects you to create the OAuth client yourself in the Google Cloud console and give the harness its client ID and secret. Our view: this is Google working as documented, not an outage to wait out. The question that matters is whether your harness accepts a client you registered yourself.

Checked on 2026-10-27 (UTC). Harness status comes from the open issues and current docs on that date. The latest releases were OpenClaw 2026.10.7 and Hermes Agent v0.22.5. Google's Workspace MCP servers are in Developer Preview.

What does "does not support dynamic client registration" mean?

RFC 7591 (July 2015) "defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers." The client POSTs its metadata (name, redirect URIs) to a registration endpoint and gets a client_id back, with no human in a console.

A client learns that the endpoint exists from the authorization server's metadata. RFC 8414 lists registration_endpoint as OPTIONAL. No field, no dynamic registration.

OpenClaw prints the check's result before any browser opens. From issue #146663 (OpenClaw 2026.9.3):

openclaw mcp add gmail --url https://gmailmcp.googleapis.com/mcp/v1 --auth oauth --transport streamable-http
openclaw mcp login gmail
# [openclaw] Incompatible auth server: does not support dynamic client registration

Why doesn't Google support dynamic client registration for Gmail MCP?

We followed the discovery chain ourselves on October 27, 2026 at 04:38 UTC, with curl and no credentials:

  1. https://gmailmcp.googleapis.com/.well-known/oauth-protected-resource/mcp/v1 returned "authorization_servers":["https://accounts.google.com/"] and eleven Gmail scopes, from gmail.readonly up to https://mail.google.com/.
  2. https://accounts.google.com/.well-known/openid-configuration listed authorization, token, device, userinfo and revocation endpoints. It had no registration_endpoint and no client_id_metadata_document_supported.
  3. A POST of initialize to https://gmailmcp.googleapis.com/mcp/v1 returned 200, and tools/list returned the tool list. A tools/call for list_labels returned 401 with WWW-Authenticate: Bearer resource_metadata=... and the text "Request is missing required authentication credential."

No registration endpoint, and no Client ID Metadata Document support either.

Google's docs don't explain the choice. They state the requirement. The OAuth 2.0 overview (last updated October 16, 2026) starts with "Obtain OAuth 2.0 credentials from the Google API Console," described as "a client ID and client secret that are known to both Google and your application." The OpenID Connect guide says you "must set up a project in the Google Cloud Console to obtain OAuth 2.0 credentials, set a redirect URI" before using Google's OAuth. Every client is one somebody created.

Google's Workspace MCP setup guide (last updated October 27, 2026 UTC) follows the same model: membership in the Developer Preview Program, a Cloud project, the Gmail API and Gmail MCP API enabled, a consent screen, then a client whose ID and secret you paste into the MCP client.

What does the MCP spec say about dynamic client registration?

The 2026-07-28 client registration section names three mechanisms and an order. Clients that support all of them should use pre-registered client information first, then Client ID Metadata Documents, then dynamic registration, then prompt the user.

On dynamic registration it is blunt: "Dynamic Client Registration is deprecated. New implementations should use Client ID Metadata Documents instead." It is a MAY, kept "for backwards compatibility."

And on the case Gmail needs: "MCP clients SHOULD support an option for static client credentials such as those supplied by a pre-registration flow." That can be a hardcoded client ID or a UI where users "enter these details, after registering an OAuth client themselves." Google is inside the spec here. A harness that only does dynamic registration is the part that's behind.

Which harnesses accept a pre-registered client today?

Harness Accepts your own client ID and secret? Status with Google's hosted servers, October 27, 2026 (UTC)
OpenClaw No. Per the issue thread, the oauth block takes scope, redirect URL, client metadata URL and auth profile settings, but no client ID or secret. Blocked at login. Tracked in #116052, open; #146663 was closed as a duplicate by the triage bot. A 2026.10.5 comment reports the same missing client ID option for a Google Home server.
Hermes Agent Yes, as oauth.client_id and oauth.client_secret. Open bugs. Login never starts because Google answers initialize without a token (#89412, 13 comments). #137289 adds an issuer trailing-slash mismatch and a configured scope that gets ignored. Fix PRs #97010 and #137296 are open.
Antigravity Yes, per Google's guide, as oauth.clientId and oauth.clientSecret in ~/.gemini/config/mcp_config.json. Google's documented setup. The secret sits in that file in plaintext.

Hermes is worth a closer look, because its docs already describe the fix for Drive: Google's Drive server "returns a 400 Bad Request" to the registration step, so you add your own client and run hermes mcp login. For Gmail and Calendar, the reports in #89412 say that still ends with "Server responded, but no OAuth token was obtained." A pull request that forced the flow, #53873, was closed on October 24 in favor of #97010, after a tester reported it still failed under mcp 2.x.

What can you do about it?

Option 1: Register your own OAuth client

Follow Google's Workspace MCP guide to the point where you have a client ID and secret. Google's OAuth docs say to pick Desktop app for "Windows, macOS, or Linux applications or CLI tools." Google's Workspace MCP guide uses Web application with a registered redirect URI for Antigravity, and Hermes reporters used both types. Then give the harness the pair. Antigravity keeps the client secret in plaintext in ~/.gemini/config/mcp_config.json, so don't commit that file, and use one OAuth client per harness so you can revoke one without breaking the others.

For Hermes, the block below combines two examples from its docs (Drive's client_id and client_secret, Asana's redirect_port). It does not work for Gmail today: open issues #89412 and #137289 report that login never completes. It is the shape to use once those are fixed:

mcp_servers:
  gmail:
    url: "https://gmailmcp.googleapis.com/mcp/v1"
    auth: oauth
    oauth:
      client_id: "${GMAIL_OAUTH_CLIENT_ID}"
      client_secret: "${GMAIL_OAUTH_CLIENT_SECRET}"
      redirect_port: 27890

Register http://localhost:27890/callback on the client if your harness uses that callback. Four limits from Google's docs and the issues:

  • A consent screen with an external user type in "Testing" status gets refresh tokens that expire in 7 days. One reporter on #89412 points out that, while the login bug stands, Hermes then has no way to re-authorize.
  • Google allows 100 refresh tokens per Google account per client ID. Past that, a new one invalidates the oldest without warning.
  • #137289 reports that the MCP SDK requests every scope Google lists, including https://mail.google.com/ and gmail.send, even when you configure fewer. Read the consent screen before you approve.
  • Reporters on #89412 and #137289 say Google rejects Gmail scopes in the device flow, so plan on a browser on the same machine or an SSH tunnel.

Option 2: Use a third-party Gmail server that handles Google auth itself

Put a different MCP server, one built to connect to Gmail, between the harness and Google. That server holds its own registered Google client, runs the consent flow on its side, and exposes tools to your harness behind a credential the harness already supports, such as a static Bearer header (url plus headers in both OpenClaw and Hermes). Dynamic registration never comes up, because the harness never talks OAuth to Google.

The tradeoff is trust. That server holds your Google tokens. Before you connect one, check who runs it, which scopes it requests, whether it keeps copies of your mail, and whether it exposes send or delete tools. For keeping an agent's inbox access read-only, see OpenClaw Gmail read-only.

Register the client, or move the OAuth

The error is accurate. Google has no registration endpoint, and the MCP spec treats dynamic registration as optional and deprecated. Bring your own client to a harness that accepts one, or use a third-party Gmail MCP server you trust to handle Google's OAuth on its side.

New to the protocol side? Start with what an MCP server is. For Drive, see OpenClaw and Google Drive.

Aperisa connects as a remote MCP server over Streamable HTTP with a Bearer key, and each key can be limited by data area and level of detail. Try it out.

FAQ

Does Google support dynamic client registration? Not for its OAuth server. On October 27, 2026 (UTC), Google's published discovery document listed authorization, token, device, userinfo and revocation endpoints but no registration_endpoint. Google's OAuth docs have you create each client in the Google Cloud console instead.

Is dynamic client registration required by the MCP spec? No. In the 2026-07-28 revision it is optional and deprecated. The spec ranks pre-registered client information first, then Client ID Metadata Documents, then dynamic registration, and says clients should support static client credentials.

Can I connect OpenClaw to Google's Gmail MCP server? Not through native OAuth yet. OpenClaw issue #116052, open as of October 27, 2026 (UTC), tracks support for a pre-registered client ID and secret. Until it lands, OpenClaw has no supported way to run Google's OAuth for this server.

Which Google OAuth client type should I create? Google's OAuth docs say to use Desktop app for Windows, macOS or Linux applications and CLI tools. Google's Workspace MCP guide uses Web application, with a registered redirect URI, for Antigravity. Match what your harness documents.

Sources

Questions

Does Google support dynamic client registration?

Not for its OAuth server. On October 27, 2026 (UTC), Google's published discovery document listed authorization, token, device, userinfo and revocation endpoints but no registration_endpoint. Google's OAuth docs have you create each client in the Google Cloud console instead.

Is dynamic client registration required by the MCP spec?

No. In the 2026-07-28 revision it is optional and deprecated. The spec ranks pre-registered client information first, then Client ID Metadata Documents, then dynamic registration, and says clients should support static client credentials.

Can I connect OpenClaw to Google's Gmail MCP server?

Not through native OAuth yet. OpenClaw issue #116052, open as of October 27, 2026 (UTC), tracks support for a pre-registered client ID and secret. Until it lands, OpenClaw has no supported way to run Google's OAuth for this server.

Which Google OAuth client type should I create?

Google's OAuth docs say to use Desktop app for Windows, macOS or Linux applications and CLI tools. Google's Workspace MCP guide uses Web application, with a registered redirect URI, for Antigravity. Match what your harness documents.

Published

Keep reading