Skills vs MCP servers vs tool calls
Skills, MCP servers, and tool use all give a model new abilities, but they sit at different layers and it is easy to confuse them. The short version: a tool call is a single function, an MCP server is a live connection that exposes many tools over a shared protocol, and a Skill is a package of instructions and code that Claude reads off the filesystem.
| Mechanism | What it is | Lifecycle | Best for |
|---|---|---|---|
| Skill | Filesystem folder + SKILL.md (instructions + optional scripts) | Reusable across conversations and projects | Domain expertise, multi-step procedures, repeatable workflows |
| MCP server | A service exposing tools over the Model Context Protocol | Persistent connection, stateful | External services, real-time data, shared tools across clients |
| Tool use / function calling | A JSON schema for one function in the API request | Per-request only | Structured input/output for a single operation |
The three compose: a Skill can instruct Claude to call an MCP tool, and an MCP server can be the thing a Skill shells out to. A Skill is the cheapest way to teach Claude a procedure, because its body only enters the context window when the task is relevant.
Anatomy of a SKILL.md
A Skill is a directory whose only required file is SKILL.md. Everything else - reference docs, example files, executable scripts - is optional and loaded lazily.
The YAML frontmatter is small on purpose. The two fields that matter are name (max 64 characters, lowercase letters, numbers and hyphens) and description (max ~1024 characters). The description is the single most important line you write: it is the only text Claude sees for every Skill at all times, and Claude matches your request against it to decide whether to load the rest. State both what the Skill does and when to use it. Claude Code adds optional fields such as allowed-tools (tools the Skill may use without prompting) and invocation controls, but those are extensions on top of the open standard.
Progressive disclosure is the design that makes Skills cheap. There are three levels: metadata (name + description, always loaded, roughly 100 tokens per Skill), instructions (the SKILL.md body, loaded only when the Skill is triggered), and resources (bundled files and scripts, read or executed only when the instructions reference them). A Skill that bundles fifty reference files costs almost nothing in context until one of those files is actually needed - and scripts run via the shell and return only their output, so their source never enters the context window.
Building a web-scraping Skill
A common, high-value Skill gives Claude reliable access to live web content. On its own, an AI agent can only reason over what is already in its context or its training data; a web-scraping Skill lets it fetch a current page, convert it to clean Markdown, and continue. Because a Skill is just instructions plus code, its reliability is inherited entirely from whatever it calls.
This is where the design choice matters. A naive Skill that does a plain HTTP GET works on simple sites and then fails the moment it hits a JavaScript-rendered page or a site behind verification - it silently returns a challenge page instead of content, and Claude has no way to know. A Skill that shells out to a managed web-data API instead inherits that API's residential proxies and real-browser rendering, and gets back clean Markdown ready for the model. The code example below is a minimal SKILL.md that does exactly this against the Scrappey API; the same shape works for any HTTP-callable backend.
Scrappey publishes a ready-made Skill for this (the scrappey-skill repository, auto-discovered by Claude Code and other SKILL.md-compatible agents) alongside a CLI, so you can drop it into .claude/skills/ rather than writing the wrapper yourself.