I Connected Five MCP Servers to My IDE. My AI Agent Got Dumber

How Kiro Powers works with MCP Configuration

Series: Golden Jacket Field Notes (22 articles)

1
The Cheapest Price Per Token Can Be the Most Expensive Way to Run an LLM
…
5
I Connected Five MCP Servers to My IDE. My AI Agent Got Dumber This article
6
The Real Firewall Decision Happens in the Audit Room

Erick Mancz

AWS Golden Jacket | Co-founder Golden Jackets Brazil Community | 40 AWS Credentials

Published Jun 2, 2026

Last modified Jun 30, 2026

Disclaimer

Originally published on Medium as Week 4 of Golden Jacket Field Notes**
Canonical URL: https://medium.com/aws-tip/i-connected-five-mcp-servers-to-my-ide-my-ai-agent-got-dumber-92c2e658f487
This is a republication on AWS Builder Center for the AWS community. The piece below appeared first on Medium and is preserved here in its original form.

Golden Jacket Field Notes. Week 4.

Last month I was testing a development environment setup for a serverless project on AWS. Nothing exotic. Lambda functions, DynamoDB tables, a CDK stack, some CloudWatch alarms. The kind of thing I have done hundreds of times.

I had Kiro open with five MCP (Model Context Protocol) servers configured: AWS Documentation, CloudWatch, Aurora DSQL, a GitLab integration, and a Postgres connector. Each one doing its job. Each one exposing its own set of tools to the agent inside the IDE.

I typed a simple prompt. Something like “create a Lambda handler that reads from this DynamoDB table and publishes to SNS.” The kind of request that should take seconds.

The response was slow. And wrong. The agent tried to use a CloudWatch tool to query DynamoDB. It referenced a GitLab endpoint that had nothing to do with what I asked. It was confused in a way I had not seen before.

I closed three of the MCP servers. Same prompt. Fast, accurate, exactly what I needed.

That was the moment I realized that more tools can actually make an AI agent worse. And it forced me to understand something about MCP architecture that I had been ignoring.

Quick Clarification: MCP Is Not an Agent

Before going further, I need to set something straight because I see this confused constantly.

MCP is a protocol. It is not an agent, it is not a framework, and it does not run anything on its own. Anthropic built it internally, then open-sourced it in November 2024. A year later, in December 2025, they donated it to the newly formed Agentic AI Foundation under the Linux Foundation.

The architecture is client-server. The agent (living inside Kiro, Claude, Cursor, Bedrock AgentCore, or whatever host you use) is the client. The MCP server is an intermediary that exposes tools, resources, and prompts through a standardized interface. Under the hood it runs JSON-RPC 2.0. Local servers communicate via stdio, remote ones via HTTP.

You can build an MCP server with FastAPI, with the official Python or TypeScript SDK, or with anything that implements the protocol. The server is essentially a standardized wrapper that gives the agent structured, secure access to external capabilities. A database. An API. A documentation source. A monitoring system.

The agent decides when and which tool to call. The MCP server receives the request, executes the logic (a REST call, a SQL query, a documentation search), and returns the result.

It is a simple architecture with a powerful level of abstraction. And also the source of a problem that nobody warned me about.

The Context Overload Problem

Here is what happens when you connect multiple MCP servers to any IDE that supports the protocol.

At initialization, the IDE loads the tool definitions from every registered MCP server into the agent’s context window. Every single one. Before you type anything.

A typical MCP server exposes somewhere between 8 and 30 tools. The Figma server has 8 tools at around 12,000 tokens. Postman exposes 122 tools. AWS Observability bundles four separate MCP servers (CloudWatch, Application Signals, CloudTrail, and Documentation) with eight steering guides on top.

Connect five servers and you can easily end up with 100+ tool definitions consuming north of 50,000 tokens. Depending on the model you are using, that can be anywhere from 25% to 40% of your available context window, gone before your first prompt.

And here is the thing that the documentation does not spell out clearly. LLMs (Large Language Models) are not databases with indexed lookups. They do not scan a list of tools and pick the right one with surgical precision. They reason over everything in their context. More noise in the context means worse signal. The model has to parse through tool definitions for payment processing, design systems, database operations, and documentation search just to figure out that you want a simple Lambda handler.

