CLI vs MCP, Part Two: The First Gap Just Closed

written by Stefan Christoph

- 9 minutes read
TL;DR: In March I argued the CLI vs MCP debate was the wrong debate, and that the CLI’s advantages were a temporary artifact of training data, not a law of physics. One of those advantages was multi-account work: the aws CLI switches accounts with a --profile flag on every command, while the AWS MCP Server made you stop the session, rewrite your credentials, and restart. On June 5 that gap closed. The AWS MCP Server now takes a profile per command. And the way it closed the gap is more interesting than the fact that it did, because the MCP version is not a copy of the CLI behaviour. It is a stricter, safer version of it.

A Prediction, Three Months On

In March I wrote a post called “CLI vs MCP: The Wrong Debate” [4]. The argument was that the whole “is MCP a mistake?” fight missed the point. CLIs win where the model already knows the tool from training, because it has read a million git commit examples and needs no schema. MCP wins for the bespoke integrations no model has ever seen. The two are not competitors. They are layers.

The part of that post I was least sure about was the prediction at the end. Building on Didier Durand’s analysis of the “accidental” advantage CLIs hold [6], I claimed the CLI’s edge was “a snapshot, not a law of physics” — a head start that comes from training data, and one that would erode as MCP matured and as MCP interactions started showing up in future training sets. It was the kind of forecast that is easy to write and easy to be wrong about.

Three months later, the first concrete piece has fallen. And it fell on exactly the dimension I had flagged as the CLI’s most painful real-world advantage: account and credential switching.

What Actually Shipped

On June 5, AWS announced cross-account and cross-role access for the AWS MCP Server, part of the Agent Toolkit for AWS [1] [3]. The change is small to describe and large in practice: an agent can now specify which AWS profile to use on each individual command, so it can move between accounts and roles inside a single conversation with no restart [1].

Before this, switching accounts through the MCP server meant stopping the AI session, editing your local AWS credentials, and restarting the server for every account change [1]. That is not a minor annoyance when your day looks like “diagnose this in staging, then check whether prod is configured the same way.” It is a hard context switch that breaks the flow of the conversation you are having with the agent.

The feature is live in US East (N. Virginia) and Europe in Frankfurt (eu-central-1) [1]. It is the kind of unglamorous capability that does not trend, but it removes a real reason people were reaching back for the raw CLI.

Why This Is The Gap I Meant

Here is the section from the original post that this announcement speaks to directly. I listed three places where CLIs break for agents, and the third was authentication:

The Authentication Nightmare. This is the one that hurts most in practice. CLIs rely on local profiles — ~/.aws/credentials, ~/.kube/config, GitHub tokens in environment variables. For a solo developer, this works. For an enterprise with 200 developers running AI agents that need access to internal services? It’s a security team’s worst nightmare. No centralized revocation, no scoped permissions, no audit trail. [4]

That framing was about the CLI’s weakness at enterprise scale. But it hid a flip side I did not give enough credit to: for the single multi-account developer, the CLI’s local-profile model was also a strength the MCP server simply lacked. aws s3 ls --profile dev and aws s3 ls --profile prod are two characters of difference and zero restarts. The MCP server could not do that. So for anyone living in three or four accounts a day, the CLI quietly won, and it won on muscle memory.

That is the advantage that just expired. Not because someone decided MCP should imitate the CLI, but because the multi-account use case was painful enough that it earned a first-class solution.

How It Works, And Why It’s Stricter Than The CLI

The mechanism lives in the MCP Proxy for AWS, which sits between your agent and the AWS MCP Server [2]. You declare the profiles you want available when the proxy starts. The proxy then injects an aws_profile parameter into the schema of the tools that need credentials, so the agent can pick a profile per call [2].

The MCP client configuration below comes straight from the official Agent Toolkit user guide [2]. The AWS_MCP_PROXY_PROFILES value is the allowlist of profiles the agent is permitted to use.

# ~/.aws config drives which profiles exist; the proxy decides which are exposed.
mcpServers:
  aws-mcp:
    command: uvx
    args:
      - mcp-proxy-for-aws@latest
      - https://aws-mcp.us-east-1.api.aws/mcp
    env:
      # First profile is the default; the rest are switchable.
      AWS_MCP_PROXY_PROFILES: "prod-readonly dev staging"

The routing logic is where it gets interesting [2]:

  • A call with no aws_profile is signed with the first profile in the list — so you can make the safe one the default.
  • A call with aws_profile="dev" is routed through a connection signed with the dev credentials.
  • A call naming a profile that was not declared at startup is rejected, with an error listing the profiles that are allowed.
  • The aws_profile parameter is stripped before the request reaches the backend, so the AWS MCP Server never sees it [2].

Read those rules again with the original post’s “authentication nightmare” in mind. The raw CLI exposes every profile sitting in ~/.aws/config; the agent can use any of them. The MCP proxy exposes only the profiles you explicitly listed, defaults to whichever you put first, and refuses everything else by name [2]. That is an allowlist, a least-privilege default, and a closed door, built into the switching mechanism itself.

