⏱️ I Spent 6 Hours on AWS AgentCore for MCP IDE/CLI Integrations — So You Don’t Have To
After six hours of testing, here’s the bottom line:
AWS AgentCore is optimized for enterprise/production deployments, not local IDE/CLI dev/test loops.
If your workflow is in VS Code/GitHub Copilot, Claude Code, Kiro, or the OpenAI Codex CLI, local MCP servers will feel faster, simpler, and cheaper.
Quick Comparison ⚖️
Quick Comparison: Local MCP server Vs AgentCore Runtime
What Went Wrong (My Testing) ❌
Authentication Friction 🔐
In my testing, none of the IDEs or CLI tools — VS Code, Claude Code, Kiro, or Codex CLI — had a smooth handshake with AgentCore. Workarounds exist (auth proxies, helper services), but they add friction compared to local.
At one point, I found myself juggling multiple AWS console tabs just to keep things alive — though that reflects my workflow, not a strict requirement of AgentCore.
Not exactly developer-friendly.
Latency That Breaks Flow 🐢
In my environment, local MCP calls felt instant (<50ms), while AgentCore added ~100–300ms round-trips.
That doesn’t sound bad on paper. But when every hover, completion, agent request, or CLI call is delayed, it kills the dev flow.
Cost Doesn’t Match Use Case 💸
AgentCore’s pricing model makes sense for production agents serving users.
But for a developer running lightweight MCP calls inside an IDE or CLI, the baseline infra overhead felt like overkill.
Local? Free.
AgentCore? A bill for something slower and harder to use.
Why I Tried AgentCore 🤔
MCP (Model Context Protocol) is becoming the standard way to connect AI agents to external tools.
With IDEs like VS Code/GitHub Copilot, Claude Code, Kiro, and even the Codex CLI already integrating MCP, it felt natural to explore hosting our MCP server on the cloud.
In fact, I had already explored this path in an earlier post:
So trying AWS AgentCore runtime felt like the logical next step:
- Managed, isolated execution
- Built-in observability
- Scalable infra when needed
I expected it to just work across these IDEs and CLI tools.
Spoiler: it didn’t. (As of 2025–09 , AgentCore is still in preview.)
Before You Try AgentCore Runtime: What You’ll Need 🛠️
If you’re evaluating AgentCore Runtime for an MCP server, factor in these practical prerequisites (this is where most of my friction came from):
- Identity & Auth 🔑: Inbound requests are expected to be authenticated with OAuth/OIDC-style JWTs. Tokens are short-lived and need refresh. This is fine for web apps, but awkward for IDE/CLI clients (VS Code, Claude Code, Kiro, Codex CLI) unless you add a helper/proxy.
- Containerized Service 📦 : Your MCP server must run as a containerized service that exposes the required protocol endpoint (e.g., an MCP HTTP endpoint) and listens on the configured port.
- Permissions & Setup 📝: You’ll need to provision runtime configs, execution roles/permissions, logging/observability, and image registry access.
- Network & Endpoint Shape 🌐: Expect to align to the platform’s required endpoint shapes and headers; custom auth headers are not the happy path.
TL;DR: These are reasonable for enterprise agent apps, but they introduce friction for day-to-day IDE/CLI workflows.
Final Thoughts 💡
From my testing, AgentCore introduced more friction than value for IDE/CLI use. It’s optimized for enterprise scenarios, so for local dev/test loops, I found local MCP servers far smoother.
AgentCore will likely shine in enterprise contexts — but for IDE/CLI workflows, local remains the practical choice today.
👉 Have you tried AgentCore with MCP? Did you run into the same walls?
💬 Drop your experience in the comments — I’d love to compare notes.
👏 Give it a clap if this saved you time — so others won’t repeat my mistake!
If you’re new here, start with Part 1 of my journey — how I linked a legacy system to MCP, then Part 2 — how I added new tools with Codex. This AgentCore trial is Part 3: the cloud runtime experiment.