How I Used Kiro to Optimize Its Own MCP Configuration

Source: Dev.to

Problem Overview

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.

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

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.

1. Create a restore point

   /checkpoint init

   This creates a checkpoint I can roll back to if something goes wrong.
   Extra safety tip: initialize a git repo in ~/.kiro and commit before experimenting. That gives you a recovery path that works even if Kiro can’t start.

2. Prompt Kiro (run from ~/.kiro):

   “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.”

   The last sentence is important – I wanted a plan I could review, not immediate file edits.

What Kiro Proposed

Kiro analyzed my mcp.json, researched the Powers documentation online, and returned 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.

Logical Groupings (based on functionality)

Before

{
  "mcpServers": {
    "awslabs.aws-api-mcp-server": { ... },
    "aws-knowledge-mcp-server": { ... },
    "awslabs.aws-serverless-mcp-server": { ... },
    "bedrock-agentcore-mcp-server": { ... },
    "strands-agents": { ... },
    "email-calendar-mcp": { ... }
    // … 8 more …
  }
}

After – six Powers that load on‑demand based on keywords:

Key insight: the tools naturally cluster by workflow.

• When building AWS infrastructure, I need the CDK server and AWS docs, but not Playwright.
• When testing a web app, I need browser automation, but not architecture‑diagram tools.

The Conversation

After reviewing the plan, I approved it:

“I approve your plan, build it!”

Kiro then:

• Created the folder structure.
• Wrote POWER.md files with appropriate keywords and onboarding instructions.
• Configured a separate mcp.json for each Power.
• Added steering files with best practices.

Follow‑up questions & refinements

Each question refined the outcome. The AI handled the implementation; I steered the design. To do that, we both 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.

Example: aws-development Power

aws-development/
├── POWER.md
├── mcp.json
└── steering/
    ├── aws-api-workflows.md
    ├── serverless-patterns.md
    ├── cdk-best-practices.md
    └── architecture-diagrams.md

POWER.md frontmatter

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

Takeaways

• Group related MCP servers into Powers to reduce startup context size.
• Use keyword‑driven activation so only the needed tools load.
• Create checkpoints and backups before any bulk changes.
• Iterate with the AI – ask for a plan, review, approve, then let it implement.

By consolidating 14 individual MCP servers into 6 on‑demand Powers, I cut the initial token load dramatically, sped up responses, and made Kiro’s tool selection far more reliable. The same approach can be applied to any bloated Kiro configuration. Happy optimizing!

The Results

The main mcp.json is now nearly empty, containing only 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” → the AWS Development Power loads.
• Ask about “browser testing” → the Web Automation Power loads.

The interesting part isn’t just the specific optimization but the approach. I used Kiro to:

1. Analyze its own configuration.
2. Research documentation I wasn’t fully familiar with.
3. Propose a restructuring plan.
4. Discuss edge cases.
5. Implement changes across multiple files.
6. Verify the results.

Try It Yourself

If your MCP configuration has grown unwieldy, the same approach works:

1. Run /checkpoint init first (or use Git for a safety net that works even if Kiro can’t start).
2. Open the Kiro CLI in your ~/.kiro folder and ask it to analyze your mcp.json and propose groupings.
3. Review the plan, discuss any concerns, refine it, then approve and let it implement.
4. 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.
• 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.

1. Start with defaults.
2. Use the tools and notice friction.
3. Ask the AI to help reduce that friction.

Configuration files aren’t sacred; they’re just another part of a codebase that can be refactored and improved.