·

AWS MCP With Gemini CLI

Set up AWS MCP in Gemini CLI so your AI agent can manage cloud resources and investigate infrastructure right from your editor.

Gemini CLI's MCP implementation is solid for tool-calling generally, and it turns out to be a strong fit specifically for cost analysis — Gemini's larger context window handles the sprawling, tag-heavy JSON that Cost Explorer returns better than you'd expect. This topic covers the setup, CloudWatch Insights usage, a real cost-driver investigation, and an honest comparison against Claude Code.

Installing and Connecting AWS MCP to Gemini CLI

Gemini CLI uses settings.json for MCP server configuration, either at ~/.gemini/settings.json (user scope) or .gemini/settings.json in a project (project scope). As with the other clients, keep AWS entries at user scope.

{
  "mcpServers": {
    "aws-api": {
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "dev-readonly",
        "AWS_REGION": "us-east-1"
      },
      "trust": false
    },
    "aws-cloudwatch": {
      "command": "uvx",
      "args": ["awslabs.cloudwatch-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "dev-readonly",
        "AWS_REGION": "us-east-1"
      },
      "trust": false
    },
    "aws-cost": {
      "command": "uvx",
      "args": ["awslabs.cost-analysis-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "dev-readonly",
        "AWS_REGION": "us-east-1"
      },
      "trust": false
    }
  }
}

