I had a problem. My Kiro setup had accumulated 14 MCP servers over time: AWS tools, web automation, documentation servers, email integration. That's dozens of tools, all loading into context at the start of every conversation, whether I needed them or not.
This is the hidden cost of extensibility. MCP servers give AI assistants access to external tools and services. Powerful, but each one adds to the context window. More tools means more tokens consumed before you ask your first question, slower responses, and an AI that sometimes picks the wrong tool because it has too many options.
So I asked Kiro to help me build a better solution.
Using Kiro CLI to Create Powers
Kiro Powers are the solution to MCP sprawl. They're self-contained packages that bundle MCP servers with documentation and best practices, loading on-demand based on keywords in your conversation. But here's the thing: while Powers currently only work in Kiro IDE (CLI support is coming), Kiro CLI is excellent at creating them. So I used the CLI to analyze my MCP configuration and generate properly structured Power folders, then added them to Kiro IDE.
Getting Started
I used Kiro CLI with the Auto model, the default mode that blends frontier models with specialized ones for different tasks. For this kind of work (analyzing config files, researching documentation, generating structured output), Auto picks the right model for each step rather than using a single expensive model for everything.
First, I copied my mcp.json from ~/.kiro/settings/ to a working folder:
mkdir ~/optimize-powers
cp ~/.kiro/settings/mcp.json ~/optimize-powers/
cd ~/optimize-powers
Then I launched Kiro CLI in that folder and gave it this prompt:
"I have an mcp.json file with too many MCP servers. Help me group and transform them into Kiro Powers. Research carefully how Powers work online, including the folder structure and POWER.md frontmatter syntax. For each logical grouping, create a folder with the correct structure: POWER.md with proper frontmatter (name, displayName, description, keywords, mcpServers), an mcp.json with the server configurations, and a steering/ folder with best practices. Prepare a detailed plan and propose it to me before creating any folders."
That last sentence is important. I didn't want Kiro to just start creating files. I wanted a plan I could review and discuss.
What Kiro Proposed
Kiro analyzed my mcp.json, researched the Powers documentation online, and came back with a consolidation plan. It identified logical groupings based on functionality:
Before: 14 individual MCP servers, all loading at startup
After: 7 Powers that load on-demand based on keywords:
- aws-development bundles AWS API, documentation, serverless, CDK, and diagram tools
- web-development handles frontend frameworks and Playwright for testing
- web-research uses Fetch for browsing documentation
- bedrock-agentcore for agent production and deployment
- strands-agents for agent development with the Strands SDK
- office-tools covers email and calendar
- amazon-aurora-dsql for database-specific workflows
The key insight: these tools naturally cluster by workflow. When I'm building AWS infrastructure, I need the CDK server and AWS documentation, but not Playwright. When I'm testing a web app, I need browser automation, but not the architecture diagram tools.
The Conversation
After reviewing the plan, I had follow-up questions.
"Can't Bedrock AgentCore and Strands be grouped into a single agentic AI power?" This led to consolidating them. Both are about building AI agents, just at different stages of the workflow.
"What if I want to use Playwright for web browsing too, not just testing? Would it be duplicated across powers?" Kiro explained that Powers are namespaced to prevent conflicts, but this led to a better design for my workflows: consolidating into a single "web-research-browse-test" Power that combines Fetch and Playwright for both browsing and testing, separate from frontend development.
Each question refined the outcome. The AI handled the implementation; I steered the design. The final result: 6 Powers instead of 14 scattered MCP servers.
After finalizing the plan, I approved it: "I approve your plan, build it!"
Kiro created the folder structure for each Power, wrote the POWER.md files with appropriate keywords and onboarding instructions, configured the mcp.json for each Power, and added steering files with best practices.
What a Kiro Power Looks Like
A Kiro Power is a self-contained package: documentation, best practices, and its own MCP server configuration bundled together. When the Power activates, its MCP servers become available. When it's not needed, they stay out of context.
Here's the AWS Development Power that Kiro created:
aws-development/
├── POWER.md
├── mcp.json
└── steering/
├── aws-api-workflows.md
├── serverless-patterns.md
├── cdk-best-practices.md
└── architecture-diagrams.md
The POWER.md frontmatter defines when the Power activates:
---
name: "aws-development"
displayName: "AWS Development"
description: "Comprehensive AWS development toolkit..."
keywords: ["aws", "cloud", "serverless", "lambda", "cdk",
"cloudformation", "infrastructure", "api",
"documentation", "diagrams"]
mcpServers: ["aws-api", "aws-knowledge", "aws-serverless",
"aws-diagram", "aws-cdk"]
---
The keywords array is the trigger mechanism. When Kiro sees any of these words in your conversation, it loads this Power automatically. The keyword matching is simple but effective: use words that match how you naturally talk about the workflow.
Adding Powers to Kiro IDE
Once Kiro CLI created the Power folders, I added them to Kiro IDE one at a time. In the Powers panel, I clicked "Add power from Local Path" and selected the directory containing the POWER.md file (e.g., ~/optimize-powers/aws-development/). Each Power appeared in the IDE's Powers list and activates automatically when I use its keywords in conversation.
The Results
The difference is immediate. When I'm working on a web frontend, I don't have AWS and email tools cluttering the context. The AI makes better tool choices because it has fewer, more relevant options. Ask about "CDK stacks" and the AWS Development Power loads. Ask about "browser testing" and the web automation Power loads.
What's interesting is the approach itself. I used Kiro CLI to analyze a configuration, research documentation I wasn't fully familiar with, propose a restructuring plan, discuss edge cases, and implement the folder structures. Then Kiro IDE activated them.
Try It Yourself
If your MCP configuration has grown unwieldy, the same approach works. Copy your mcp.json to a working folder, open Kiro CLI there, and ask it to analyze your servers and propose groupings. Review the plan, discuss any concerns, refine it, then approve and let it create the Power folders. Finally, add each Power to Kiro IDE through the Powers panel.
Powers don't require MCP servers. You can create documentation-only Powers with steering files for specific frameworks or patterns. And they're portable: push to a GitHub repo and others can install them. The community Powers repository has examples from Datadog, Figma, Stripe, and others.
If you haven't tried Kiro yet, you can get started for free.
What This Opens Up
I used an AI tool to restructure how that same AI tool accesses its capabilities. Kiro CLI analyzed the configuration, researched documentation, and generated the folder structures. Kiro IDE then activated them. The whole process took about 15 minutes.
The same pattern applies beyond MCP setups: treat your AI tooling configuration as something that evolves. Start with defaults, use the tools, notice friction, then ask the AI to help reduce it. The configuration files aren't sacred. They're just another part of a codebase that can be refactored and improved. And once Powers come to the CLI, this workflow will get even simpler.
Top comments (0)