Release v1.24.1

Bug-fix release focused on OAuth 2.1: the ChatGPT connector can complete its token exchange again, and OAuth 2.1 mode now fails fast with an actionable message instead of dying at the last step of the browser flow. Also adds a per-tool block list for trimming individual tools out of any tier.

What's Changed

• fix(oauth21): require GOOGLE_OAUTH_CLIENT_SECRET in OAuth 2.1 mode and fail at startup with an actionable error instead of letting the browser flow die on invalid_request: client_secret is missing at /oauth2callback. Google enforces the secret on the authorization code exchange even for public clients sending a valid PKCE code_verifier, so the documented "secretless" launch block could never complete end to end. MCP clients still connect with PKCE and no secret — the secret is only used by this server for its own upstream exchange with Google, and it doubles as the JWT signing key material, so FASTMCP_SERVER_AUTH_GOOGLE_JWT_SIGNING_KEY is no longer needed. Deployments where a separate IdP performs the code exchange are exempt via EXTERNAL_OAUTH21_PROVIDER=true. Fixes #1008 by @taylorwilsdon in #1019
• fix(deps): bump fastmcp to >=3.4.7 to restore the ChatGPT connector (developer mode), which authenticates via CIMD with private_key_jwt client assertions. FastMCP 3.4.4's OAuthProxy validated those assertions against a doubled-slash audience (https://host//token) when the server is deployed at a bare origin, rejecting ChatGPT's correctly signed aud: https://host/token with invalid_client: Invalid JWT assertion — sign-in and consent completed, then the token exchange failed with a generic "There was a problem connecting". Fixes #1015 by @taylorwilsdon in #1018
• enh(tools): add --disabled-tools <name> ... and WORKSPACE_MCP_DISABLED_TOOLS (comma-separated) to block individual tools by name. Every other filter is an allowlist; this one is subtractive, so it composes with --tools, --tool-tier, --read-only, and --permissions, and block wins over allow — you can drop send_gmail_message while still running --tool-tier core. Unmatched names log a warning rather than failing startup, since a name is legitimately absent when its service isn't loaded. Works for plugin users who can't pass CLI args, and the resolved block list is shown in the startup configuration banner by @taylorwilsdon in #990

Upgrade notes

If you were running OAuth 2.1 in the README's old secretless configuration, the server will now refuse to start until you set GOOGLE_OAUTH_CLIENT_SECRET (use a Web application client). That flow never actually completed against Google, so this converts a confusing mid-flow 500 into a startup error that tells you what to set. FASTMCP_SERVER_AUTH_GOOGLE_JWT_SIGNING_KEY becomes optional once the secret is set — the JWT key is derived from it — but an explicit key is still honored if you'd rather set one.

Note that --disabled-tools doesn't narrow the OAuth scopes requested at consent; scopes are derived from the loaded services, not from individual tools. Use --read-only or --permissions when the goal is scope reduction rather than a smaller tool list.

Full Changelog: v1.24.0...v1.24.1