5 MCP Tools That Replaced My AWS Console — How I Operate Multi-Account from the Terminal
I built 5 lightweight MCP tools that let me manage CloudFront, Cognito, SNS, and CloudWatch across multiple accounts using natural language — no console, no memorized CLI flags, ~45 minutes saved daily.
5 MCP Tools That Replaced My AWS Console — How I Operate Multi-Account from the Terminal
By Ricardo Gulias | June 2026
I manage infrastructure across multiple AWS accounts daily. CloudFront distributions, Cognito user pools, DynamoDB tables, SNS topics, S3 buckets — scattered across accounts and regions.
Two weeks ago I stopped opening the AWS console for operational tasks. Here's what replaced it.
The Problem: Too Many Clicks, Too Much Context Switching
If you operate AWS at any scale, you know the drill:
- Open console
- Switch to the right account
- Navigate to the right service
- Find the right resource
- Perform the action
- Repeat for the next account
For a single operation, that's fine. For 10-15 ad-hoc operations per day across multiple accounts, it's death by a thousand clicks.
AWS CLI helps — but requires remembering exact resource IDs, ARNs, and flags.
aws cloudfront create-invalidation --distribution-id E2O44PV... --paths "/*" — which distribution was that again?The Solution: MCP Tools + Natural Language
MCP (Model Context Protocol) is an open standard that lets AI assistants call external tools through a structured interface. Instead of memorizing CLI syntax, you describe what you want in plain language — and the right tool fires with the right parameters.
I built 5 MCP tools that cover 80% of my daily AWS operations:
Tool 1: check-status — Multi-Account Health in 3 Seconds
Before: Open CloudFront console → switch account → check status → repeat for each distribution.
Now: "What's the status of all my distributions?"
Returns health for every CloudFront distribution I manage in one response. Green or broken — instant.
1
2
3
4
5
{
"name": "check-status",
"description": "Check CloudFront and S3 health across all managed accounts",
"inputSchema": { "type": "object", "properties": {} }
}Time saved: ~5 minutes per check × 3 checks/day = 15 min/day
Tool 2: invalidate-cache — No More Distribution ID Hunting
Before: Find the right CloudFront distribution ID (was it E3N44... or E174X...?), construct the CLI command, run it, verify.
Now: "Invalidate the cache for the production site"
The mapping between human-friendly names and AWS resource IDs lives in the server. I never type a distribution ID again.
1
2
3
4
5
6
7
8
9
10
{
"name": "invalidate-cache",
"description": "Invalidate CloudFront cache for a specific site",
"inputSchema": {
"type": "object",
"properties": {
"site": { "type": "string", "description": "Site name" }
}
}
}Time saved: ~3 minutes per invalidation × 2/day = 6 min/day
Tool 3: list-users — Identity Management Without the Console
Before: Cognito console → User Pools → select pool → Users tab → filter → page through results.
Now: "List confirmed users in the production pool"
Returns name, email, status, creation date. Filterable by group, status, or date range.
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "list-users",
"description": "List Cognito users with optional filters",
"inputSchema": {
"type": "object",
"properties": {
"pool": { "type": "string" },
"group": { "type": "string" },
"status": { "type": "string" }
}
}
}Time saved: ~4 minutes per lookup × 3/day = 12 min/day
Tool 4: send-notification — Alerts Without Opening SNS
Before: SNS console → Topics → select topic → Publish message → fill form → publish.
Now: "Send a notification about the deployment to the ops topic"
One sentence. Message formatted, topic resolved, published.
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"name": "send-notification",
"description": "Publish message to SNS topic",
"inputSchema": {
"type": "object",
"properties": {
"topic": { "type": "string" },
"subject": { "type": "string" },
"message": { "type": "string" }
},
"required": ["topic", "message"]
}
}Time saved: ~2 minutes per notification × 2/day = 4 min/day
Tool 5: query-metrics — Quick Answers Without CloudWatch Dashboards
Before: CloudWatch → Metrics → find namespace → find metric → set time range → wait for graph.
Now: "How many invocations did the auth function have today?"
Returns the number. No graph needed for a quick check.
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "query-metrics",
"description": "Query CloudWatch metric for a resource",
"inputSchema": {
"type": "object",
"properties": {
"function": { "type": "string" },
"metric": { "type": "string" },
"period": { "type": "string", "default": "today" }
}
}
}Time saved: ~3 minutes per query × 4/day = 12 min/day
Total Impact
| Metric | Before | After |
|---|---|---|
| Console sessions/day | 10-15 | 0-2 |
| Time on ad-hoc ops | ~50 min/day | ~5 min/day |
| Wrong-account mistakes | 1-2/week | 0 |
| Context switches | Constant | Near-zero |
That's ~45 minutes/day returned to actual work. Not life-changing individually, but compounded over weeks it's significant.
How It Works Under the Hood
The entire setup is a Python script (~150 lines) that:
- Reads commands via stdin (JSON-RPC 2.0)
- Routes to the right function based on tool name
- Calls boto3 with the right parameters
- Returns results as structured JSON
No framework. No Lambda. No deployment pipeline. Just a file on my machine that starts when I open my terminal.
1
2
3
4
5
6
7
Terminal (Kiro CLI)
↓ natural language
AI Agent (decides which tool)
↓ JSON-RPC
MCP Server (local Python, boto3)
↓ API calls
AWS Services (CloudFront, Cognito, SNS, CloudWatch)Configuration is one JSON file pointing to the script with an AWS profile that has scoped IAM permissions.
Why MCP Over Bash Scripts or Aliases?
I've had aliases and scripts for years. The difference:
| Scripts/Aliases | MCP Tools | |
|---|---|---|
| Discovery | You remember they exist | Agent finds the right one |
| Parameters | You provide exact values | Agent infers from context |
| Chaining | Manual piping | Conversational follow-ups |
| Error handling | Parse output yourself | Agent interprets and retries |
| Learning curve | Memorize each script | Describe what you want |
The killer feature isn't any individual tool — it's that I never have to remember which tool to use or what parameters it needs. I describe the outcome, the agent picks the tool.
Getting Started in 30 Minutes
- Pick 3 operations you do daily in the console
- Write a Python function for each (boto3 call + return JSON)
- Add MCP schema (name, description, input parameters)
- Wire up the JSON-RPC handler (read stdin, route, write stdout)
- Register in your MCP client config file
That's it. No infra to deploy, no costs, no dependencies beyond Python and boto3.
When MCP is NOT the Answer
- Automated pipelines — use CI/CD, not conversational tools
- Alerting — use EventBridge/CloudWatch alarms, not manual queries
- Complex queries — use Athena or proper dashboards
- Anything that should never be ad-hoc — automate it instead
MCP fills the gap between "fully automated" and "open console and click around." It's for the 20% of operations that are unpredictable — the "check this", "fix that", "what's happening" moments.
What's Next
I'm exploring deploying MCP servers as Lambda Function URLs — so team members can use the same tools without local AWS profiles. Authentication via Cognito token, zero setup on their end.
But honestly, 90% of the value came from the first afternoon of building the local version. Start there.
I haven't opened the AWS console for operational tasks in two weeks. Not because I can't — because I don't need to.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article