Leave trust at false (or omit it — that's the default) for AWS servers specifically. Gemini CLI's trust: true flag skips the per-call tool confirmation prompt, which is a reasonable trade-off for something like a filesystem MCP server on your own machine, but not for a server that can call mutating AWS APIs if your IAM policy allows it. Confirming each call adds friction, but for account-affecting tools that friction is the point.

Confirm the connection inside the CLI:

gemini
> /mcp list

✓ aws-api (2 tools) - connected
✓ aws-cloudwatch (4 tools) - connected
✓ aws-cost (3 tools) - connected

If a server shows disconnected, run gemini with --debug to see the raw stderr from the failed process launch — this surfaces uvx-not-found and Python version mismatches far more clearly than the default output.

gemini --debug

Tips
- Leave trust: false on every AWS MCP server entry — the per-call confirmation prompt is your last line of defense against a mutating call you didn't intend, and it costs you one keypress per call.
- Use gemini --debug immediately when a server fails to connect rather than guessing — it prints the exact subprocess launch command and its failure output, which is the fastest path to root-causing a uvx/PATH issue.

Running CloudWatch Insights Queries from Gemini CLI

The tool-calling mechanics are identical to the other clients — same execute_log_insights_query tool, same query language — but Gemini CLI's longer context budget is genuinely useful here when you want to pull a wide time window and let the model do pattern-finding across a lot of raw log data rather than a tightly pre-aggregated query.

Run a Logs Insights query against /aws/lambda/inventory-sync-prod for the
last 24 hours. I don't have a specific error in mind — just show me
everything at WARN level or above, grouped by hour, and tell me if you
see any pattern correlating with a specific time of day.

fields @timestamp, @message
| filter @message like /WARN/ or @message like /ERROR/
| stats count(*) as issueCount by bin(1h)
| sort @timestamp asc

For a more targeted diagnosis once you have a hypothesis:

fields @timestamp, @message, @logStream
| filter @message like /rate exceeded/
| stats count(*) as throttleCount by bin(15m)
| sort throttleCount desc
| limit 10

A workflow that plays to Gemini's strengths specifically: pulling a wide, unfiltered log window and asking the model to find the pattern itself, rather than pre-filtering with a narrow query you have to already know how to write. This is slower and costs more in Logs Insights scan volume, so use it for genuine "I don't know what I'm looking for yet" exploration, not routine debugging where you already have a hypothesis.

Pull metric data for Duration, Errors, Throttles, and ConcurrentExecutions
for inventory-sync-prod over the last 24 hours at 5-minute granularity,
and correlate that against the WARN/ERROR pattern you just found.

Tips
- Reserve wide, unfiltered Logs Insights pulls for genuine unknown-unknowns exploration — they cost more in scan volume, and a narrower query with a specific filter clause is both cheaper and faster once you have any hypothesis at all.
- Ask explicitly for metric-and-log correlation in one prompt rather than two separate ones — Gemini CLI handles holding both result sets in context and cross-referencing them in a single response reasonably well.

Practical Example: Identifying the Top Cost Drivers in an AWS Account

This is where awslabs.cost-analysis-mcp-server — paired with Gemini's context capacity — earns its place. Cost Explorer's raw API responses are verbose (nested by service, by usage type, by region), and a genuine "why did our bill jump" investigation involves iterating across several dimensions.

Our AWS bill increased 23% month over month. Pull cost and usage data for
the last two full months, broken down by service, and identify which
services account for the increase. Then break down the top 2 services by
usage type to explain what specifically drove the change.

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --profile dev-readonly

Once the top service is identified — say, EC2 — a follow-up drills into usage type:

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --profile dev-readonly

For tag-based attribution — the question that actually matters for accountability ("which team's workload caused this") — Cost Explorer needs cost allocation tags activated first, which is an account-level setting, not something the agent can turn on itself:

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=team,Status=Active \
  --profile admin

Once tags are active (allow 24 hours for backfill), the same investigation becomes team-attributable:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=TAG,Key=team \
  --profile dev-readonly

In a real investigation on a mid-sized account, this pattern surfaced an EC2 cost jump traced to a forgotten m5.4xlarge instance left running after a load test — tagged team=platform, purpose=load-test, with no auto-termination. The agent's value wasn't finding the instance (a describe-instances filtered by tag does that in one call); it was connecting the cost spike to the specific instance and its launch date, then confirming via CloudTrail that no one had touched it in three weeks — building the full "here's what happened and why it's safe to terminate" case in one session instead of five separate lookups.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=i-0a1b2c3d4e5f67890 \
  --profile dev-readonly

Tips
- Activate cost allocation tags before you need them — the 24-hour backfill delay means you can't retroactively get team-level attribution for a cost spike that already happened if tags weren't active at the time.
- Cross-reference a cost-driver finding with cloudtrail lookup-events before recommending termination of anything — "expensive and idle" is a strong signal but not proof it's abandoned; confirm no legitimate recent activity before proposing a mutating fix.

Comparing AWS MCP Output Between Gemini CLI and Claude Code

Both clients call the identical MCP servers and get identical raw tool output — the differences are entirely in reasoning style and session ergonomics, not data accuracy.

Where Gemini CLI has an edge:
- Wide, exploratory investigations across large JSON payloads (Cost Explorer's nested breakdowns, multi-day unfiltered log pulls) — the larger context window means less need to pre-summarize or chunk the data yourself.
- Cost analysis specifically, where correlating usage-type-level detail across multiple services in one pass benefits from more room to hold context.

Where Claude Code has an edge:
- Tighter integration between tool output and your actual repo code — Claude Code's file-reading and tool-calling loop feels more naturally interleaved when a fix needs to touch both AWS state and source files in the same turn.
- Slightly more conservative and explicit about flagging when it's uncertain which resource or region a query resolved to, based on direct side-by-side sessions run against the same incident.
- Better tool-output UX for iterative narrowing (collapsible/summarized tool results vs. Gemini CLI's more verbose default rendering).

Practically identical for both:
- Raw IAM policy analysis and simulate-principal-policy interpretation — both handle this well since it's a fairly mechanical read-and-explain task.
- Basic S3/EC2/Lambda listing and filtering.

The honest takeaway: for a cost-analysis-heavy sprint, reach for Gemini CLI. For day-to-day incident debugging tightly coupled to your codebase, Claude Code's tighter code-and-cloud interleaving generally saves more time. Neither is categorically better — they diverge by task shape, and a team running both isn't wasting effort by keeping two configs current.

Tips
- Don't standardize your whole team on one client for all AWS MCP work — the task-shape differences here are real enough that keeping both configs current (Claude Code + Gemini CLI at minimum) pays off for teams that do both cost work and incident debugging regularly.
- When comparing output between clients for a genuinely important decision (e.g., before terminating a resource), re-run the same investigation in a second client — cheap insurance against a single client's reasoning quirk leading you to a wrong conclusion.

Tips

Tips
- Keep trust: false on all AWS MCP entries in Gemini CLI's settings.json — the confirmation-per-call friction is worth it for anything that can touch a real account.
- Reach for Gemini CLI specifically for cost analysis and wide exploratory log pulls; its context capacity is a genuine practical advantage there, not just a marketing spec.
- Activate AWS cost allocation tags now, before your next cost spike — team-level attribution is worthless retroactively if the tags weren't live when the spend happened.

Next AWS MCP With Cursor