Agent, MCP, Skill, CLI, Model: Concept Map & Three Paths for Legacy AI Integration

Background

A major Chinese automotive group's IT team was tasked with "letting AI penetrate legacy business systems" — not buying a new AI system, but engineering AI into existing systems like leave management, PLM, and internal platforms. The team struggled with concept confusion (Agent, Skill, MCP, CLI, Model) and where to start integration. This article distills a 42-page technical exchange into a practical concept map and decision framework.

Five Concepts as a Digital Team

The author uses a company-team analogy to clarify roles:

Model (LLM) = Brain: reasoning and generation engine, but no hands to touch data.

Agent = Digital Employee: goal-driven, autonomous planning, tool-calling loop (perceive, plan, act, observe, re-plan). Agent is a system; Model is just one component.

Skill = Job Skill Manual: packages processes, domain knowledge, and tool lists into versioned, engineering-grade SOPs — not just a prompt.

MCP (Model Context Protocol) = Universal Adapter: open standard connecting Agent to any external system (DB, API, file, device) via a unified interface.

CLI = Walkie-Talkie: structured command channel for both engineers and Agents; clear instructions, explicit receipts, auditable.

Key nesting relationship: an MCP Server often wraps a CLI internally. Agent sees only the standard MCP shell; it doesn't care whether the backend is CLI, API, or script. CLI governs tool execution; MCP governs standardized exposure to AI.

Collaboration Flow: A Tool-Call Relay

User says: "Check my leave records from last week." The relay:

User input via CLI/chat entry.

Agent receives goal, delegates planning to Model.

Model identifies need to query HR system; Skill provides standard procedure.

Agent loads Skill, finds required tool, calls via MCP to Leave MCP Server.

MCP Server calls legacy REST API.

Results return back up the chain; Agent replies in natural language: "You took 2 days annual leave last week, 8.5 days remaining."

Mapping to traditional software:

Microservice → Agent

OpenAPI/REST → MCP

Internal Wiki/SOP → Skill

SDK/Command Line → CLI

Three Integration Paths for Legacy Systems (Decision Tree)

First, assess four dimensions: API openness, documentation completeness, auth system, change-risk tolerance. Then follow priority order:

API → MCP Wrapper (Preferred) : System has open REST API. Add thin MCP Server layer doing only protocol translation, zero business logic changes. Minimal invasion, stable, supports canary release.

CLI → MCP Wrapper (Secondary) : No API but has CLI/ops scripts. Wrap scripts into structured CLI (JSON output preferred), then wrap with MCP. Example: git bash → MCP Server. Requires structured output for Agent consumption.

Browser Automation / RPA (Fallback) : Only web UI remains. Simulate human clicks. Works but brittle — breaks on UI changes. Treat as transitional, not end state.

Priority decreases top to bottom; fragility increases.

Security & auth: no universal standard yet. Identity propagation (user → Agent → system), least privilege, audit, human-in-the-loop for sensitive actions — each system needs custom review. "Whoever promises a ready-made solution hasn't done enterprise-grade deployment."

Prioritization: plot systems on "Usage Frequency × Business Value" quadrant. Start with high-frequency, low-risk, API-available systems. "First battle must be won, and won cheaply."

MCP Implementation Forms (Complete Classification)

Official spec defines only two standard transports (as of 2025-03):

stdio : Host spawns local subprocess via stdin/stdout. Standard for local dev and desktop Agents. Single-machine, single-client, process-level trust.

Streamable HTTP : Single HTTP endpoint; POST for requests, GET for streaming responses. Supports session persistence, reconnection, OAuth 2.0. Official recommended remote deployment for enterprise centralized, multi-tenant sharing.

Legacy (deprecated): HTTP+SSE (dual endpoints) — only for existing migration, never new builds.

Community extensions (transport-agnostic protocol logic unchanged): WebSocket (full-duplex, low latency; browser bridging, e.g., Agent ↔ Chrome extension for browser automation; requires sticky sessions, firewall traversal), WebRTC, in-process RPC.

Deployment architectures (Gateway, Proxy, Hosted MCP) are separate from transport choice.

Selection cheat sheet: local dev → stdio; enterprise sharing → Streamable HTTP + OAuth; SSE → migrate only; WebSocket → real-time & browser scenarios.

Two Real-World Case Studies

Case 1: Leave System (BS Architecture) — Path 1

Java web app with REST API; high-frequency HR scenario.

Pain: 5 clicks to check balance; monthly manual reconciliation.

Fix: MCP Server (Streamable HTTP, centralized) in front of REST API; integrated with corporate SSO; zero changes to legacy code.

Result: "Book half-day annual leave tomorrow afternoon" — 5 steps → one sentence.

Case 2: PLM System (CS Architecture) — Path 2

Traditional desktop client; no open REST API but has client-side API/SDK.

Pain: Data silos; engineers manually ferry BOM and drawing data between systems.

Fix: Local wrapper service beside PLM client, exposing client API as structured interface, then MCP layer. Session and permissions reuse client's existing login state.

Three Reusable Lessons

Assess first, then pick path — don't hammer everything with the same tool.

Keep wrappers thin; never touch business logic. Thinner wrapper = slower project death.

Treat auth as a first-class project workstream, not an afterthought.

Outcome

Client feedback: concepts clarified, decision tree directly applicable to their inventory. Author's benchmark: a technical exchange succeeds when the counterparty feels "we can do this ourselves."