It is the equivalent of walking into a hardware store and having every single employee from every department follow you around explaining their products while you are trying to buy a light bulb.

I have seen this pattern multiple times now. Teams start with one or two MCP servers, everything works great, they get excited, add three more, and suddenly the agent feels slower and less accurate. Nobody connects the dots because adding tools should make things better. Intuitively it makes sense. In practice, it does the opposite.

What Powers Actually Solves

This is where Kiro Powers enters and why I think the approach it takes is worth paying attention to.

A Power is not just an MCP server with a fancy name. It is a package that bundles three things together:

POWER.md is the steering file. Think of it as an instruction manual that tells the agent what tools this Power provides, when to use them, and what best practices to follow. It is the piece that gives the agent expertise, not just access.

MCP server configuration is the actual connection to external services. The tools, the endpoints, the authentication details.

Steering files and hooks (optional) are additional context and automation. Hooks trigger agent actions automatically when specific events happen in the IDE. Save a file, create a component, delete something. The agent responds without you asking.

But the real innovation is not the bundling. It is the loading strategy.

Powers do not load at initialization. They activate dynamically based on keywords in your conversation. You mention “payment” or “checkout” and the Stripe Power loads its tools and steering. You shift to database work and the Supabase Power activates while Stripe deactivates. Your baseline context usage with five installed Powers is close to zero until you actually need them.

This is a different approach entirely. Instead of dumping 50,000 tokens of tool definitions into context and hoping the model figures it out, Powers feed the agent only what is relevant to what you are doing right now.

I ran through this comparison myself. Same five capabilities (AWS docs, observability, database, design, API testing). With the traditional MCP setup, I noticed slower responses and the agent occasionally picked the wrong tool. With the same capabilities packaged as Powers, responses came back faster, tool selection was accurate, and the agent actually followed best practices from the steering files instead of just blindly calling API endpoints. Not a formal benchmark, but the difference was obvious enough that I stopped going back to the traditional setup.

Anatomy of a Real Power

Let me walk through what a Power actually looks like on disk, because I think this is where the abstraction becomes concrete.

Take the AWS SAM Power that launched on March 13. The official documentation shows that a Power follows this general structure:

1
2
3
4
5
my-power/
├── POWER.md
├── mcp.json
└── steering/
    └── workflow.md

The complexity varies. Some Powers keep everything inside POWER.md and skip the steering folder entirely. Others, like the Supabase Power, split guidance across multiple steering files so the agent only loads what is relevant to the current task.

The POWER.md file tells the agent: you have access to the SAM MCP server. Use it when the developer mentions serverless, Lambda, SAM templates, or deployment. Here are the patterns you should follow. Use Powertools for AWS Lambda by default for observability. Follow security best practices for IAM policies.

The mcp.json points to awslabs.aws-serverless-mcp-server and whatever additional servers the Power needs (in this case, a fetch server for pulling documentation).

The steering folder contains markdown files with opinionated guidance. Not just “here are the tools” but “here is how a senior engineer would use these tools.”

That last part matters more than people realize. Without steering, an agent can call Stripe APIs but does not know to use idempotent keys. It can query a Neon database but does not understand connection pooling for serverless. Access without expertise is just a faster way to build things wrong.

The Enterprise Angle

I want to touch on something that got announced on March 12 because it matters a lot more than it looks at first glance.

Kiro now has an MCP server registry where administrators can define an allow-list of approved MCP servers. You create a JSON file, host it on S3 or any HTTPS endpoint, and configure the URL in the Kiro admin console. Developers can only connect to servers that appear on that list.

On top of that, there are model governance controls that restrict which AI models developers can use. Both controls are enforced at the account level.

For anyone who has tried to roll out AI development tools in a regulated environment, you know why this matters. The conversation with security teams always stalls at the same question: “What can this tool connect to and who controls that?” Now there is an answer.

Combined with Powers, this starts to add up. An enterprise can curate a set of approved Powers, ensure they connect only to sanctioned MCP servers, and know that each Power carries steering files with organizational best practices baked in. The developer gets a one-click install. The security team gets a governance framework. That is a conversation I have not been able to have with most other AI tools.

What the Documentation Does Not Tell You

A few things I learned through trial and error that you will not find in the official docs:

