The three layers

Read three blog posts on agentic AI and you will hit three terms that sound related and feel slightly overlapping: functions (sometimes called tools), MCP, and skills. They are related, but they are not the same thing - and they sit at different layers of a working agent.

The short version:

  • Functions are the unit of action - one concrete thing the model can do.
  • MCP is the protocol - the standard wire format that lets any host discover and call those functions.
  • Skills are the unit of know-how - a folder of instructions and scripts that tells the agent how to combine functions into real work.

This article walks each one in turn, then stacks them back together so the relationship is clear.

Functions (Tools)

A function is a concrete, executable action the model can choose to call. In OpenAI's function calling docs they are functions; in Anthropic's tool-use API they are tools; in LangChain, LlamaIndex, and most agent frameworks the word is tool. The vocabulary varies, the idea does not.

Each function has three things attached to it:

  • A name - get_weather, send_email, create_ticket.
  • A schema - the JSON shape of its arguments, usually written as JSON Schema. This is what the model fills in.
  • A description - one to three sentences telling the model what the function does and when to use it. The model reads this every turn to decide whether to call it.

At runtime the model emits a structured function call - a name and an argument object - and the surrounding application is responsible for actually running it and feeding the result back. The model never executes anything itself; it only proposes the call.

The whole layer is mechanical. A function is the smallest useful contract between the model and the world: one verb, one schema, one return value.

MCP - the protocol

Model Context Protocol is the standard that lets agents discover and use functions across applications without bespoke wiring for every pair. The pitch most people repeat: USB-C for agentic AI - one connector, any host, any tool.

Without MCP, every team building an AI feature solves the same plumbing problem twice. The model needs to call out to a database, a ticket tracker, a calendar, a filesystem - and each of those needs a hand-rolled adapter for every host that wants to use it. M models, N tools, M × N integrations. With MCP, the math collapses: build one MCP server for a tool and every host that speaks the protocol can use it.

An MCP server publishes three kinds of primitives:

  • Tools - the functions described above, now discoverable over the wire.
  • Resources - pieces of context the host can pull in (files, rows, pages).
  • Prompts - reusable templates the user can invoke from a slash command.

The key shift is that MCP is not the function itself - it is the standardized way to expose, describe, and call functions. The function still does the work; MCP just gives every host a single shape to ask for it.

Skills - the know-how

Skills are modular folders of instructions, scripts, and reference material that an agent can discover and load on demand. Instead of cramming every workflow into the system prompt or building a specialized tool for each task, a skill bundles how to do something as a portable, version-controlled directory.

A typical skill folder looks like this:

  • SKILL.md - the entry point. Frontmatter says what the skill is for and when to load it; the body is plain-language instructions the model reads.
  • Scripts - small helpers the skill calls out to (a Python file, a shell script, an MCP server config).
  • Reference material - examples, templates, fixtures, style guides, anything the model should consult while working.

The agent loads skills the same way a person consults a runbook - on demand, when the task at hand matches the skill's description. A skill might wrap a sequence of function calls, encode a team's editorial standards, or just collect a few reference documents the model should keep in mind while writing.

Crucially, a skill is not a function and not a protocol. It is a folder - the smallest unit at which expertise becomes portable across projects and across agents.

How they stack

The three layers stack from the bottom up:

  • Functions at the bottom - the verbs the agent can actually run.
  • MCP in the middle - the wire that exposes those verbs to any host that asks.
  • Skills at the top - the playbooks that tell the agent which verbs to use, in what order, for what kind of task.

Each layer is useful without the others, but they get most of their leverage when stacked. A function with no MCP wrapper is fine for a single in-house app. An MCP server with no skill is fine for a model that already knows what to do. A skill that calls nothing is just a structured prompt. Put all three together and you get an agent that knows the work (skills), can reach the systems (MCP), and does concrete things (functions).

A worked example

Imagine a support agent that triages incoming bug reports. The pieces line up like this:

  • Functions - search_issues, create_ticket, tag_ticket, post_to_slack. Each is a single verb against a real system: GitHub, Jira, Slack.
  • MCP - those functions live behind two MCP servers, one for the issue tracker and one for Slack. The host (Claude Desktop, an IDE, a custom agent runtime) connects to both and gets the function list automatically.
  • Skill - a triage-bug-report skill folder bundles the team's actual triage policy: how to phrase the title, which labels to apply, when to escalate, what to post in Slack and where. The skill calls the functions in the right order and in the team's voice.

Swap the model for a different one and the skill still works. Swap the issue tracker and only the MCP server changes. Swap the policy and only the skill folder changes. Each layer evolves on its own schedule.

When to reach for which

A useful rule of thumb for the three layers:

  • Reach for a function when you need the model to do something that has a clear input and a clear output - call an API, read a file, run a query.
  • Reach for MCP when more than one host needs the same set of functions, or when you want a clean separation between the team that owns the system and the teams that use it from inside AI tools.
  • Reach for a skill when you find yourself pasting the same instructions, examples, or reference material into prompts over and over - that is the moment the workflow is portable enough to live in a folder of its own.

Common confusions

Three mix-ups show up over and over.

  • "MCP replaces function calling." It doesn't. Functions are still the unit of action; MCP just standardizes how they are described and exposed. A model still emits a function call, the host still runs it.
  • "A skill is just a long prompt." A long prompt lives inside one conversation. A skill is a folder on disk with a description that lets the agent decide when to load it - portable across sessions, hosts, and teams.
  • "Tools and skills are the same thing." A tool is one verb. A skill is a playbook that uses many verbs (plus reference material) to accomplish something a team cares about. One is atomic; the other is composed.

Why all three matter

Each layer optimizes for a different kind of change. Functions change when the underlying system changes - a new API field, a renamed endpoint. MCP servers change when the boundary between teams changes - who owns this integration, who is allowed to call it. Skills change when the work itself changes - a new policy, a new style guide, a new kind of task the team is taking on.

Build only at one layer and you pay for it at the others. A team that wires everything as raw function calls ends up rewriting integrations for every new host. A team that ships MCP servers with no skills ends up with capable agents that do not know the local rules. A team that writes skills with nothing underneath ends up with elegant prompts that cannot reach the systems they describe.

The point of having three layers is that each one can move at its own pace - which is what makes the whole stack survive the next year of changes in models, hosts, and tooling.

References