So MCP did not just match the CLI here. On the dimension I called the CLI’s worst enterprise liability, the MCP version arrives with the guardrails already attached. That fits a longer arc: in April I wrote about MCP growing from a tool-calling convenience into a production platform [5], and per-command, allowlisted credential routing is exactly the kind of operational detail a platform grows into.

The Decision That Got Simpler

Decision flow showing how the MCP proxy routes a tool call based on the aws_profile parameter

How the proxy routes each call by profile: an unspecified call hits the read-only default, a named profile routes to its own credentials, and an undeclared profile is rejected with the allowed list.

In the original post I gave four pieces of advice to builders. One of them was “don’t pick a side — use CLIs for well-known tools, use MCP for everything else.” This announcement does not change that advice. It moves a workload across the line. Multi-account AWS work used to be a reason to drop out of the MCP layer and run aws --profile directly. Now it is a reason to stay in the conversation.

The Honest Caveats

I want to be careful not to do the thing I criticised in the first post, which is to declare a winner. This is one feature.

It is available in two regions, not everywhere [1]. It requires the MCP Proxy for AWS at version 1.6.0 or later, and the profile switching only applies to the AWS MCP Server, not to other MCP servers you might proxy [2]. The profiles still resolve to local credentials in ~/.aws, so the broader “no centralized revocation, no audit trail” problem I described for enterprise fleets is not solved by this alone — it is mitigated for the single developer with an allowlist, not eliminated for the org. And profile-per-command is a credential convenience, not a permission boundary; the IAM policies behind each profile are still what actually constrain the agent.

What it is, precisely, is the first data point for a prediction I made three months ago. The CLI’s lead was supposed to be a head start that erodes. Here is a piece of it eroding, in public, on the schedule I guessed at.

What This Means For You

If you run an AWS workday through an agent, three practical moves [2]:

  1. Make the default profile read-only. The first profile in AWS_MCP_PROXY_PROFILES is what an unspecified call uses. Put prod-readonly first so the safe path is the lazy path.
  2. Keep the allowlist tight. Only list the profiles the agent genuinely needs this session. The proxy cannot use a profile you did not declare, even if it exists in ~/.aws/config.
  3. Gate the dangerous profiles at the client. The docs recommend client-side hooks or permission rules to require manual approval before a write-capable or production profile is used [2]. Treat per-command switching as the plumbing, and your client approval rules as the safety valve.

The question from the first post still stands: it was never CLI or MCP, it was knowing when each earns its place. What changed this week is that the “both” is converging. The terminal is the interface of our history. The protocol is the interface of our future. And the future just took back one of the present’s last good arguments for the past.

If You’re Running This on AWS

The pieces you need are all in the Agent Toolkit for AWS [3]:

  • Install the proxy. The AWS MCP Server is reached through mcp-proxy-for-aws (1.6.0+), run via uvx as shown in the config above [2]. Point it at the regional endpoint, for example https://aws-mcp.us-east-1.api.aws/mcp [2].
  • Set up your profiles. Each profile in your allowlist needs entries in ~/.aws/config and ~/.aws/credentials, with IAM permissions scoped to the minimum that profile’s work requires [2]. A read-only default plus narrowly-scoped write profiles maps cleanly onto the proxy’s routing.
  • Mind the Regions. Cross-account access is available in US East (N. Virginia) and Frankfurt (eu-central-1) today [1]. Pick the endpoint that matches your data residency needs.
  • Layer client-side controls. For production safety, add approval hooks in your MCP client (Kiro, Claude Code, Codex, and similar all support permission rules) so a prod call pauses for a human [2].

Full setup is in the Multi-profile support guide [2] under the Agent Toolkit for AWS documentation.

Sources

[1] AWS, “The AWS MCP Server now supports cross-account and cross-role access” — AWS What’s New, June 5, 2026. https://aws.amazon.com/about-aws/whats-new/2026/06/aws-mcp-server/

[2] AWS, “Multi-profile support” — Agent Toolkit for AWS User Guide. https://docs.aws.amazon.com/agent-toolkit/latest/userguide/multi-account-access.html

[3] AWS, “Agent Toolkit for AWS” — Product page. https://aws.amazon.com/products/developer-tools/agent-toolkit-for-aws/

[4] Stefan Christoph, “CLI vs MCP: The Wrong Debate” — schristoph.online, March 17, 2026. https://schristoph.online/blog/cli-vs-mcp-the-wrong-debate/

[5] Stefan Christoph, “The Protocol We Should Have Built for Humans” — schristoph.online, April 20, 2026. https://schristoph.online/blog/the-protocol-we-should-have-built-for-humans/

[6] Didier Durand, “The Terminal (CLI) vs. The Protocol (MCP): 5 Counter-Intuitive Truths About the Future of AI Tooling” — Didier’s Substack, March 15, 2026. https://didierdurand.substack.com/p/the-terminal-cli-vs-the-protocol

Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

❤️ Created with the support of AI (Kiro)