claude-code - 💡(How to fix) Fix [FEATURE] Allow plugins to surface MCP servers in the Connectors UI panel [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Plugins can already surface MCP servers in a Connectors-style section today by declaring mcpServers in plugin.json. However, the UX is significantly weaker than what Anthropic first-party integrations (Slack, Figma, Linear) get. Three specific gaps:

1. No auth UI for plugin-declared MCPs. First-party connectors get connect/disconnect controls, OAuth flows, and auth status indicators. Plugin-declared MCPs just appear as running processes with no auth affordances — users can't tell if a connection is healthy, expired, or misconfigured.

2. No way to depend on or reuse first-party connector auth. If a user has already connected Figma via the first-party Anthropic OAuth, a plugin that needs Figma access can't piggyback on that session — it has to ship its own duplicate MCP with its own auth, creating two Figma entries in the toolkit.

3. Visual and functional asymmetry. First-party connectors live in a top-level Connectors section with rich UX; plugin MCPs live in a per-plugin subsection with minimal UX. They serve the same purpose but are treated as different classes of citizen.

Proposed Solution

Extend the plugin manifest with a connectors field that upgrades plugin-declared MCP entries with the same UX as first-party connectors (auth controls, status indicators) and optionally lets them reference existing first-party connectors instead of shipping a duplicate MCP:

{
  "connectors": [
    {
      "id": "figma",
      "name": "Figma",
      "description": "Read and write Figma designs",
      "mcpServer": "figma",
      "authType": "oauth" 
    }
  ]
}

Where mcpServer references a key in the plugin's mcpServers config. Claude Code would render these entries in the Connectors panel alongside first-party integrations, with the same connect/disconnect controls and auth status indicators.

Alternative Solutions

• In-plugin setup wizards — requires users to discover and run an onboarding command; no persistent connection status
• Documentation — doesn't solve the discoverability or status-visibility problem

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Why it matters

• Plugin users currently have no UI signal that a required MCP connection is missing — features silently fail at invocation time
• First-party and third-party integrations are treated asymmetrically despite serving the same purpose
• A connectors surface for plugins would make the ecosystem viable for tool-dependent workflows (design tools, project management, CI systems)