MCP Connects Agents to Tools, So Why Is It Still Not Enough?

What MCP Solves and What It Misses

Once you connect an Agent to MCP, calling tools seems straightforward. But an analysis from a Vietnamese tech channel offers a counterintuitive take: connecting to tools is only half the problem.

The value of MCP (Model Context Protocol) lies in unifying how Agents discover and invoke tools. The Agent talks to an MCP Server through an MCP Client, and the Server exposes tools that actually reach GitHub, Jira, code search, documentation, and production systems. At the protocol level, there are essentially two actions: Tools List (what tools exist on the server, their names, descriptions, and input parameters) and Tools Call (executing a specific tool, such as looking up an issue).

The problem is that connection itself doesn't answer governance questions. Every system you connect brings a whole set of permissions, credentials, and monitoring burdens. The MCP protocol is not responsible for answering: which Agent used which tool? Under whose identity is it running? Who tracks access? These are precisely each company's own rules.

MCP (Model Context Protocol) is an open protocol proposed and open-sourced by Anthropic in late 2024, aimed at standardizing how LLM applications connect to external data sources and tools. It uses a Client–Server architecture: the Agent side acts as the MCP Client, external systems are wrapped as MCP Servers, and the two exchange capability descriptions and execution results via JSON-RPC-style requests. The protocol defines primitives such as Tools, Resources, and Prompts, where Tools List declares available tools and their input schemas, and Tools Call performs the actual execution. MCP positions itself as the "USB-C port for AI applications," solving the problem of interface fragmentation, but it deliberately leaves policy layers such as authentication, authorization, and auditing to implementers—which is the technical root of the governance gap described in this article.

Every Team Writing Its Own Is the Real Cost Black Hole

If teams are left to their own devices, the situation quickly spirals out of control: one team writes its own OAuth, another manages its own secrets, and yet another keeps its own logs. Beyond duplicated effort, the standards end up completely inconsistent.

DoorDash's approach is to break the problem into three main threads and converge them onto a single Agent Gateway:

• Access (access control): who is calling, what they are allowed to do, and which credential is required
• Selection (tool filtering): a single Server may host hundreds of tools while a given workflow needs only a few, so only relevant and approved tools are exposed
• Operations (runtime assurance): tracking traffic, errors, response times, usage, and cost

According to the channel's analysis, these three threads together form the full responsibility of the Agent Gateway—access control governs "who can do what," selection governs "exposing only the right tools," and operations governs "whether it runs stably."

Identity is the most easily underestimated piece. Under whose account the Agent executes operations directly determines whether the audit trail holds up.

Agent Gateway can be understood as a Policy Enforcement Point sitting between the Agent and backend systems, similar in role to a traditional API Gateway but adapted for the non-deterministic, multi-tool orchestration scenarios of Agents. Typical capabilities include: OAuth/OIDC-based identity proxying and token exchange (letting the Agent call downstream with an explicit user or service identity), tool whitelisting and dynamic trimming per workflow, request-level audit logging, rate limiting and cost metering, and interception and redaction before requests reach production systems. The key difference from an API Gateway is that the Agent's call path is determined dynamically by the model rather than pre-coded, so the Gateway must perform tool visibility control and least-privilege granting at runtime—otherwise the permission model degrades into coarse-grained "allow-everything" authorization.

Audit trails and identity propagation are technical details often overlooked in Agent governance. In traditional systems, request identity is held directly by the caller; in Agent scenarios, there is a "delegation" relationship: the user authorizes the Agent, the Agent calls the MCP Server, and the Server accesses the backend. If the original user identity is not propagated across these hops, the logs will only show a shared service account, making it impossible to answer "who initiated this operation." A common industry practice is to use OAuth 2.0 Token Exchange (RFC 8693) or nested tokens, preserving both the initiator's and executor's identity claims at every hop and recording them uniformly on the Gateway side. Without this mechanism, even if tool calls succeed, post-hoc tracing and compliance auditing cannot hold up.

Using Tools Is Fundamentally About Rules, Not a Network Cable

This breakdown points to a more fundamental conclusion: getting Agents to use tools is not a "connection" problem but a "rules" problem. The protocol handles communication, and the Gateway handles governance. Without the latter, the more tools there are, the larger the risk surface.

The security boundary also lies here. The Gateway needs to intercept requests before they hit backend systems, preventing anomalous requests from penetrating into production.

This also explains why many teams remain "stuck" after MCP integration—what's blocking them isn't the protocol, but the engineering scaffolding: permission models, tool whitelists, and observability. The channel has teased a follow-up breaking down the internal implementation of the Agent Gateway, which for teams building Agent platforms is a topic more worth watching than the protocol itself.

(This article is based on analysis from a single video source; DoorDash's specific implementation details have not been independently verified.)

One-line Summary

MCP only unifies tool connections; the real bottleneck for Agent deployment is governance rules such as permissions, filtering, and operations.

Paragraph Summary

The article notes that while the MCP protocol unifies how Agents discover and invoke tools, it solves only half the problem: Tools List and Tools Call handle communication but do not answer governance questions around permissions, credentials, and monitoring. Leaving each team to implement OAuth, secret management, and logging on its own leads to duplicated effort and fragmented standards. DoorDash's approach breaks the problem into three main threads—access control, tool filtering, and runtime operations—converged onto an Agent Gateway, where the identity under which the Agent executes is key to a valid audit trail. The conclusion: getting Agents to use tools is fundamentally a rules-design problem rather than a connection problem; the protocol handles communication and the Gateway handles governance, and without the latter, the more tools there are, the larger the risk surface.