MCP, CLI and Skills Together: A Connectivity Stack for Production Agents

Demos defined 2024, coding agents defined 2025, and 2026 is the year general knowledge-work agents head into production. The Model Context Protocol is reported to have reached about 110 million monthly downloads, a milestone it hit faster than React did. Yet as agents take on enterprise workflows that span many SaaS apps and shared drives, one point keeps surfacing: connectivity isn't a single thing. Anyone who claims one answer, whether computer use, MCP or the command line, is selling too much. Strong agents don't pick one. They use the whole connectivity stack at once.

Three layers

Skills, CLI and MCP each solve a different problem, and each is built differently.

• Skills carry domain knowledge. They're reusable procedural instructions, usually markdown files, that teach a model how to use tools. They travel between clients and supply the context complex tasks need. Humans write them or agents generate them, and they load from local directories such as .claude/skills/ or from remote repositories.
• CLI, or computer use, is local execution in the Unix style. It composes well, spends few tokens (around 200 per response) and benefits from the model's pre-training on tools like git, gh and curl. You get CLI tools by installing ordinary binaries through a package manager.
• MCP is the connective tissue. It offers rich semantics, platform independence and enterprise features such as OAuth, governance policies and audit trails. A server is defined in code, for example server.py or server.ts, as tools, resources and prompts, and talks JSON-RPC 2.0 over HTTP or SSE.

When MCP is the right call

Reach for MCP when you need rich semantics, authorization and independence from the platform. It takes a schema-first, deterministic approach to tool selection, with governance and audit trails built in. The cost is context. A naive setup that loads every tool schema up front can eat 44,000 to 55,000 tokens, and each response is a full typed JSON object, great for programmatic parsing but heavy on tokens.

For anyone writing servers, the advice is to use descriptive function and parameter names and to annotate every parameter with a description. Models do better and faster when they know exactly what's expected.

# Annotated Tool Definitions
from typing import Annotated
from datetime import date
from enum import Enum

class Category(str, Enum):
    TRAVEL = "travel"
    MEALS = "meals"
    OFFICE = "office"

def submit_expense(
    amount: Annotated[float, "The expense amount in USD"],
    date: Annotated[date, "Date of the expense in YYYY-MM-DD format"],
    category: Annotated[Category, "The expense category"]
) -> str:
    """Submits a new expense report for approval."""
    pass

When CLI is the right call

If the tool already appears in the model's pre-training data, as with Git or the GitHub CLI, command-line execution is very strong. The model can chain commands with pipes and redirects and iterate on errors cheaply. Rather than receiving a giant JSON payload, it can filter with jq and get back only what it needs, a compact reply of roughly 200 tokens.

Progressive discovery

The single biggest upgrade to most agent harnesses is progressive discovery. Instead of pouring every tool into the context window, defer loading until the model actually needs one. Give it a tool_search capability so it can look tools up dynamically, and context use can fall by about a factor of five.

Programmatic tool calling

When a model must orchestrate several tools, don't make it call them one after another, because each step then pays inference latency. Use programmatic tool calling, also called Code Mode. Provide a REPL such as a V8 isolate or a Python sandbox and let the model write a script that composes the tools. The script is written once and runs the whole sequence, which cuts latency sharply.

// Programmatic Tool Calling (Code Mode)
// Instead of multiple sequential LLM turns, the model writes this script once:
const issue = await mcp.call_tool("linear_get_issue", { id: "ENG-5121" });
const prs = await mcp.call_tool("github_list_prs", { repo: "frontend" });

// Use structured output to enforce types
const expectedType = z.object({ title: z.string(), status: z.string() }).passthrough();
const typedIssue = await extract("claude-haiku-4-5", expectedType, issue);py

Build for agents

Server authors should stop mapping REST APIs one-to-one onto MCP servers and design for agents from the start. Three habits help. Build tools with clear intent, as you would an interface for a person. Expose execution environments, like the Cloudflare MCP does, so a model can orchestrate complex workflows in code. And ship an MCP App: use MCP's semantics to deliver UI resources, meaning HTML, JavaScript and CSS, over the wire so the server can render its own interface inside the client.

What's coming for MCP

The ecosystem is moving fast to meet enterprise needs and scale, and the 2026 roadmap has three threads.

• A better core: a new stateless transport, proposed by Google, should make MCP servers easier to deploy on Kubernetes and Cloud Run, and v2.0 releases of the TypeScript and Python SDKs are expected.
• Integration everywhere: Cross-App Access would give single sign-on across MCP servers through a company's identity provider, and servers could be found automatically from a file at .well-known/mcp-server-card/server.json.
• Beyond the current edge: Skills over MCP would let a server ship domain knowledge next to their tools through skills/list and skills/get endpoints.

Choosing among them

The decision depends on context and requirements: MCP when you need governance and rich semantics, CLI when the model already knows the tool and tokens matter, and Skills to supply the procedural knowledge that ties them together.

Takeaways

No single tool wins, and framing it as MCP against CLI misses the point. Production agents need layers. Criticism of MCP, namely token overhead, gaps in auth and uneven server quality, points at real problems, but they're engineering problems with fixes, and the ecosystem is already adjusting. Progressive discovery and Code Mode trim token bloat and latency, so the standard can be tuned instead of dropped. Walking away from MCP in an enterprise swaps those problems for worse ones: fragmented auth, no audit trail and vendor lock-in. Expect the strongest agents to pair Skills for knowledge, MCP for governed connections and the CLI for cheap local execution.