MCP AWS CloudFormation

Model Context Protocol (MCP) and AWS CloudFormation Stop hand-writing plumbing and start plugging in purpose-built connectors. When you want an LLM-based agent like Claude to interact with external systems — AWS, a database, or a monitoring platform — the usual pattern is to write glue: a few boto3 calls, error handling, pagination, and retries. That works until APIs change, your integration surface grows, or you add more services. Then the agent becomes a brittle mess of plumbing instead of a reasoning engine. The Model Context Protocol (MCP) solves this by moving integration logic out of the agent and into small, reusable servers. Instead of embedding AWS knowledge directly in your agent, you point the agent at an MCP server that already speaks AWS. Plug it in and the agent can call high-level, typed tools without you writing wrappers. Why this matters

Keeps the agent focused on reasoning and orchestration.
Lets integrations handle authentication, retries, and API shapes.
Makes it easy to add or replace external systems without changing agent code.

Example of the kind of glue code MCP avoids (illustrative only):

# example: direct boto3 usage (for illustration)
import boto3
from botocore.exceptions import ClientError

cfn = boto3.client("cloudformation")
try:
    response = cfn.list_stacks()
except ClientError:
    # implement retry logic here
    retry()

# boto3 returns native Python dicts; no manual json.loads is normally required.
# You still often need to handle pagination and error shapes.

Minimal local registration example (how you might tell the SDK to launch a server):

mcp_servers = {
    "cfn": {"command": "uvx", "args": ["awslabs.cfn-mcp-server"], "env": {}}
}

What is an MCP server? An MCP server is a separate process that exposes an external system as a set of typed, discoverable tools. Core principles:

One standard interface for every server so agents interact uniformly.
Each server runs as an independent process and may be implemented in any language.
Servers expose their tools at runtime; the agent discovers them automatically.
Add new capabilities by plugging in servers — no changes to the agent.

The server handles the messy details (auth, retries, parsing, pagination). The agent uses the clean tool surface to reason and orchestrate.

A presentation slide titled "One Server, Four Promises" describing a separate process that exposes an outside system as clean, structured tools. Four boxed points are shown: One Interface, External Process, Runtime Discovery, and Plug and Play, each with a brief explanation.

Registering MCP servers in ClaudeAgentOptions You declare MCP servers in a single ClaudeAgentOptions field named mcp_servers. Each key is the server name; the value describes how to launch it (command, args, env). The server name becomes the namespace prefix for all tools it provides. Important behaviors:

You never register individual tools. Once a server runs, the agent discovers its tools automatically.
The server name prefixes every tool: mcp__{server_name}__{tool_name}.

Naming convention and examples

Concept	Pattern	Example
Tool name format	`mcp__{server_name}__{tool_name}`	`mcp__cfn__list_resources`
Resource type example	—	`AWS::CloudFormation::Stack`
Whitelist all tools for a server	—	`["mcp__cfn__*"]`
Whitelist a single tool	—	`["mcp__cfn__list_resources"]`

Whitelisting (allowed_tools) enforces least privilege. You can allow all tools from a server with a wildcard or grant only specific operations for read-only jobs.

# Whitelist examples
allowed_tools = ["mcp__cfn__*"]
# or a single tool
allowed_tools = ["mcp__cfn__list_resources"]

Pointing Claude at AWS CloudFormation CloudFormation is AWS’s infrastructure-as-code service. Instead of a monolithic createStack tool, the AWS Labs CloudFormation MCP server models resources as typed entities and exposes focused operations such as:

list_resources
get_resource
get_resource_schema_information

Each operation expects a resource type to specify intent. Examples:

To list all stacks: call mcp__cfn__list_resources with resource type AWS::CloudFormation::Stack.
To inspect an S3 bucket: call mcp__cfn__get_resource with resource type AWS::S3::Bucket.

Because the MCP server returns structured errors and typed responses, the agent can interpret failures and present user-friendly explanations instead of raw stack traces. Example console run (trimmed):

$ python3 task_3_list_stacks.py
☒ uvx awslabs.cfn-mcp-server@latest → cfn server ready
☒ mcp__cfn__list_resources
resource_type: AWS::CloudFormation::Stack
→ mcp-demo-s3-stack-a1b9c CREATE_COMPLETE
→ mcp-test-s3-stack-7f2e0 CREATE_COMPLETE
☒ mcp__cfn__get_resource AWS::S3::Bucket
read-only – inspects, never changes

Architectural benefits

One agent can connect to many servers. Tools are namespaced by server name so there is no collision between different integrations.
Each server runs independently. A failure in one server does not bring down others.
To give the agent new capability, plug in a server and update the whitelist — no agent rewrite required.
Combine servers for complex workflows (e.g., compare a local CloudFormation template on a filesystem server with the live stack from the CloudFormation server).

A dark-themed diagram titled "One Agent, Many Servers" showing a Claude Agent SDK box connected to modules like "filesystem," "cfn," and "custom," which in turn link to targets labeled "Local files (/root/code)" and "AWS CloudFormation (Live stacks)." It illustrates an orchestrator agent using plugins/connectors to access different servers and resources.

Putting it all together With:

skills defining what Claude can do,
sub-agents defining who does the work,
and MCP defining where tools live,

you get a stable, extensible platform that can plan and deploy real infrastructure without embedding provider-specific plumbing inside the agent itself.

MCP shifts infrastructure integration out of the agent and into small, focused servers. That keeps agent code stable and lets you add or replace external integrations without touching the agent.

Links and references

AWS CloudFormation documentation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/
Model Context Protocol (MCP) pattern — architecting LLM agents with external tool servers
Example MCP server: awslabs CloudFormation MCP server (awslabs.cfn-mcp-server)

Foundations

Advanced Patterns

Capstone

MCP AWS CloudFormation

Watch Video

Practice Lab