Hybrid MCP‑Skill Model: Keeping LLM Agent Skills Fresh

While building internal LLM agent tools, the author faced a dilemma: should new capabilities be packaged as a static Skill or exposed via an MCP server? The conclusion was to adopt a hybrid model that blends both approaches, preserving the simplicity of Skills while ensuring they stay current.

Calling external APIs with a Skill

A simple Skill can invoke an external API using curl. The article shows an example where the Skill fetches feedback data from an internal service. When the API evolves—new endpoint, authentication header, or response format—the Skill becomes stale because it is shipped as a snapshot with the Agent. Each Agent retains its own copy, so updates must be pushed and pulled manually; otherwise, agents continue to run the outdated version.

---
name: summarize-feedback
description: >
  Summarizes customer feedback from the last N hours.
Sources: Zendesk tickets, Slack mentions, NPS surveys.
---

curl -s "https://api.internal.company.com/v2/feedback/summary" \
-H "Authorization: Bearer $(cat ~/.config/company/token)" \
-H "Content-Type: application/json" \
-d '{"hours": 24, "model": "sentiment-v3", "sources": ["zendesk", "slack", "nps"]}'

If the API migrates to v3 or adds new sources, the Skill breaks. One mitigation is to force the Skill to fetch its definition from a registry on every call, but this adds latency, requires extra tooling on developer machines, and still lacks a built‑in mechanism in Claude Code to refresh automatically.

The MCP server solves the staleness problem because the call happens on the server side; updating the tool code on the server instantly fixes all Agents. In theory, breaking changes to the MCP tool could affect callers, but in practice the tool name and input schema are part of the list tools response, making the interface self‑describing and resilient.

Hybrid mode: thin CLI layer

To retain the Skill‑like interface while gaining the freshness of MCP, the author proposes inserting a thin CLI wrapper before the MCP call. When the API changes, only the MCP server is updated; every Agent that pulls the Skill immediately benefits because the Skill now merely forwards commands to the CLI.

---
name: summarize-feedback
description: >
  Customer feedback tools via feedback-cli.
Each MCP tool is a CLI command. Run `feedback-cli --help` to list them.
Run `feedback-cli <command> --help` to see the tool's schema.
Run `feedback-cli <command> -d '<json>'` to call it.
---

## Usage

$ feedback-cli --help
Commands:
  summarize-feedback    Summarizes customer feedback from the last N hours.

$ feedback-cli summarize-feedback --help
{
  "name": "summarize-feedback",
  "description": "Summarizes customer feedback from the last N hours.",
  "input_schema": {
    "hours": "integer",
    "model": "string",
    "sources": "array of strings"
  }
}

$ feedback-cli summarize-feedback -d '{"hours": 24, "model": "sentiment-v3", "sources": ["zendesk", "slack", "nps"]}'
{
  "total_tickets": 142,
  "top_themes": ["login timeout", "mobile crash on checkout", "missing invoice PDF"],
  "sentiment": {"positive": 0.31, "neutral": 0.42, "negative": 0.27}
}

In this design, the Skill’s example code may become outdated, but the underlying functionality remains functional because the Agent queries the server for the current schema via --help. The downside is a runtime dependency on the MCP server; if it goes down, the Skill fails. A fallback to a raw curl call can be embedded as a safety net.

The ideal scenario is when the provider ships both a traditional API and an MCP endpoint in the same deployment. The Skill then acts as a thin, zero‑dependency client that forwards to the MCP server, automatically adapts to API changes, and can capture client‑side metrics such as call count, latency, and error rate.