MCP, CLI, and Agent Skills: A Research View on Tool Use for LLM Agents

The interesting question is not which interface "wins." It is sharper and less partisan: which boundary should carry protocol, execution, workflow knowledge, and governance in an LLM agent system?

LLM agents fail in ways that look strange until you treat tool use as a cognitive load problem.

An agent can have the right tool available and still pick the wrong one. It can receive relevant information and still lose it somewhere in a long prompt. It can execute a perfectly valid tool call while misunderstanding the workflow that call was supposed to live inside. Give it twenty reasonable tools and it may perform worse than it did with five.

None of that is purely a model failure. It is an interface failure.

The Model Context Protocol, command-line interfaces, and Agent Skills are not three contenders for one job. Each answers a different part of the tool-use problem. MCP standardizes discovery and invocation. CLI tools provide executable, inspectable operations. Skills encode procedure, examples, constraints, and recovery logic. HTTP APIs and governed gateways centralize authorization and telemetry.

The mistake — and it is a common one — is collapsing all of those jobs into a single local tool registry.

This article takes a research view of the current debate, and its conclusion is deliberately bounded: MCP over stdio is often a weak default for complex local agents; MCP over HTTP remains appropriate for governed platforms; CLI + Skills is frequently the better local architecture because it separates execution from procedural knowledge and supports progressive disclosure.

Background: Tool Use Is a Multi-Stage Problem

Most descriptions of agent tooling compress the problem into a single step: the model calls a tool. Done.

In practice, tool use has at least five stages:

tool-use loop
├── decide whether a tool is needed
├── retrieve or notice candidate tools
├── select the right tool for the task
├── fill valid arguments
└── interpret the result inside a larger workflow

Tool-learning research keeps finding that these stages come apart. MetaTool studies whether models know when to use tools and which ones to choose. WTU-EVAL asks whether a tool should be used at all, instead of assuming the answer is always yes. ToolRet treats tool retrieval as a problem in its own right, with a large corpus of heterogeneous tools. ToolLLM trained and evaluated models over thousands of real-world APIs.

The implication is worth sitting with: an interface that only exposes callable functions has solved the execution surface. One stage out of five.

An agent needs to know what exists, what matters right now, what order to follow, what a failure means, and when to call nothing at all. Which is why tool metadata, context layout, command discoverability, and workflow instructions are not implementation details. They are the agent's reasoning environment.

MCP: A Standard Interface, Not a Complete Architecture

MCP earns its place by standardizing a real integration boundary. The protocol gives clients one common way to discover capabilities, call tools, read resources, and talk to external systems. The official specification defines transports including stdio and Streamable HTTP, and MCP has become the shared vocabulary for agent-tool connectivity.

That standardization is worth defending. Before shared protocols, every integration was a custom bridge: one plugin per app, one connector shape per model client, one hand-written adapter per workflow. Nobody misses that era.

But a protocol is not an architecture. MCP defines how a client and a server communicate. It says nothing about tool retrieval, prompt budget, workflow sequencing, or human debuggability — and nothing about whether the tool surface belongs in the model context in the first place.

And the distinction between stdio and HTTP is not a detail.

MCP over stdio is convenient for local integrations. A client launches a subprocess and exchanges JSON-RPC messages over stdin/stdout. That convenience makes local experimentation easy, but it buys a fragile process boundary: stdout must stay protocol-clean, logs have to live elsewhere, environment variables become the credential channel — and when something breaks, the investigation spans client logs, server logs, schema interpretation, and model behavior. Four layers for one error.

MCP over HTTP plays in a different league. HTTP deployments can sit behind OAuth, policy enforcement, service identity, audit logging, telemetry, and centralized lifecycle management. There, the protocol boundary is doing real organizational work.

Context Is Not Free

The strongest technical objection to large local tool registries is not aesthetic. It is context load.

Tool schemas, descriptions, examples, and parameter definitions are not neutral passengers. The moment they enter the prompt, they compete — with the user's task, the code, the retrieved evidence, the earlier decisions, the safety constraints. Everything the model actually needs. More context does not automatically mean more capability.

Long-context research has been sounding this alarm for years. In Lost in the Middle, models used information less reliably when the relevant evidence sat in the middle of a long context. Large Language Models Can Be Easily Distracted by Irrelevant Context showed that irrelevant information alone can drag down problem-solving accuracy. More recent work on context length hurting performance despite perfect retrieval argues that even when the relevant information is right there, longer inputs can degrade performance across tasks.

