[FEATURE] Allow plugins to surface MCP servers in the Connectors UI panel

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] 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.

1. 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.

1. 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)