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 fix itself.

The Self-Optimization Approach

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.

Before making any changes, I ran /checkpoint init in Kiro CLI. This creates a restore point I can roll back to if something goes wrong. For extra safety, you could also initialize a git repo in ~/.kiro and commit before experimenting. That gives you a recovery path that works even if Kiro can't start.

Here's what I typed into Kiro CLI, running in my ~/.kiro configuration folder:

"This is my Kiro configuration folder. Here I have too many MCP servers in the mcp config file. Can you help me group and transform those MCP servers into Kiro Powers? Research carefully how they work online and the details of their syntax and folder structure. Check that some MCP servers aren't already covered by existing or new powers to avoid duplication. Prepare a detailed plan and propose it to me before making any change to the code."

That last sentence is important. I didn't want Kiro to just start editing 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 also created a backup of the original config (mcp.json.backup) before making changes, a sensible precaution I didn't have to ask for.

It identified logical groupings based on functionality:

Before: 14 individual MCP servers, all loading at startup

{

  "mcpServers": {

    "awslabs.aws-api-mcp-server": { ... },

    "aws-knowledge-mcp-server": { ... },

    "awslabs.aws-serverless-mcp-server": { ... },

    "bedrock-agentcore-mcp-server": { ... },

    "strands-agents": { ... },

    "email-calendar-mcp": { ... },

    ...

  }

}

After: 6 Powers that load on-demand based on keywords. The aws-development Power bundles AWS API, documentation, serverless, CDK, and diagram tools. web-development handles frontend frameworks. web-research-browse-test combines Fetch and Playwright for web automation. agentic-ai groups Bedrock AgentCore and Strands Agents SDK. office-tools covers email and calendar. And amazon-aurora-dsql already existed as a Power.

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. But that's not the full story.

The Conversation

After reviewing the plan, I approved it: "I approve your plan, build it!"

Kiro created the folder structure, wrote the POWER.md files with appropriate keywords and onboarding instructions, configured the separate mcp.json for each Power, and added steering files with best practices.

But I had follow-up questions.

"Did you remove the original MCP servers from the main mcp config file? How many are left there?" Kiro confirmed the cleanup.

"Can't these be grouped into an agentic AI power?" This led to consolidating the Bedrock AgentCore and Strands servers into a single Power.

"What happens if I trigger both web research and web dev powers? Would Playwright be included twice?" Kiro explained that Powers are namespaced to prevent conflicts. But this question led to a better design: a dedicated "web-research-browse-test" Power that combines fetch and Playwright, separate from frontend development.

Each question refined the outcome. The AI handled the implementation; I steered the design. To do that, we both (Kiro and I) needed to know what a Kiro Power is.

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.

The Results

The main mcp.json is now nearly empty, just the Powers section referencing installed Powers. No servers load until needed, which means faster startup.

Context pollution is gone. When I'm working on a web frontend, I don't have email and calendar tools cluttering the context. The AI makes better tool choices because it has fewer, more relevant options.

Powers activate based on keywords in the conversation. Ask about "CDK stacks" and the AWS Development Power loads. Ask about "browser testing" and the web automation Power loads.

The interesting part is not only the specific optimization but the approach. I used Kiro to analyze its own configuration, research documentation I wasn't fully familiar with, propose a restructuring plan, discuss edge cases, implement changes across multiple files, and verify the results.

Try It Yourself

If your MCP configuration has grown unwieldy, the same approach works. Run /checkpoint init first (or use git for a safety net that works even if Kiro can't start). Open Kiro CLI in your ~/.kiro folder and ask it to analyze your mcp.json and propose groupings. Review the plan, discuss any concerns, refine it, then approve and let it implement. Test that keywords trigger the right Powers.

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. The system improved its own configuration based on how I actually use it. And it took 15 minutes.

The same pattern applies beyond MCP setups: treat your AI tooling configuration as something that evolves. Self-optimization is a new pattern. 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.