re:Invent 2025 - Accelerate building Serverless apps with Kiro and MCP servers

Building a production-ready serverless backend involves selecting the right AWS services, writing infrastructure as code, configuring integrations, and running tests, all before you ship a single line of business logic. In this session from re:Invent 2025, Sean Kendall, Principal Solutions Architect at AWS, and Brian Zambrano, Senior Deep Learning Architect at AWS, demonstrate how combining Amazon Kiro with Model Context Protocol (MCP) servers lets you hand that entire workflow to an AI agent. In this post, we'll walk through how Kiro works, which MCP servers matter most for serverless development, and the configuration and prompt engineering techniques that make the results reliable.

What is Amazon Kiro?

Kiro is an agentic AI coding tool that lets you type a prompt, hit Enter, and walk away while it builds and deploys an application on your behalf. Behind the scenes it uses Anthropic's Claude models with a routing system that selects the best model for each task, though you can specify an exact model if you prefer.

Kiro comes in two forms. The Kiro CLI lets you open a terminal, type a prompt, and walk away. Sean described his personal workflow: write a prompt before bed, run it with the --allow flag that grants the agent permission to execute any command without pausing, and wake up to a deployed application. This works well for personal or demo environments, but in an AWS account where a runaway command could cause real damage, you should keep the per-command permission prompts enabled. The Kiro IDE is a fork of VS Code that wraps the same agent in a graphical interface, adding features like agent steering documents and a "Refine" button that automatically improves those documents based on your existing project code.

One practical advantage of both the CLI and IDE is that all agent settings, including MCP server definitions, live inside a .kiro directory in the project. Committing that directory to source control gives every developer on the team the same agent configuration without any manual setup on each machine.

MCP Servers: Giving the Agent Current Knowledge and Actions

The models inside Kiro were trained on data up to a specific cutoff date. Any AWS service launched or updated after that date is unknown to the model unless you supply that context from outside. Model Context Protocol (MCP) servers are the standard mechanism for doing that. Think of an MCP server as a bridge that connects your coding agent to a backend system, giving it access to real-time information, the ability to run commands in your environment, or the ability to call an external API. Because MCP is an open protocol, any system can expose an MCP interface and any compatible agent can connect to it. Many SaaS vendors are now publishing MCP servers for their own products alongside their traditional APIs.

For this session, Sean and Brian drew from a set of AWS-maintained servers available in the AWS Labs MCP repository. The AWS Documentation MCP Server gave the agent access to current service documentation, limits, and APIs, which is especially useful at re:Invent when new features are announced and published before the underlying models have any training data about them. The AWS Serverless MCP Server understands AWS SAM (Serverless Application Model) and its CLI, including how to build, test locally, and deploy. This server can execute those commands directly in your environment, so the agent does not have to infer the right syntax from training data alone.

The AWS CDK MCP Server is the right choice when you want infrastructure written in Python using the AWS Cloud Development Kit. A notable built-in behavior of this server is that it automatically introduces CDK Nag into the project, which enforces security rules at build time and fails the build if the infrastructure does not meet its standards. When the agent decides a control is unnecessary for a demo, it adds an explicit suppression that you can review and remove if you want the control reinstated. This is a practical counterweight to the tendency of AI code generation to favor convenient shortcuts over secure defaults. The AWS Core MCP Server rounds out the setup with a prompt-understanding layer that reformulates your input into better-structured prompts for AWS development, and a routing mechanism that loads additional servers automatically based on a developer or architect persona you specify.

One important consideration on server selection: more is not better. Each server registers its available tools into the model's context window, and the more tools present, the harder it becomes for the model to select the right one at each step. Sean's recommendation was to be deliberate and add only the servers relevant to the specific project you are working on.

Prompt Engineering, Steering Documents, and the Five-Minute Build

A well-structured prompt changes outcomes more than most people expect when they first start working with agents. Sean's prompt for the session illustrates this clearly. He told the agent to build and deploy without stopping to ask for confirmation, because his preferred workflow is to run prompts unattended. He gave it the direct URL of the front-end's OpenAPI spec and instructed it to use the Fetch MCP server to retrieve it, so the backend would exactly match the published contract rather than guessing at the API shape. He named his default AWS account as the deployment target (without this, the agent would pause and ask), requested post-deployment API tests, explicit Cross-Origin Resource Sharing (CORS) header handling, and resource tagging with a project name. At the bottom of the prompt, he added specific instructions for failure modes he had identified in earlier runs of the same application.

The practical lesson here is to treat your prompts as living documents rather than one-off inputs. When the agent fails on something consistently, add an instruction that directly addresses it. Over time, your prompts become more reliable for the kinds of applications you build. Sean noted that CORS headers remain the most common failure point even when explicitly requested: the agent skipped that instruction in several test runs on the morning of the session, which illustrates why iterating on prompts matters even when you think you have covered a known issue.

Steering documents serve a similar purpose at the project level. In the Kiro IDE, these are Markdown files stored in the .kiro directory that the agent reads before every task. Brian created two for the demo: one describing the project structure and the SAM commands to build, deploy, and sync changes; another with product-level instructions covering CORS handling and how to install AWS Lambda Powertools as a Lambda layer rather than bundling it into the deployment package. Brian also learned from experience to include explicit instructions about what not to build. Without clear scope boundaries, agents tend to generate unit tests, integration tests, and additional scaffolding that adds noise to a prototype. Adding "I do not need unit tests or integration tests" kept the output focused.

To demonstrate all of this together, Sean and Brian built the backend for a TicTacToe game starting from an empty directory. The front-end was already deployed and exposed an OpenAPI spec at a public URL. Sean submitted his prompt to the Kiro CLI and Brian pasted a shorter prompt into the Kiro IDE. Both backends were deployed in approximately five minutes, each producing a working Amazon API Gateway setup connected to AWS Lambda functions backed by an Amazon DynamoDB table, with the full infrastructure captured in a SAM template. The first test on Sean's backend returned a validation error. He pasted the error message directly into the CLI with no additional context, and the agent identified the cause, corrected the function, and redeployed. Brian's backend had a CORS issue that required a second pass. Both were resolved in under a minute of agent work.

Conclusion

Building serverless applications with Kiro and MCP servers is not about removing judgment from the development process. It is about compressing the time between an idea and a deployed, testable backend so you can apply your judgment at the right moment. The techniques in this session, curating MCP servers to match your stack, writing prompts that account for your known failure modes, and using steering documents to encode project conventions and scope boundaries, are what separate an agent that needs constant correction from one that produces something usable on the first or second run.

To get started, explore the full library of AWS-maintained MCP servers in the AWS Labs MCP repository, install the Kiro CLI or IDE, and start with a small serverless project before applying these patterns to production workloads.

Watch the full session: Accelerate building Serverless apps with Kiro and MCP servers (CNS373)