[FEATURE] Unified panel for MCP tools, skills, and plugins (too many names, too many locations)

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

Problem

In Claude Desktop, tools and instructions are spread across multiple settings pages and views, all with different labels, even when they describe the same underlying concept. code.claude
As someone who builds custom MCP servers and skills, this makes the mental model and the UI much harder than it needs to be. code.claude

***

Current layout

Claude Desktop Settings
├── General → language, theme…
├── Extensions → “plugins” / “connectors” (= pre‑packaged MCP servers) claude
├── Capabilities
│ ├── Artifacts → files/code generated by Claude
│ ├── Memory → what Claude remembers across sessions
│ └── Skills → .md instruction files support.claude
└── Developer → MCP servers (manual JSON config) support.claude

Code tab (sidebar)
└── Plugins → another place to install MCP‑like integrations / project plugins code.claude

Cowork tab
└── Plugins → “Browse plugins”, ready‑to‑use workflows that bundle tools and company‑specific logic claude

***

Naming confusion

Concept 1 — Tools (callable functions / integrations)

• “MCP server”: installed manually in Developer via JSON config. support.claude
• “Plugin”: pre‑packaged, often one‑click install (Extensions, Code sidebar, Cowork). claude
• “Extension”: sometimes used for the same thing as “plugin” in Desktop docs. [anthropic](https://www.anthropic.com/engineering/desktop-extensions)
• “Connector”: subset of plugins/extensions for specific external services. claude

All of these effectively represent “things Claude can call”.

Concept 2 — Instructions (claude.md / .md skills)

• “Skill”: label in the UI for .md instructions that define how Claude should use tools, follow processes, or behave in certain contexts. code.claude

Concept 3 — Containers / menus

• “Capabilities”: menu grouping Skills + Artifacts + Memory, mixing tool instructions with core model features. code.claude
• Multiple “Plugins” sections: appear in Code, Cowork, and Desktop, each with slightly different scope and behavior. claudecn

End result: 4+ names for “tools”, managed from at least 4 different locations, with unclear global vs project vs workspace scope. support.claude

***

### Optional improvement: reusable groups per project/conversation

Another powerful addition would be the ability to define groups that bundle specific MCP tools and skills together, and then reuse those groups across chats, Projects, Claude Code, and Cowork.[web:5][web:54][web:58][web:61]

Key ideas:

• I can define multiple named groups (e.g. “Dental‑practice automations”, “GitHub triage”, “Data analysis”, etc.).
• For any chat / Project / Cowork run / Code workspace, I can:
• pick one or more groups to activate together for that context, and
• have a set of global tools/skills that are always enabled everywhere (general utilities, safety/guardrail skills, etc.).[web:51][web:56][web:60]

Examples:

• A “Dental‑practice automations” group with:
• Desktop/file MCP for local documents
• A few third‑party connectors (calendar, practice management, etc.)
• Domain‑specific skills describing workflows and billing rules

• A “GitHub triage” group with:
• GitHub MCP + issue/PR skills
• Notification skills/connectors (Slack, email, etc.)[web:51][web:56]

Ideally, I could:

• Define and name these groups once in the unified “Tools & Instructions” manager.
• Choose which combination of groups to activate:
• when creating or opening a Project,
• when starting a chat,
• when launching a Cowork task,
• or when working in Claude Code on a repository.[web:54][web:58][web:60][web:61]

This would let me say “use <group-A> + <group-B> for this conversation” while always keeping my global tools available, without manually toggling individual MCPs and skills every time I switch context.

### Proposed Solution

### Proposed solution: One “Tools & Instructions” manager

Replace these with a single unified panel:

- Settings → Extensions  
- Settings → Capabilities → Skills  
- Settings → Developer (MCP config)  
- Code tab → Plugins  
- Cowork → Plugins

**Mockup:**

```text
┌──────────────────────────────────────────────────────────────────────┐
│                    Tools & Instructions Manager                      │
├──────────────┬───────────────┬────────────────┬──────────────────────┤
│ Name         │ MCP Tools     │ Instructions   │ Bundle (store)       │
├──────────────┼───────────────┼────────────────┼──────────────────────┤
│ wordpressmcp │ ON  [config]  │ ON  [edit]     │                      │
│ notebooklm   │ ON  [config]  │                │                      │
│ github       │               │                │ ON  [store]          │
│ slack        │               │                │ ON  [store]          │
│ my-skill     │               │ ON  [edit]     │                      │
└──────────────────────────────────────────────────────────────────────┘
                                  [ + Add MCP ] [ + Add Skill ]

• Column 1 — Name: unique identifier for the integration / skill / bundle.
• Column 2 — MCP Tools: MCP servers and other callable tools. Toggle ON/OFF, click for config (endpoints, auth, scopes…).
• Column 3 — Instructions: associated .md skill / claude.md file. Toggle ON/OFF, click to edit inline. support.claude
• Column 4 — Bundle (store): pre‑packaged “plugin” entries from the marketplace (MCP + Skills + settings, as a bundle). code.claude

A row can have only MCP tools (pure integration), only Instructions (pure skill), both (custom pairing), or a store bundle that is just a preset combination of the above. claude

***

Optional improvement: filters and scopes

In a unified “Tools & Instructions” table, filters and tags would make it easy to understand what each entry does and where it runs. [support.anthropic](https://support.anthropic.com/en/articles/11724452-browsing-and-connecting-to-tools-from-the-directory)

Examples of useful filters/tags:

• Third‑party connectors: tools that connect to external SaaS or APIs (Notion, Slack, Stripe, etc.). support.claude
• Desktop extensions: tools that act on the local machine (filesystem, apps, OS automation). support.claude
• Browser / web automation: tools that control or read from the browser (via browser MCP, Chrome extension, etc.). tactiq
• Private vs shared: tools/skills that are private to me vs shared with my team/workspace. youtube

With a single manager plus filters, I could, for example, show only “desktop” tools when debugging local automation, or only “third‑party connectors” when reviewing security and external data access. support.anthropic

***

Why this matters

• Single mental model: “Tools” (things Claude can call) vs “Instructions” (how Claude should use them), instead of MCP vs plugins vs connectors vs extensions vs skills. anthropic
• One screen instead of 4+ places (Developer, Extensions, Capabilities → Skills, Code → Plugins, Cowork → Plugins). support.claude
• Clear visual link between an MCP server and the skill(s) that orchestrate it. code.claude
• Store entries are explicitly shown as bundles (MCP + Instructions + config), instead of feeling like a separate category of “magic plugins”. claude
• Easier to reason about scope: a unified panel can clearly surface global vs workspace vs project‑local activation and visibility. reworked

***

Current pain points

• When I build a custom MCP server, I configure it in Developer, then separately upload a skill under Capabilities → Skills, and there is no single place where I can see “this skill uses this MCP server”. support.claude
• “Plugin”, “Extension” and “Connector” all effectively map to MCP‑based integrations, but are surfaced in different UI sections with different labels. anthropic
• Skills live under “Capabilities” next to Artifacts and Memory, which are core model features, not extension mechanisms, mixing instruction authoring with system‑level capabilities. code.claude
• Frontmatter / config rules for skills differ between Claude Code and Claude Desktop, and the distinction is not obvious in the UI when you’re just “adding a skill”. claudecn
• MCP servers and plugins can be installed from Developer, Extensions, Code sidebar, and Cowork plugins, and it’s not clear which ones are global, which ones are project‑local, and how they relate. reworked

A unified “Tools & Instructions” manager that spans Desktop, Code and Cowork would make it much easier to understand, debug, and share setups, especially for users who actively build MCP servers and complex skills. claude

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_