Summary
Installing the Val Town plugin via the claude.ai Directory (Plugins → Browse → Val Town → install) never triggers an authentication flow. The plugin reports "installed and ready to use," but no OAuth handshake occurs, the connector never shows as connected, and the plugin's tools are silently unavailable in chat — with no error surfaced anywhere.
Repro steps
- In claude.ai, uninstall the Val Town plugin if already installed (Directory → Plugins → Val Town → Uninstall).
- Directory → Plugins → Browse → search "Val Town" → click install (+).
- Observe: toast says "Val Town is installed and ready to use." No login/consent screen appears.
- Check Settings → Customize → Connectors: the
valtown connector is either missing entirely from the list, or (in some sessions) shows status — with no "Connect" action available — unlike every other not-yet-connected connector, which shows a "Connect" button.
- Start a new chat and ask Claude to do something requiring a Val Town tool call (e.g. "List my Val Town vals").
- Observe: Claude responds that it has no active Val Town connector in the chat and falls back to web search / memory instead of attempting the tool call or prompting for auth.
Network trace evidence
Captured via browser devtools during step 2 (the install click). The entire install flow is:
PUT /api/organizations/{org}/plugins/{plugin_id}/enabled → 200
That's it — no request is made to api.val.town, /v3/mcp, /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, or any /oauth/* endpoint. The install action only flips an enabled flag in claude.ai's own plugin table; it never attempts to connect to the bundled MCP server, so there's nothing to trigger an OAuth prompt from.
This differs meaningfully from Settings → Connectors → Add custom connector, which — pointed at the exact same URL (https://api.val.town/v3/mcp) — correctly performs discovery, dynamic client registration, and redirects to Val Town's real sign-in page. We verified this manually and it's a working stopgap (see below), which confirms the MCP server side (discovery metadata, DCR, scopes) is fine; the gap is specifically in the plugin-install code path never attempting a connection.
Workaround
Manually add a custom connector (Settings → Customize → Connectors → Add → Add custom connector) with the identical URL the plugin uses. claude.ai correctly recognizes it ("This connector is required by the following plugin: Val Town") and offers a working Connect button that completes the full OAuth flow. This is the only reliable way we've found to get the plugin's tools working today.
Related upstream issues
Ask
The plugin-install flow (and/or first tool use in a fresh chat) should attempt a connection to any bundled MCP server requiring auth and surface the same Connect/OAuth UI that "Add custom connector" already has, rather than silently marking the plugin "ready to use" with no working tools and no indication anything is wrong.
Summary
Installing the Val Town plugin via the claude.ai Directory (Plugins → Browse → Val Town → install) never triggers an authentication flow. The plugin reports "installed and ready to use," but no OAuth handshake occurs, the connector never shows as connected, and the plugin's tools are silently unavailable in chat — with no error surfaced anywhere.
Repro steps
valtownconnector is either missing entirely from the list, or (in some sessions) shows status—with no "Connect" action available — unlike every other not-yet-connected connector, which shows a "Connect" button.Network trace evidence
Captured via browser devtools during step 2 (the install click). The entire install flow is:
That's it — no request is made to
api.val.town,/v3/mcp,/.well-known/oauth-protected-resource,/.well-known/oauth-authorization-server, or any/oauth/*endpoint. The install action only flips anenabledflag in claude.ai's own plugin table; it never attempts to connect to the bundled MCP server, so there's nothing to trigger an OAuth prompt from.This differs meaningfully from Settings → Connectors → Add custom connector, which — pointed at the exact same URL (
https://api.val.town/v3/mcp) — correctly performs discovery, dynamic client registration, and redirects to Val Town's real sign-in page. We verified this manually and it's a working stopgap (see below), which confirms the MCP server side (discovery metadata, DCR, scopes) is fine; the gap is specifically in the plugin-install code path never attempting a connection.Workaround
Manually add a custom connector (Settings → Customize → Connectors → Add → Add custom connector) with the identical URL the plugin uses. claude.ai correctly recognizes it ("This connector is required by the following plugin: Val Town") and offers a working Connect button that completes the full OAuth flow. This is the only reliable way we've found to get the plugin's tools working today.
Related upstream issues
claude mcp add) never triggers the OAuth flow either; root cause noted as "the CLI implementation is missing the OAuth flow trigger logic that exists in the web app version." Same category of gap: the "attempt connection / prompt for auth" logic isn't implemented consistently across every surface.oauthblock (clientId,callbackPort) from a plugin's bundled.mcp.json. We've added anoauth.authServerMetadataUrlhint to our own.mcp.jsonin this repo regardless (val-town/plugins, see companion PR), but per #359 it's likely to be stripped during sync today, and it wouldn't address this issue's root cause anyway since the install flow doesn't attempt a connection at all, with or without that field present.Ask
The plugin-install flow (and/or first tool use in a fresh chat) should attempt a connection to any bundled MCP server requiring auth and surface the same Connect/OAuth UI that "Add custom connector" already has, rather than silently marking the plugin "ready to use" with no working tools and no indication anything is wrong.