Tool definitions obey the same physics. Show an agent dozens or hundreds of affordances that have nothing to do with the task at hand, and you have manufactured a distraction problem before the first token of reasoning is generated.

Microsoft Research has a name for it: tool-space interference — adding individually reasonable tools can reduce end-to-end agent performance once the combined tool space becomes harder to navigate. This is not an argument against tools. It is an argument for tool-space design.

CLI + Skills as Progressive Disclosure

CLI tools and Agent Skills do not replace protocols in every setting. They propose a different decomposition of the local agent problem — and, often, a better one.

The CLI is the execution substrate. It hands humans and agents the same operational surface: subcommands, help text, flags, exit codes, structured output, authentication, shell-level composability. A good CLI works in a terminal, a script, CI, documentation, and an agent session without changing shape.

Skills are the procedural layer. Anthropic's Agent Skills engineering post describes a model of progressive disclosure: metadata is visible first, full instructions load only when they become relevant, and supporting references or scripts are consulted on demand.

That architecture matters because it keeps most procedural knowledge out of the base prompt. The agent starts from an index, not a five-hundred-page manual.

The pattern also lines up with the basic lesson from tool-use research: selection and execution are different problems. A CLI can be excellent at execution while a Skill is excellent at helping the model select, sequence, and interpret operations.

A CLI can expose the verbs:

• status for current state
• list for inventory
• create for provisioning
• delete for destructive operations
• --json for structured output
• --help for on-demand discovery

And a Skill can encode the rules of the trade:

• inspect before you mutate
• prefer dry-run modes where they exist
• ask before destroying anything
• retry only on specific transient failures
• summarize command output instead of pasting all of it
• stop when credentials or permissions are missing

MCP can expose similar capabilities, but stdio MCP tends to flatten them into passive function calls. CLI + Skills makes the separation explicit — and the separation is the point.

Where MCP Still Belongs

A research view should resist swapping one universal answer for another.

MCP over HTTP remains a strong candidate wherever the system needs centralized governance. Large organizations need consistent authentication, authorization, audit logs, usage telemetry, policy enforcement, and shared service ownership — guarantees that a scatter of local CLI tools does not naturally provide.

MCP over stdio remains reasonable for small local bridges with narrow tool surfaces. If a tool has two or three stable actions, no real workflow, and no need for shared human execution, the overhead is a fair price.

The weak default is not MCP itself. The weak default is local MCP as a universal wrapper around every command, service, document source, database helper, browser operation, and internal workflow a team can think of.

Design Principles for Agent Tool Interfaces

The practical principles fit on an index card.

Minimize always-loaded context. Put only indexes, names, and trigger descriptions into the base context. Load full procedures and reference material when they are needed, not before.

Separate execution from instruction. Execution surfaces should be deterministic, scriptable, and inspectable. Procedural guidance belongs in Skills, docs, policies, or task-specific prompts.

Preserve human debuggability. If an agent ran a command, a human should be able to rerun it, inspect the output, and understand why it was chosen.

Treat tool retrieval as a first-class problem. Large tool corpora need retrieval, routing, ranking, or scoping before selection ever happens. Dumping every possible tool into the model context is a brittle baseline, not a design.

Choose transport by governance boundary. Stdio is a process convenience. HTTP is a platform boundary. CLI is an execution boundary. Skills are a workflow boundary.

Conclusion

Strip away the partisanship, and the debate around MCP, CLI, and Agent Skills is a context-management debate wearing a standards-war costume.

LLM agents do not become reliable because they can call more tools. They become reliable when the tool space is scoped, the relevant information arrives at the right time, the workflow knowledge is explicit, and the execution can be inspected after the fact.

For local developer agents, CLI + Skills usually gives the better decomposition: the CLI does the work, the Skill teaches the craft, and everything irrelevant stays out of context until the moment it earns its place. For enterprise platforms, MCP over HTTP keeps a strong role, because governance is itself part of the system.

The end state is not "everything becomes an MCP server." It is a layered architecture where each boundary is chosen for the job it actually performs.

As in any well-designed system.

Sources: MCP transport and authorization specifications; Anthropic's MCP donation announcement and Agent Skills engineering note; Microsoft Research on tool-space interference; Liu et al. on lost-in-the-middle long-context behavior; Shi et al. on irrelevant-context distraction; Amazon Science/arXiv work on context length and performance; MetaTool, WTU-EVAL, ToolRet, ToolLLM, MCP-Atlas, and survey literature on LLM tool learning.