We've Been Using MCP Wrong: Its Only Real Value Is Authentication

MCP's Real Value: Authentication, Nothing Else

The conversation around Model Context Protocol (MCP) is heating up, but one YouTube developer has put forward a controversial take: most of us are actually using MCP wrong. His core argument is straightforward — the only reason you should use MCP is because it encapsulates authentication. Full stop.

This might sound simple, but it points to a widely overlooked problem in today's AI tooling ecosystem: many people treat MCP as a universal adapter for giving LLMs new capabilities, while missing the part that's actually irreplaceable — controlled permission boundaries.

The Hidden Risk of CLI Login Patterns

The author uses Cloudflare's Wrangler CLI as a cautionary example. Once you log into a CLI tool, your credentials persist in the local environment. The problem follows immediately: any agent that can access this CLI can use it to perform operations on your Cloudflare account.

This is a genuinely dangerous authorization model. You haven't granted permission for a specific agent run — you've exposed your entire account's operational capabilities to anything that can touch that environment. For increasingly automated, increasingly "unsupervised" AI agents, these broad, long-lived credentials are essentially a blank check.

This risk is known in security circles as "Credential Sprawl" — long-lived access tokens scattered across environments, difficult to track or revoke. The traditional Principle of Least Privilege dictates that each operation should only obtain the minimum permissions needed to complete it, and those permissions should expire immediately afterward. Persistent CLI credentials violate this principle: they hand an agent an "unlimited pass" rather than a "single-visit badge." In AI agent scenarios, this problem is amplified further — agents can be manipulated through prompt injection attacks, where malicious instructions exploit legitimate credentials to execute destructive operations, with no way for the system to distinguish authorized user behavior from an attack.

What Makes MCP Different: On-Demand Authorization + Explicit Action Sets

By contrast, MCP's authorization model is far more granular. The author points out that you can enable an MCP for one specific run, giving the agent a bounded set of actions and the corresponding authentication.

In other words, MCP bundles "what you can do" together with "what you're authorized to do," forming a controllable scope. That's its genuine advantage over bare CLI tools or custom scripts — not the capabilities themselves, but the constraints and isolation placed around those capabilities.

MCP (Model Context Protocol) was proposed and open-sourced by Anthropic in late 2024 to standardize how LLMs interact with external tools and data sources. Its design draws from OAuth 2.0's authorization philosophy: the service provider (MCP Server) declares which tools and resources it can offer, and the client requests access on demand for a specific task, rather than acquiring all permissions upfront. This "dynamic capability discovery + scoped access" pattern means the same agent can receive different permission sets across different tasks, enabling fine-grained access control. This is precisely why the author emphasizes that MCP's core value lies in authentication boundaries rather than tool capabilities — the protocol explicitly separates "what can be called" from "what is authorized to be called" at the architectural level.

Providing Capabilities: MCP Is No Better Than a Homegrown Solution

This is the most counterintuitive — and most thought-provoking — part of the author's argument. He states plainly: when it comes to simply providing capabilities, MCP has no inherent advantage over tools you write yourself.

The reason is that modern LLMs are extraordinarily good at following instructions. If you directly tell the model "here are five things you can do," it will do them — no need to wrap those actions in a layer of MCP protocol. The protocol layer adds no extra magic in terms of expressing capabilities; it only adds complexity.

A Real-World Example: An Agent Driving Programs Directly

The author illustrates this with his own project (which sounds like a tool called Alakargi). The system has a client that directly tells the model "here is everything you can do," and the model then calls the underlying programs to run.

The program operates at a very low level: capturing screen images, sending keystrokes, executing mouse actions. The author describes letting the model directly control the mouse — "move, double-click" — and the model simply knows how to use these primitives. It goes ahead and operates the interface directly, with no MCP involved anywhere in the process.

This example strongly supports the author's central thesis: when you simply want an LLM to use certain capabilities, clear instructions and a callable program interface are enough. MCP is redundant in this kind of scenario.

What This Means for Developers

This perspective offers a practical decision framework for developers building AI agents:

• Need permission isolation and on-demand authorization across accounts or services? Use MCP — its authentication model is built exactly for this.
• Just want to expose a set of internal actions to a model? Write clear instructions and provide a program interface directly. There's no need to force MCP into the picture.

Of course, this is a single developer's personal take, shaped by a distinctly hands-on perspective. The MCP ecosystem is still evolving rapidly, and the value of standardization — tool reuse, interoperability — shouldn't be dismissed entirely. But the question the author raises cuts to the heart of the matter: before introducing any protocol layer, get clear on what problem it actually solves — is it authentication, or are you just using it because everyone else is?

For teams blindly stuffing every capability into MCP, this is a reminder worth hearing.