Trimio Field Notes

MCP vs. CLI vs. API: Three Ways to Call an LLM, One Place to Govern Them All

June 4, 2026 7 min read architecturegovernancemcpstandards

The debate about whether MCP (Model Context Protocol) is dying hit HN last week with 266 points and 243 comments. The argument: direct CLI access to Claude Code, raw API calls, and native SDK integrations are all bypassing MCP as transport layers. The thread was alive with engineers arguing about the right abstraction for AI tool use.

The thing nobody in that thread addressed: it doesn't matter which transport layer your team uses. Every single one of those calls passes through the same chokepoint — and that chokepoint is where governance lives.

Whether a request comes in over MCP, a CLI wrapper, a raw API call, or a GitHub Actions integration, it ends up in the same place: an HTTP request to an LLM endpoint with a model name, a token payload, and a provider API key. That's the layer that determines cost, quality, security, and compliance. The transport is upstream of that decision. The governance layer is at it.

3
Transport Layer Patterns
MCP, CLI integration, and raw API calls are the three dominant patterns for calling LLMs in 2026 — and all three route through the same LLM endpoint layer.
1
Governance Layer
Whether you're using Claude Code, a custom CLI, MCP-native agents, or direct API calls — one gateway layer controls cost, quality, and security across all of them.
0
Transport Layer Lock-In
Trimio intercepts at the HTTP layer. Your agents can use any transport. Trimio's routing, compression, and governance apply uniformly — no transport rewrites required.

What the MCP-is-dead debate is actually about

Essential
The MCP-vs-CLI debate is a debate about where to place the abstraction layer for AI tooling. It has nothing to do with where cost, quality, and security controls live. Those controls live at the LLM endpoint layer — and that layer is transport-agnostic.

The case for MCP's death isn't really about MCP failing as a protocol. It's about developers discovering that direct CLI access gives them more control over the full request lifecycle — including which model gets called, how the request is formatted, and how the response is cached. MCP sits in the middle and abstracts that away. For power users, that's a limitation.

CLI-native tools like 9Router, RTK, and TokenPak take a different angle: they wrap the API call layer directly and add compression, routing, and provider abstraction at that level. You're still making HTTP calls to LLM endpoints. The CLI wrapper is just a convenience layer on top.

Direct API calls — the third pattern — skip any wrapper entirely. If you're using Claude Agent SDK, Cursor, or writing a custom integration, you're making raw REST calls with a provider API key in the header. No MCP, no CLI layer, no wrapper. Just the request.

Three distinct patterns. One common denominator: every call is an HTTP request to an LLM provider's endpoint with a model name and a token payload.

The governance layer is transport-agnostic by design

Essential
A proxy-layer gateway intercepts LLM calls at the HTTP level — below the transport layer, at the actual API call. This means governance applies uniformly regardless of how the request originated: MCP, CLI, SDK, or raw curl.

Here's what this means in practice. If your team runs Claude Code (CLI-native), builds custom agents with the Anthropic SDK (API-native), and has a new team experimenting with MCP-native agents, you have three distinct transport patterns in the same organization. Without a central gateway, each pattern is governed separately — if at all.

Claude Code gets its own API key and makes direct calls. Your custom agent uses a separate key. The MCP team is calling a third provider directly. Each team has their own cost visibility — at best. Nobody has cross-team spend visibility, uniform routing policies, or shared security controls.

With a proxy layer in place: every LLM call — regardless of transport — routes through the same gateway. The gateway applies routing rules, compression, token counting, PII detection, and audit logging. The team running Claude Code through CLI is governed identically to the team using MCP-native agents. The custom agent SDK integration hits the same routing logic. Cost, quality, and security controls are consistent across the entire organization, not siloed by transport pattern.

The three governance capabilities that transport-agnosticism unlocks

1. Unified spend visibility across every transport pattern. MCP calls, CLI wrappers, and direct API calls all show up in the same request log. Finance teams see the full picture: which team is spending what, which models are in use, where the optimization opportunities are. No transport pattern is invisible.

2. Consistent routing policy regardless of how the call originated. If you want all coding-class traffic under a quality-85 threshold to route to the highest-value model, that policy applies whether it comes in over MCP, CLI, or direct API. You don't configure routing separately for each transport layer. The gateway enforces it at the endpoint.

3. Security controls that follow the request — not the tool. PII detection, content policy gates, and audit logging apply to every request that passes through. A prompt injection attempt over MCP hits the same policy enforcement as one over a raw API call. The security boundary is at the gateway, not at the transport layer.

Why the MCP debate shouldn't matter to your procurement decision

Essential
The right question when evaluating an AI gateway isn't "does it support MCP?" It's "does it govern all my LLM traffic, regardless of transport?" MCP support is a feature list item. Transport-agnostic governance is a structural requirement.

If you're evaluating AI gateway products, here's the test: take any LLM call from any tool in your stack — Claude Code, Cursor, a custom agent, an MCP-native integration — and trace it to the actual HTTP request. At that layer, does the gateway apply cost controls, routing policies, and security enforcement? If yes, you've found transport-agnostic governance. If you need to configure it differently depending on which tool made the call, you have transport-specific governance — which creates the same visibility and control gaps as having no gateway at all.

The MCP-vs-CLI debate will continue. New transport patterns will emerge. The teams that get governance right are the ones that focus on the layer that actually matters: the LLM endpoint, where every request — from every transport — arrives the same way.

Trimio governs every LLM call — MCP, CLI, SDK, or raw API — at the endpoint layer. Unified routing, compression, spend visibility, and security controls for the entire organization. See how it works.

Trimio
Stop guessing. Start governing.
trimio is the LLM API gateway purpose-built for AI cost governance — visibility, routing, caching, and budget enforcement in one layer.