[Feature Request] MCP Server Grouping & Selective Tool Activation

[emretoprak]

Kiro Product

IDE

Feature Description

Feature Description

When multiple MCP servers are configured in Kiro, the total number of available tools grows rapidly. This triggers warnings like "too many tools" and can degrade agent performance and context efficiency.

Proposed solution: Allow users to organize MCP servers into named groups, and selectively activate a group per chat session.

---

Problem

• Adding several MCP servers quickly inflates the tool count (e.g., 5 servers × 10 tools = 50+ tools in context).
• Kiro already warns about excessive tool counts, which signals this is a real constraint.
• There is currently no way to scope which MCP tools are active for a given task or conversation.

---

Proposed Behavior

1. Group creation – Users can create named groups (e.g., "File Operations", "Database", "Web") and assign one or more MCP servers to each group.
2. Group activation in chat – When starting or during a chat, the user can specify which group(s) to use (e.g., #FileOperations), so only the tools from those servers are loaded into context.
3. Ungrouped servers – MCP servers that are not assigned to any group continue to work exactly as they do today (always active), preserving full backward compatibility.
4. Multiple groups – A user should be able to activate more than one group at a time if needed.

---

Example

Groups:
📁 File Operations → [filesystem-mcp, git-mcp]
🌐 Web → [browser-mcp, search-mcp]
🗄️ Database → [postgres-mcp]

Ungrouped (always active): [memory-mcp]

In chat: "Using the File Operations group, refactor all TypeScript files in /src"

---

Benefits

• Reduces tool count in context → fewer warnings, better agent focus.
• Gives users explicit control over what capabilities are available per task.
• Scales gracefully as the MCP ecosystem grows and users add more servers.

---

Additional Context

This is especially relevant for power users who rely on many MCP servers for different workflows (e.g., frontend work vs. backend work vs. DevOps tasks). Grouping would let them switch "tool profiles" without manually enabling/disabling servers each time.

Use Case

I work on multiple types of projects — frontend, backend, and DevOps. For each context I use different MCP servers. Right now, all of them are active at once, which floods the tool list and triggers "too many tools" warnings.

With grouping, I'd create a "File & Git" group for daily coding tasks and a "Database" group for data work. When I start a chat, I'd pick the relevant group so only those tools are in context — keeping the agent focused and avoiding the tool limit warnings.

Additional Context

No response

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #5863: Loading/unloading of MCP servers on-demand during a session (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues address MCP server management during sessions - the new issue proposes grouping and selective activation of MCP servers, while #5863 requests loading/unloading MCP servers on-demand. Both solve the same core problem of managing which MCP tools are active in a given context.

[github-actions]

Thank you for your feedback! 🙏

The 👎 reaction has been noted. The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[AnilMaktala]

We're doing a periodic backlog review and noticed this issue has been inactive for several months. Kiro has shipped a lot of changes since this was filed — we're now on IDE 1.0.309 and CLI 2.18.1 — and without any community uptake, we can't confidently prioritize it.

Closing to keep the backlog focused, but not as a dismissal. If you're still seeing this or others share the same experience, a new issue with your current version and any updated details would help us pick it back up. Issues with 👍 reactions from the community rise to the top fastest.