Skill vs Tool vs MCP vs API

One nuance worth stating early, because it is the source of most confused arguments. MCP standardises what a server exposes: tools, resources and prompts. A skill is a host- or platform-level packaging convention for instructions, templates and supporting files — it is not an MCP primitive at all. That is exactly why they complement each other. MCP solves a connectivity problem. A skill solves a repeatability problem.

Assume the ask arrives every morning, in this shape:

Generate yesterday’s TikTok Shop GMV report for all stores. Use each store’s local business day, compare with the previous day and the same calendar day last year, and flag missing data.

The desired output is stable, which is the whole reason this is worth engineering:

TikTok Shop GMV Daily Report
Date: 2026-08-29 (store-local date)
 
| Store   | GMV     | Day over day | Year over year | Status       |
|---------|--------:|-------------:|---------------:|--------------|
| Store A | $12,450 |        +8.2% |         +14.6% | Complete     |
| Store B | N/A     |          N/A |            N/A | Data pending |
 
Notes
- Store B: no finalized settlement record at report time.

Now build exactly that, three ways. The figure below is the whole argument in one picture: each version puts the seam in a different place.

In the skill-only version someone exports yesterday’s data to a CSV, or pastes a table into the conversation. The agent has no live connection to TikTok Shop at all.

## Input contract
- Required columns: date, shop_id, gmv
- Interpret “yesterday” in the stated store timezone.
 
## Procedure
1. Identify the requested store-local reporting date.
2. Filter the supplied data to that date and aggregate by shop.
3. Compare with the prior business day and the same date last year.
4. Mark unavailable comparisons `N/A`; never infer a value.
5. Render the approved Markdown table and notes section.

Now expose a function from the application straight to the model. It calls TikTok Shop internally.

const getTikTokGmvYesterday = {
  name: "get_tiktok_gmv_yesterday",
  description:
    "Return a store's GMV for its previous local business day.",
  inputSchema: {
    type: "object",
    properties: {
      shop_id: { type: "string" },
      category: { type: "string" }
    },
    required: ["shop_id"]
  }
};

This is a real improvement. Authentication, query construction and network access now happen in code rather than in a chat window.

For a workflow that several teams depend on, split the responsibility along the seam the first two versions kept crossing.

The MCP server wraps everything that is TikTok-specific: authentication, pagination, rate limits, retries, error normalisation, and a consistent data contract that any approved AI client can discover. Its tool surface should be composable, not report-shaped:

{ name: "list_shops" }
{ name: "get_gmv",   args: shop_id, date_from, date_to, category? }
{ name: "get_reporting_calendar", args: shop_id }

Notice what is absent: no daily-report template, no Slack wording, no escalation rule. Those policies do not belong in a TikTok connector. They belong in the skill:

## Procedure
1. Call `list_shops` unless a shop list was supplied.
2. Per shop, resolve the previous local business date from
   its reporting calendar.
3. Call `get_gmv` for that date, the prior business date,
   and the matching date last year.
4. Compute percentage changes deterministically. A zero
   denominator or an incomplete response renders as `N/A`,
   with the reason stated.
5. Emit the approved table, then an exceptions-only notes
   section.
 
## Guardrails
- Never mix store-local dates inside one comparison.
- Never invent a missing value.
- Preserve column order and currency formatting.

The payoff is that the system can now evolve without everything changing at once. Each kind of change has exactly one home — which is what the right-hand column of the first figure was showing.

MCP + Skill is not automatically the right first implementation. If one internal app needs one read-only lookup, a direct tool is the sensible answer and the extra layer is ceremony. The architecture earns its keep when the same connection will serve multiple workflows, multiple clients, or a meaningful amount of operational policy.

Can one MCP server support several skills? Can one skill use several servers?

Yes to both, and that is usually the cleanest topology. One tiktok-shop server might serve a daily GMV report skill, a product-health-check skill and a campaign-performance skill — the same trustworthy connection, three different workflows and output standards. Conversely one “cross-border daily operations” skill might orchestrate a TikTok server for GMV, a Shopify server for direct revenue, a project-management server for incident status, and a messaging server to deliver the result.

When do I write a skill, add a tool, or build a server?

Does the task need live data or an external action?
├── No  → Start with a Skill.
│         Capture the procedure, the checks, the format.
└── Yes → Already available through a suitable MCP server?
          ├── Yes → Use its tools. Add a Skill if
          │         consistency matters.
          └── No  → Is this a reusable atomic action?
                    ├── One app only → a direct Tool.
                    └── Many clients → an MCP server.
 
Any multi-step workflow with rules, decisions or a
prescribed deliverable → add a Skill on top,
whichever branch you took.

Does the model see the tool schema, the skill text, or both?

Both, in some form. The tool definition gives the model the name, description and input schema it needs to select and invoke an action. The skill content supplies the sequence, the business rules, the stop conditions, the validation and the output format.

The loading mechanism is host-dependent — a platform might load every enabled tool at session start, select a subset dynamically, or fetch a skill only when its description matches the request. Do not design against any one platform’s hidden prompt layout. Design against the distinction itself.