AWS Releases MCP Server to Turn IDE Prompts into Deployable Bedrock AgentCore Agents
What the AgentCore MCP server is
AWS has open-sourced a Model Context Protocol (MCP) server for Amazon Bedrock AgentCore that moves much of the integration and deployment work into the IDE assistant. The server exposes task-specific tools to MCP-capable clients and guides an assistant through the steps needed to convert a prompt-driven prototype into a deployable AgentCore Runtime agent.
How it works inside your IDE
The AgentCore MCP server presents the assistant with the right tools and documentation so the assistant can: convert entry points into AgentCore handlers, add bedrock_agentcore imports, generate dependency files such as requirements.txt, refactor direct calls into payload-based handlers compatible with Runtime, provision AWS environment resources (credentials, roles, ECR, config files), wire up the AgentCore Gateway for tool calls, and finally invoke and test the deployed agent — all from the IDE chat surface.
Supported MCP clients include Kiro, Claude Code, Cursor, the Amazon Q Developer CLI, and VS Code Q plugin. The server communicates via the standard mcp.json entry that these clients consume, and a lightweight launcher (uvx) provides a one-click install flow from the GitHub repo.
Installation and client support
AWS provides an easy install path from the awslabs mcp mono-repo (Apache-2.0). The repository contains the AgentCore server implementation and links to broader MCP resources and documentation. The expected mcp.json locations listed by AWS help MCP-capable clients find the server configuration, for example:
- Kiro: .kiro/settings/mcp.json
- Cursor: .cursor/mcp.json
- Amazon Q CLI: ~/.aws/amazonq/mcp.json
- Claude Code: ~/.claude/mcp.json
This uvx-based approach makes client hookup straightforward for developers who already use MCP-aware tools.
Architecture guidance and layered context
AWS recommends a layered context model for MCP servers so the IDE assistant receives progressively richer information: start with the agentic client context, add AWS documentation, layer in framework docs like Strands Agents or LangGraph, include AgentCore and agent-framework SDK docs, and apply per-IDE steering files to guide recurrent workflows. This layered arrangement reduces retrieval misses and keeps the assistant focused on a single end-to-end transform, deploy, and test loop.
Typical development workflow
A common path looks like this:
- Bootstrap: Use local tools or MCP servers. Provision a Lambda target for AgentCore Gateway or deploy directly to AgentCore Runtime.
- Author/Refactor: Start from existing Strands Agents or LangGraph code. The server instructs the assistant to convert handlers, imports, and dependencies for Runtime compatibility.
- Deploy: The assistant consults relevant docs and invokes the AgentCore CLI to deploy the agent.
- Test & Iterate: Invoke the agent via natural language, integrate Gateway tools if needed, redeploy (v2), and retest.
Why this matters
Many agent frameworks force developers to learn cloud-specific runtimes, role policies, registries, and deployment CLIs before they can iterate. By shifting much of that work into the IDE assistant, the MCP server narrows the prompt-to-production gap. Because it is an MCP server, it composes with existing document servers and benefits from improvements in MCP-aware clients, offering a low-friction path for teams standardizing on Bedrock AgentCore.
Community notes and resources
The server lives in the awslabs mcp mono-repo with Apache-2.0 licensing. The repo includes the AgentCore server, links to docs, and examples for installation. Community commentary highlights how the uvx mcp.json pattern simplifies client integration and how the server maps to AgentCore Runtime, Gateway, and memory stacks while preserving existing Strands and LangGraph code paths.
For full technical details and installation instructions see the AWS blog post and the GitHub repository linked by AWS.