MCP stands for Model Context Protocol. An MCP server is a lightweight process that exposes tools, resources, and data to an AI agent — giving it the ability to interact with the outside world.
Without MCP, an AI model lives inside a conversation. It can read what you type and respond. That's it.
With an MCP server, the same model can query a database, read files from your filesystem, call an external API, execute code, search the web, check your calendar, and push commits to GitHub — all within a single conversation, autonomously, without you doing any of it manually.
MCP is the bridge between AI reasoning and real-world action. It is why the shift from AI chatbots to AI agents happened so fast in 2025-2026.
Why MCP exists
Before MCP, every team that wanted to connect an AI model to an external tool built their own integration. Different schemas, different transport formats, different authentication patterns. A company using three AI models and five internal tools needed fifteen custom integrations. Maintaining them as models updated was a recurring engineering tax.
Anthropic published the Model Context Protocol specification in November 2024 as an open standard. The goal: one protocol that any AI model can use to talk to any tool, regardless of who built either.
The analogy that actually works: MCP is to AI agents what USB is to peripherals. Before USB, every device had its own connector, its own driver, its own installation ritual. After USB, you plug it in and it works. MCP does the same thing for AI and tools — standardises the connection so the model and the tool don't need to know anything specific about each other.
How an MCP server works
An MCP server exposes three types of things to an AI model:
Tools — functions the model can call. A tool has a name, a description, and a JSON schema defining its inputs. When the model decides it needs to use a tool, it calls the tool with appropriate inputs and receives the result. Examples: query_database, read_file, send_email, create_github_issue, invoke_lambda.
Resources — data the model can read. Files, database records, API responses. Resources give the model access to context it wasn't trained on — your company's internal documentation, a customer's account history, the contents of a code repository.
Prompts — reusable prompt templates the server makes available to the model. Useful for standardising how the model approaches specific tasks within a particular domain.
The communication flow is straightforward:
User → AI model → MCP client → MCP server → external system
↓
User ← AI model ← MCP client ← tool result
- User asks the model to do something that requires an external tool
- The model identifies which MCP tool it needs and calls it with appropriate parameters
- The MCP client forwards the call to the MCP server
- The MCP server executes the tool — queries the database, reads the file, calls the API
- The result comes back to the model
- The model uses the result to continue its reasoning and respond to the user
MCP transport types
MCP servers communicate over two transport mechanisms:
stdio (Standard Input/Output) — the MCP server runs as a subprocess on the same machine as the client. Communication happens through stdin/stdout pipes. This is the standard for local MCP servers — Claude Desktop, Claude Code, and most developer tools use stdio for local MCP integration.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/aj/projects"]
}
}
}
HTTP with SSE (Server-Sent Events) — the MCP server runs as an HTTP service. The client connects over HTTP and receives events via SSE. This is the transport for remote MCP servers — servers running on cloud infrastructure, accessible from anywhere, handling multiple clients simultaneously.
{
"mcpServers": {
"production-tools": {
"url": "https://api.yourcompany.com/mcp",
"headers": {
"Authorization": "Bearer your-token"
}
}
}
}
The choice matters for architecture. Local stdio servers are simple to deploy and have no network latency. Remote HTTP servers enable shared tools across a team, centralised access control, and deployment on cloud infrastructure like AWS Lambda.
Building your first MCP server
Here is a minimal MCP server in Python that exposes one tool — querying an AWS DynamoDB table:
import json
import boto3
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
app = Server("dynamodb-tools")
dynamodb = boto3.resource("dynamodb", region_name="us-east-1")
@app.list_tools()
async def list_tools():
return [
Tool(
name="query_table",
description="Query a DynamoDB table by partition key. Returns matching items as JSON.",
inputSchema={
"type": "object",
"properties": {
"table_name": {
"type": "string",
"description": "The DynamoDB table name to query"
},
"partition_key": {
"type": "string",
"description": "The partition key attribute name"
},
"partition_value": {
"type": "string",
"description": "The partition key value to filter on"
}
},
"required": ["table_name", "partition_key", "partition_value"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "query_table":
table = dynamodb.Table(arguments["table_name"])
from boto3.dynamodb.conditions import Key
response = table.query(
KeyConditionExpression=Key(
arguments["partition_key"]
).eq(arguments["partition_value"])
)
return [TextContent(
type="text",
text=json.dumps(response["Items"], default=str)
)]
async def main():
async with stdio_server() as (read_stream, write_stream):
await app.run(read_stream, write_stream, app.create_initialization_options())
if __name__ == "__main__":
import asyncio
asyncio.run(main())
Install dependencies:
pip install mcp boto3
Add to Claude Desktop's claude_desktop_config.json:
{
"mcpServers": {
"dynamodb-tools": {
"command": "python",
"args": ["/path/to/your/server.py"]
}
}
}
Now Claude can query your DynamoDB tables directly from a conversation.
MCP on AWS Lambda — the production architecture
Local stdio servers work for development. Production deployments use AWS Lambda — serverless, auto-scaling, zero idle cost, accessible from Claude on Bedrock.
The architecture:
Claude on Bedrock
↓
API Gateway (HTTP endpoint)
↓
Lambda function (MCP server)
↓
DynamoDB / S3 / RDS / any AWS service
# lambda_handler.py — MCP server running on Lambda
import json
import boto3
from mcp.server import Server
from mcp.server.lambda_handler import create_lambda_handler
from mcp.types import Tool, TextContent
app = Server("production-tools")
@app.list_tools()
async def list_tools():
return [
Tool(
name="get_customer",
description="Retrieve customer record by ID from the production database.",
inputSchema={
"type": "object",
"properties": {
"customer_id": {
"type": "string",
"description": "The unique customer ID"
}
},
"required": ["customer_id"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "get_customer":
dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("customers")
response = table.get_item(Key={"customer_id": arguments["customer_id"]})
item = response.get("Item", {})
return [TextContent(type="text", text=json.dumps(item, default=str))]
handler = create_lambda_handler(app)
The IAM role for the Lambda function needs only the permissions required for the tools it exposes. If the server queries DynamoDB: dynamodb:GetItem and dynamodb:Query on the specific table. Nothing broader. This is the least-privilege principle applied to MCP tool access — the agent can only do what the Lambda role allows, regardless of what the model tries to call.
The security boundary MCP creates
MCP introduces a trust boundary that every engineer building agentic systems needs to understand.
The AI model decides which tools to call and with what parameters. The MCP server executes those calls. The model cannot directly access the underlying systems — it can only go through the tools the server exposes.
This boundary is where security controls live:
Tool schema as access control — the tools you define in your MCP server are the only operations available to the model. If you don't expose a delete_record tool, the model cannot delete records regardless of what it is instructed to do.
IAM as execution boundary — the AWS identity the MCP server runs as determines what it can actually do. A Lambda function with read-only IAM permissions cannot write data even if the tool implementation attempts it.
Input validation as injection defence — validate all inputs before passing them to downstream systems. A model can be manipulated into calling tools with adversarial inputs via prompt injection. Your server should reject inputs that don't match expected patterns before they reach your database or API.
This is why understanding MCP architecture is part of Domain 2 of the CCA-001 Claude Certified Architect exam — Tool Design and MCP Integration. The exam tests whether you can design MCP servers with appropriate security boundaries, not just whether you can make them work.
MCP servers AWS ships out of the box
AWS now ships official MCP servers for its core services. These are ready to use without building anything:
- Amazon S3 MCP — read, write, and list S3 objects from Claude
- Amazon DynamoDB MCP — query and scan DynamoDB tables
- AWS Lambda MCP — invoke Lambda functions directly from Claude Code
- Amazon SageMaker MCP — manage training jobs and endpoints
- Amazon Bedrock MCP — invoke foundation models, manage guardrails
- AWS CloudWatch MCP — query logs and metrics
- Amazon EC2 MCP — describe and manage EC2 instances
Install and configure any of these the same way as a custom server — add to your MCP client config and the tools become available immediately.
What MCP means for the engineer building on Claude
MCP is not optional knowledge for engineers building production AI systems in 2026. It is the standard integration layer for the entire Claude ecosystem — Claude Code uses it to connect to external tools, Bedrock agents use it to access enterprise data, and the Claude Partner Network ecosystem is built around MCP-compatible tooling.
The engineers who understand MCP architecture — how to design tool schemas, how to structure the security boundary, how to deploy MCP servers on Lambda, how to debug tool-calling failures — are the ones who can build production agentic systems that actually work reliably.
The StackHawks Pro track on Cloud Edventures has a dedicated MCP on AWS Lambda lab: building a production MCP server from scratch, deploying to Lambda behind API Gateway, connecting it to Claude on Bedrock, and testing the full tool-calling loop. Real AWS environment, automated validation, no billing risk.
The CCA-001 Claude Certified Architect certification covers MCP Integration in Domain 2 — 18% of the exam. Not as theory but as production architecture scenarios you have to solve correctly.
What are you connecting to Claude via MCP right now? Drop it in the comments.