Not all MCP servers are production quality. The ecosystem is exploding and that means a wide range of maturity. Partner Powers from Datadog, Stripe, Figma, and the AWS-maintained ones are well-tested. Community-built servers vary wildly. I have used some that were clearly someone’s weekend experiment wrapped in MCP. Always test in isolation before adding to your workflow.

Steering files are the competitive advantage, not the MCP connection. Anyone can wire up an MCP server. The teams that get the most value from Kiro are the ones writing good steering files. Coding standards, architectural patterns, team conventions. This is where institutional knowledge becomes agent knowledge. If you invest time in one thing, invest in your steering files.

Powers only work in Kiro IDE today. If you are on Kiro CLI, you configure MCP servers the traditional way. CLI support for Powers is on the roadmap but not here yet. This matters if you use both the IDE and CLI in your workflow.

Context summarization interacts with Power loading. When your conversation hits 80% of the context window, Kiro automatically summarizes previous messages. If a Power loaded early in a long conversation, the context that triggered it might get summarized away. I have had Powers deactivate unexpectedly during long sessions because of this. Shorter, focused sessions work better with the current implementation.

The keyword matching is not always obvious. Powers activate based on conversation keywords, but the matching logic is not fully transparent. I have had cases where I expected a Power to activate and it did not because I used slightly different terminology. Being explicit helps. “I need to work with Stripe payments” will trigger the Stripe Power more reliably than “I need to handle checkout.”

The Bigger Picture

Let me zoom out for a second.

If you read my Week 2 article about the AWS agentic stack, you know that MCP sits as the protocol layer that connects agents to tools. What Powers represent is the realization that a protocol alone is not enough. You also need a packaging and distribution model, a loading strategy that respects context limits, and a way to embed expertise alongside access.

This is not just a Kiro feature. It is an architectural pattern that I expect to see across the entire agentic ecosystem in the next twelve months. Anthropic is already moving in this direction with dynamic tool loading in Claude. Cursor has its rules files. But Kiro Powers is the most complete implementation I have seen of the idea that agent tools need to be context-aware, expertise-loaded, and dynamically managed.

For those of us designing solutions with agents, this matters. Do not hand your agent a Swiss Army knife with 100 blades and expect it to perform surgery. Give it the right tool, with the right guidance, at the right time.

Decision Tree

When should you care about this?

You are building with 1–2 MCP servers. You are fine. Traditional configuration works. Context overhead is manageable.

You are building with 3–5 MCP servers. Start watching your response quality. If you notice degradation, consider migrating to Powers.

You are building with 5+ MCP servers. You almost certainly have a context overload problem whether you have noticed it or not. Powers or a similar dynamic loading approach is not optional.

You are in an enterprise rolling out AI development tools. The governance features (MCP registry, model controls) should be part of your evaluation criteria. This is the kind of thing that gets AI tool adoption past the security review.

You are building custom MCP servers for your team. Package them as Powers from the start. Include steering files. Your future self will thank you.

The Takeaway

MCP solved the integration problem for AI agents. Every tool speaks the same protocol. That was a massive step forward.

But solving integration created a new problem: context management. More tools does not mean better agents. It means more noise for the model to reason through.

Kiro Powers is the best answer I have seen so far. Not because the bundling is clever (it is), but because it acknowledges a truth about LLMs that too many teams are still learning the hard way: these models work best when they have focused, relevant context. Not when they have all the context.

I spent almost fifteen years in cloud architecture. If there is one pattern that keeps repeating, it is this: every abstraction layer eventually needs its own management layer. VMs needed orchestration. Containers needed Kubernetes. Microservices needed service mesh. And now, MCP servers need Powers.

The tools that win are the ones that manage complexity instead of just adding to it.

This is part of the Golden Jacket Field Notes, a weekly series on AWS ML, GenAI, and cloud architecture from the field. If you found this useful, follow me for more practitioner insights that the documentation does not cover.

Erick Mancz is an AWS Solutions Architect holding Golden Jacket status (all active AWS certifications). He writes about agentic AI, cloud architecture at scale, and the patterns that emerge when you actually build things in production. Connect with him on Medium and LinkedIn .

# agentic-ai # agents # amazon-bedrock-agentcore # amazon-bedrock-agents # generative-ai