Skills vs Tools vs MCP

A language model can only read and emit tokens; it cannot query a database or send an email. A tool is the convention by which the model emits a structured request to run a named function with named arguments — and the application, not the model, runs it. As Anthropic puts it, “Tool use is a contract between your application and the model… The model never executes anything on its own. It emits a structured request, your code (or Anthropic's servers) runs the operation, and the result flows back into the conversation.” Google states the same plainly: “The Model doesn't execute the function itself. It's your application's responsibility.”

Sources: platform.claude.com · How tool use works · platform.openai.com · Function calling · ai.google.dev · Function calling.

A tool is defined by three things: a name, a natural-language description, and a JSON-Schema for its inputs (Anthropic calls the field input_schema; OpenAI and Google call it parameters). All three major providers converge on exactly this primitive.

{
  "name": "get_weather",
  "description": "Get the current weather in a given location",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City and state, e.g. San Francisco, CA" }
    },
    "required": ["location"]
  }
}

When the model decides a tool is needed, it returns a structured call — a tool name plus JSON arguments. Anthropic signals this with stop_reason: "tool_use"; OpenAI returns the call(s) in a tool_calls array on the assistant message. It does not run anything.

Your application parses the arguments, runs the real function, and sends the result back as a new message; the model then continues or calls another tool. Anthropic's documented loop: send tools + message → model returns tool_use → execute and format tool_result → send back → repeat while stop_reason is "tool_use".

MCP is “an open-source standard for connecting AI applications to external systems.” Its own analogy: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.” Crucially, MCP is not a capability — it is the connective layer that carries capabilities. The spec is explicit that it “focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context.”

Sources: modelcontextprotocol.io · Introduction (definition + USB-C analogy) · modelcontextprotocol.io · Architecture (“focuses solely on the protocol for context exchange”) · anthropic.com · Introducing the Model Context Protocol.

MCP follows a client-host-server architecture. The host is the AI application coordinating everything; it creates one client per server, and each client communicates exclusively with that server; each server exposes capabilities. Servers can be local subprocesses or remote services. Revision 2026-07-28 has no protocol-level sessions.

An MCP server can offer three things, distinguished by who controls them:

// Server primitives (modelcontextprotocol.io)
"tools":     Functions for the AI model to execute     // model-controlled
"resources": Context and data for the user or model    // application-controlled
"prompts":   Templated messages and workflows          // user-controlled

Note the nesting that often causes confusion: a “tool” is one of MCP's primitives. An MCP server is, among other things, a delivery mechanism for tools. MCP didn't replace tools; it standardized how they (and resources and prompts) are discovered and called.

Messages are JSON-RPC 2.0. Revision 2026-07-28 removes the initialize handshake and protocol-level sessions: every request carries its protocol version and client capabilities in _meta, and servers implement server/discover. Operations include tools/list and tools/call (plus resources/list and prompts/list). The two current transports are stdio (server as a subprocess) and POST-only Streamable HTTP; the older HTTP+SSE transport remains only during its formal deprecation window. Authorization is optional, but when used with Streamable HTTP the specification defines an OAuth 2.1 profile.

“Agent Skills are modular capabilities that extend Claude's functionality. Each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant.” Where a tool is one callable function and MCP is the connection, a skill is procedural knowledge: the workflows, context, and best practices that “transform general-purpose agents into specialists.” Anthropic's mental model is an onboarding guide for a new hire — you're not giving the agent a new hand, you're teaching it how to do the job.

Sources: platform.claude.com · Agent Skills · Overview · anthropic.com · Equipping agents for the real world with Agent Skills · anthropic.com · Introducing Agent Skills.

At its simplest, a skill is a directory containing a SKILL.md file that must begin with YAML frontmatter carrying two required fields, name and description, followed by the instructions. It can bundle additional markdown, reference files, and executable scripts.

pdf-skill/
├── SKILL.md          # required: frontmatter + instructions
├── FORMS.md          # additional instructions, loaded as needed
├── REFERENCE.md      # detailed reference, loaded as needed
└── scripts/
    └── fill_form.py  # run via bash; code never enters context

# SKILL.md frontmatter:
---
name: pdf-processing
description: Extract text and tables from PDF files, fill forms, merge documents.
  Use when working with PDF files or when the user mentions PDFs or forms.
---

Skills stay cheap because the agent loads them in stages — “progressive disclosure: Claude loads information in stages as needed, rather than consuming context upfront.” The documented three levels:

A skill can include code for the agent to execute as a tool at its discretion. When a bundled script runs, “the script's code never loads into the context window. Only the script's output… consumes tokens.” This provides determinism — sorting a list with a real sorting algorithm beats generating it token by token — which is why skills run inside a code-execution environment.