MCP vs Skills vs Tools vs Subagents: What Differs, and How the 2026 AI Agent Stack Is Changing

Bottom line: Tools, MCP, Skills, and Subagents are not four interchangeable product names — they are four different layers in the 2026 agent stack. Tools are the callable contracts the model sees (name + JSON Schema). MCP is the discovery and invocation protocol between a Host and external tool processes. Skills are on-demand procedural playbooks (how to get work done). Subagents are delegated agents with their own context. Collapsing them into one buzzword means you will debug the wrong layer.

Written as of 11 September 2026. We already covered what MCP is, the Agent JSON data flow, and JSON Schema as a contract. This piece only answers: what each layer owns, how they stack, and where the 2026 stack is converging.

Four layers at a glance

When people say “add a tool to the agent,” they often mean four different things. Map the phrase to this table:

One sentence: Tools are “what can be called”; MCP is “where tools come from”; Skills are “how this job is done”; Subagents are “who does it, in which context.” JSON Schema cuts across Tools and MCP; Skills and Subagents mostly govern prompts, policy, and session boundaries.

Tools: the call contract in front of the model

A Tool (or Function) is the smallest callable unit the model sees. Vendor names differ — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — but the shape is the same: you declare tools; the model returns structured tool_calls; the Host runs them and writes results back into the chat.

A tool definition usually looks like this:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

What actually constrains behavior is JSON Schema: field names, types, required, additionalProperties. Models can change; the Schema should not drift with them. See why Tool Calling depends on JSON Schema for the validation discipline. Here the point is simply: a natural-language tool blurb without Schema is no longer a production contract in 2026.

The Tools layer boundary is sharp: it does not decide whether the implementation runs in-process or remotely, and it does not decide how multi-step work is split. Those belong to MCP and to Skills / Subagents.

MCP: the cross-process tool socket

MCP (Model Context Protocol) answers how tools and context are discovered and invoked outside the Host process. Messages are JSON-RPC 2.0; common methods include tools/list, tools/call, plus Resources / Prompts. An MCP Client inside the Host (Cursor, VS Code, Claude Desktop, …) connects to an MCP Server and translates exposed tools into the Tools array the model understands.

The correct stack is:

1. The MCP Server describes each tool with inputSchema (still JSON Schema);
2. The Host calls tools/list and maps results to model Tool declarations;
3. The model emits tool_calls;
4. The Host issues tools/call to the Server and writes result back into the dialogue.

Calling MCP “another Function Calling” is the most common 2025–2026 misread. Function Calling sits at the model API boundary; MCP sits at the Host ↔ Server boundary. The current spec is 2026-07-28: no session handshake; requests carry _meta. Details: MCP guide and migration guide.

When you do not need MCP: one process, tools hard-wired into the Host, no cross-app reuse — Tool Calling alone is enough. When you do: reuse the same Server across IDEs / desktops, process isolation, dynamic tool discovery.

Skills: reusable how-to playbooks

A Skill is not another tool — it is procedural knowledge the agent can load on demand: when to activate, which steps to follow, what to check, which tools may be used. In engineering form it is often a repo SKILL.md (or equivalent rule pack): title, trigger conditions, checklist, prohibitions, related script paths.

Versus Tools / MCP:

In 2026, IDE agents treat Skills as first-class: short tasks use built-ins; long flows, team norms, and ops playbooks live in Skills so you do not paste the whole handbook into the system prompt every time. A Skill can steer which Tools to call and enforce gates like “validate JSON before submit” — but it is usually not a JSON-RPC method.

A common mix-up: a packaged shell script labeled both Skill and Tool. Rule of thumb — if the model calls it once via Schema and gets a structured result, it is a Tool; if a document tells the agent “follow these five steps, call tools when needed,” it is a Skill.

Subagents: delegation with isolated context

A Subagent is a child session the parent delegates to: usually its own context window, a narrower system prompt, a tighter tool allowlist, and a summary returned to the parent. It does not add “one more function”; it fights context pollution and enables parallel exploration.

Typical uses:

• Isolated retrieval — the child digs through the repo or logs; the parent only keeps the conclusion.
• Parallel work — frontend changes, tests, and copy translation run without fighting over one context.
• Narrow roles — security review, code exploration, CI diagnosis each get their own prompt and tools.

In practice, a Subagent is often exposed to the parent as a special Tool (e.g. Task / spawn_agent): arguments are the task description and type; the return is the child’s final answer. That does not mean Subagent = Tool. The Tool is the call surface; the Subagent is another stateful reasoning loop.

Versus Skills: a Skill says “how”; a Subagent decides “open another session to do it.” A Skill may require “complex triage must spawn the CI Subagent”; that Subagent then loads its own Skills and Tools.

How the four layers stack

A real task often uses all four. Example: “write a blog post and deploy” (illustrative, not this site’s private protocol):

1. The parent loads a Skill — “blog publish checklist”: body, locales, sitemap, IndexNow.
2. The parent calls a Subagent to explore historical article templates so dozens of HTML files never enter the main context.
3. The main session edits the frontend via Tools (read/write files, shell); if tools live out-of-process, discovery and calls go through MCP.
4. Wherever structured parameters appear, JSON Schema still pins the fields — especially for anything that leaves the machine.

Data flow in one line:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Debug cheat sheet: model calls the wrong tool → Tools / Schema; tool process will not connect → MCP; steps keep getting skipped → Skill; context blows up or contaminates → Subagent.

What is changing in the 2026 agent stack

Compared with 2024’s “stuff functions into the prompt,” 2026 compresses into five shifts:

Another thread is structured outputs merging with tool arguments: business JSON, tool arguments, and MCP inputSchema all share the same Schema discipline. See what structured output is and the OpenAI vs Gemini comparison.

On the product side, IDE agents are no longer “chat + autocomplete” only: the default stack includes tool calling, MCP connectors, a Skills directory, and spawnable subagents. For builders that means you ship more than an API — discoverable tools (MCP/Tools) + followable workflows (Skills) + roles you can delegate when needed (Subagents).

What to choose and write now

• Write the Schema before you expose the tool. Set additionalProperties: false, fill required; validate sample arguments in the browser with this site’s tools.
• Wrap an MCP Server only when tools must be reused across apps. A single script embedded in one Host does not need MCP.
• Encode repeated team workflows as Skills. Publish, migrate, triage, security review — if the steps are stable, stop relying on “remember to remind the model.”
• Split a Subagent when context gets long. Prefer delegating exploratory, read-only, high-noise work; keep decisions and final patches in the parent.
• Do not replace Schema with a Skill, or MCP with a Subagent. Process ≠ contract ≠ transport. Mixing them produces “the doc says validate” while production never runs the check.

For local JSON checks, save inputSchema, model argument samples, and MCP tools/call result samples, then use the JSON validator and JSON Diff. Nothing leaves the browser — the same on-device-first privacy instinct.

FAQ

Summary

Tools define what the model can call; MCP defines how tools are discovered and invoked from outside processes; Skills define how work is done by the book; Subagents define how context is isolated and delegated. The 2026 agent stack is converging from “one chat box + ad-hoc functions” into these four layers plus a JSON Schema contract belt.

Grow the stack from the inside out. Get Schema and Tools right first; then add MCP, Skills, or Subagents under pressure from reuse, process, or context. Validate samples locally before you ship — models can change; field names and required should not.