Enterprise Agent Capability Exposure: The Underlying Logic and Challenges of CLI vs. MCP

Enterprise Agent Capability Exposure: The Underlying Logic and Challenges of CLI vs. MCP

In recent years, as large model applications move into deeper territory, the development focus of enterprise-grade Agents has shifted from simple “conversational interaction” to “capability invocation.” Traditional enterprise software in China was long characterized by relative封闭ness, with only a handful of open API interfaces. However, driven by the demand for automated Agent execution, the software ecosystem is undergoing an intense wave of “catching up.” In this process, discussions about how Agents should expose their capabilities have intensified, particularly the growing narrative of “shifting to CLI mode.”

In fact, the so-called “shift to CLI” does not mean the demise of the graphical user interface (GUI)—GUI still plays an irreplaceable role in various business scenarios. The essence of this discussion is a debate over the technical路线 for Agent underlying capability exposure mechanisms: should it be through command-line interfaces (CLI) combined with the Skills pattern, or through standardized protocols (such as MCP, Model Context Protocol) for Tool Call?

I. The Essence of Capability Exposure: API Reshaping and Protocolization

Regardless of the form of exposure, the underlying logic is always the external output of API capabilities. Traditional APIs are primarily designed for developers writing business code, but in the Agent era, the consumer of APIs has become the large model. The large model needs to understand the purpose of APIs, the meaning of parameters, and correctly generate invocation instructions.

This gives rise to two mainstream forms of exposure:

1. MCP mode under HTTP protocol: Encapsulating capabilities as standardized tools, allowing the model to invoke them through the Tool Call mechanism.
2. Skills mode in CLI form: Encapsulating business capabilities as command-line instructions, where the model executes tasks by generating specific command strings.

Neither approach is inherently superior or inferior—the core lies in how to enable the model to understand and trigger these capabilities with lower token costs and higher execution success rates.

II. Pain Points of the MCP Mode: Token Consumption and Context Compression

MCP, as a recently prominent technical solution, is still fundamentally based on JSON Schema-based Tool Call. However, in actual enterprise-level deployment, developers face several thorny underlying challenges.

1. Massive Token Overhead

Mainstream Agents typically insert the raw JSON Schema directly into the system prompt when defining tools. The JSON format contains large amounts of brackets, quotation marks, and descriptive text—this structure itself has extremely high data redundancy. When the number of tools exposed by an enterprise reaches dozens or even hundreds, tool definitions alone can consume tens of thousands of tokens, significantly driving up the cost of each inference.

2. Static Compression of the Context Window

The context window of a large model is limited. Once tool definitions are injected as part of the system prompt, that space is statically occupied. This means the dynamic space available for actual user input, historical conversation memory, and processing of tool return results is severely compressed, directly impacting the model’s performance in multi-turn complex tasks.

3. Lack of Intelligent Lifecycle Management

Current mainstream Agent frameworks lack dynamic scheduling capability for MCP tool invocation. The model cannot independently decide to enable or disable certain tool sets based on the context of the current task. Ideally, an Agent should have a mechanism similar to “MCP AI routing” that precisely loads tools based on user intent. But in reality, most solutions still adopt full loading, resulting in low cold-start hit rates. Even with caching mechanisms introduced, the cache hit rate remains unsatisfactory due to the lack of dynamic context matching.

III. Optimization Strategies and Practical Approaches

To address the aforementioned pain points, developers building enterprise-grade Agents need to pursue deep optimization starting from the underlying architecture and engineering practices.

1. Lightweight and Compressed Tool Definitions

Abandon the practice of directly inserting lengthy JSON Schemas, and instead compress and optimize tool definitions. This can be achieved through:

• Semantic simplification: Remove unnecessary default fields from JSON Schema, and use short, semantically clear function names and parameter names.
• Layered description: In the system prompt, provide only the tool name and a one-sentence functional summary. When the model determines that a tool is needed, detailed parameter schemas are then provided through dynamic injection.

The following is an illustrative comparison of lightweight tool definitions:

// Traditional verbose definition
{
  "name": "query_cloud_storage",
  "description": "Query the object storage service to get a list of files in a specific bucket",
  "parameters": {
    "type": "object",
    "properties": {
      "bucket_name": {
        "type": "string",
        "description": "The name of the bucket to query"
      },
      "prefix": {
        "type": "string",
        "description": "The prefix of the keys to query"
      }
    },
    "required": ["bucket_name"]
  }
}
// Compressed definition
{
  "name": "get_files",
  "desc": "List files in object storage bucket",
  "params": "bucket:string(required), prefix:string(optional)"
}

2. Building a Dynamic Tool Router Mechanism

To solve the problems of context compression and low cache hit rates, enterprise-grade Agents should introduce a dynamic routing layer. The core approach is as follows:

• Intent recognition and intent clustering: Before the main Agent executes, deploy a lightweight routing model or a rule-based routing engine.
• On-demand loading: The routing engine identifies the business domain (such as storage management, monitoring and alerting, etc.) based on the user query, and dynamically concatenates only the Tool Schema relevant to that domain into the context.
• Cold-start optimization: By establishing a cache mapping high-frequency task intents to tools, when users input similar instructions, the corresponding tools can be pre-loaded directly, improving the success rate of first responses.

3. Properly Assessing the Applicable Boundaries of CLI and MCP

When building complex Agents, one should not be limited to a single mode but should flexibly choose based on scenario characteristics:

• Scenarios suitable for CLI/Skills mode: For tasks that require batch execution, chained operations, or interaction with underlying infrastructure (such as container platforms or operating system-level operations), the CLI mode is superior. The model only needs to generate syntactically valid command strings, and the executor takes over subsequent operations, greatly reducing the model’s reasoning burden for complex parameter structures.
• Scenarios suitable for MCP/Tool Call: For scenarios that require interaction with external SaaS services or general HTTP APIs, where parameter structures are complex and fine-grained validation is needed (such as sending messages via a message queue or querying a logging service), MCP’s JSON Schema provides better parameter constraints and error prompts.

IV. Conclusion

Enterprise Agent capability exposure is not simply a matter of “CLI replacing GUI” or “MCP replacing CLI”—it is an inevitable stage in the evolution of the API ecosystem toward intelligence. The token consumption and context compression problems currently faced by the MCP mode are essentially a reflection of engineering architectures not being refined enough when dealing with the characteristics of large models.

In practice, developers should not only focus on engineering optimization methods such as context compression and dynamic routing, but also maintain flexibility in architectural design by combining the standardized interfaces of MCP with the low execution cost advantages of CLI. Only by deeply understanding the capability boundaries of models and the mechanisms of context operation can truly efficient and stable enterprise-grade intelligent agents be built.