Cowork creates a broken @<plugin>-local connector for a plugin-bundled HTTP MCP server, despite the endpoint supporting DCR

Summary

When a Claude Code plugin bundles a remote HTTP MCP server via .mcp.json, installing that plugin in claude.ai Cowork / desktop creates a separate custom connector named @<server>-local and then fails OAuth registration for it — even though the target MCP endpoint fully supports Dynamic Client Registration (RFC 7591) and a built-in connector for the same endpoint authenticates fine. The bundled .mcp.json is spec-compliant and the same plugin works in the Claude Code CLI.

Environment

• Surface: claude.ai Cowork / desktop app, build v1.11847.5
• Plugin: monday-crm (Anthropic community marketplace, published from mondaycom/mcp)
• Reference ID from the error toast: ofid_fb15c93879103ae0

Symptom

The plugin bundles:

{ "mcpServers": { "monday": { "type": "http", "url": "https://mcp.monday.com/mcp" } } }

On install, Cowork auto-creates a connector named @monday-mcp-ui-local and connecting to it fails with:

Couldn't register with @monday-mcp-ui-local's sign-in service. You can try again, or add an OAuth Client ID in the connector settings. If this persists, share this reference with support: ofid_fb15c93879103ae0

Downstream: plugin skills can't reach mcp__monday__* tools, and slash commands return Unknown command: /monday-crm:setup even though the skill is registered (it appears in the Cowork Context panel).

Why this looks like a Cowork-side bug (not the plugin, not the server)

The target MCP server supports exactly the OAuth/DCR flow Cowork should use. Verified directly against the live endpoint:

| Check | Result |
|---|---|
| Protected-resource metadata (RFC 9728) | ✅ resolves at https://mcp.monday.com/.well-known/oauth-protected-resource/mcp |
| Auth-server metadata (RFC 8414) | ✅ advertises registration_endpoint: https://mcp.monday.com/register |
| Dynamic Client Registration | ✅ POST /register → 201 Created with a valid client_id — no pre-provisioned client ID required |
| Built-in monday.com connector (same URL) | ✅ authenticates in the same claude.ai account with no issue |

Since DCR succeeds server-side, and the built-in monday.com connector authenticates against the identical https://mcp.monday.com/mcp endpoint, a plugin-bundled HTTP server pointing at that endpoint should authenticate the same way. Instead Cowork creates a parallel @…-local connector and abandons the DCR handshake, surfacing "add an OAuth Client ID" for a server that doesn't need one.

Expected behavior

A plugin-bundled HTTP MCP server whose endpoint supports DCR should complete OAuth automatically in Cowork — ideally reusing or matching an existing connector for the same endpoint URL — rather than creating a broken parallel @…-local instance.

Reproduction

1. Install a plugin that bundles a remote HTTP MCP server via .mcp.json (e.g. monday-crm from the community marketplace) in claude.ai Cowork.
2. Open Connectors → observe @<server>-local created automatically.
3. Connect → OAuth registration fails with the error above.
4. (Control) Connect the built-in connector for the same endpoint URL → succeeds.

Notes

• The Claude Code CLI consumes the same .mcp.json without this problem (DCR works there).
• Removing .mcp.json from the plugin is not a fix: it is spec-correct and the CLI path depends on it. The defect is in Cowork's plugin-connector OAuth handling.