I remember being very confused when I first heard about an LLM's ability to request code execution. This feature has been called various names: tool, action, plugin, function. Now the terminology is settling on a single name: tool. However, talking to other developers and reading comments online, I see the confusion has shifted elsewhere. Some argue that, with the introduction of skills by Anthropic, MCP no longer makes sense, and others aren't convinced of the usefulness of MCP compared to direct tool calls.

The confusion is architectural. Tools, MCP servers, and skills solve different problems at different layers.

AI Tools Are the Model's Swiss Army Knife

At the most fundamental level, an AI tool is a function that a language model can decide to call. Not a metaphor for "capability" in general, but a specific, callable function with a defined input schema and a predictable output.

When a model needs information or an action it can't produce from training alone, it generates a structured call to a tool: something like "call get_customer_record with customer_id: 12345." The host application intercepts that call, runs the actual function, and returns the result to the model. The model then incorporates it and continues.

While the tool calling concept is the same across the different LLMs, each one has its own specifications to invoke tools. Check out OpenAI, Claude, or Gemini documentation for some specific examples.

Tools are what give AI its "hands." Without them, a model is impressively articulate but isolated from live data and the systems where real work happens. With them, it can search databases, call APIs, send messages, or trigger business logic in response to what a user needs.

The key property to hold onto: a tool should know how to execute one thing. It doesn't decide when to be called. That judgment belongs to the model, or in more complex systems, to something above it.

Here's what that looks like in code. Using the Anthropic SDK, you define a tool as a JSON schema: its name, a description the model uses to decide when to invoke it, and the inputs it expects:

import anthropic
​
client = anthropic.Anthropic()

tools = [{
   "name": "get_customer_record",
   "description": "Retrieve a customer's account details by ID",
   "input_schema": {
       "type": "object",
       "properties": {
           "customer_id": {"type": "string", "description": "The unique customer identifier"}
       },
       "required": ["customer_id"]
   }
}]

response = client.messages.create(
   model="claude-opus-4-6",
   max_tokens=1024,
   tools=tools,
   messages=[{"role": "user", "content": "Look up customer C-12345"}]
)

# When the model decides to use the tool, it returns a structured tool_use block
tool_use = response.content[0]
print(tool_use.name)   # get_customer_record
print(tool_use.input)  # {"customer_id": "C-12345"}

A few things to notice:

• description: This is what the model reads to decide whether to call the tool. A clear, accurate description matters more than the schema itself.
• input_schema: The structured contract. The model generates arguments that conform to this schema when it decides to invoke the tool.
• tool_use block: What the model provides when it wants to call a tool. Your application handles the actual execution and passes the result back in the next turn to continue the conversation.

The model never runs the function itself. It produces a structured intent. Your application does the work.

MCP Servers Are the Universal Translator

At first glance, an MCP server might look like a more elaborate way to define tools. In practice, it solves a different problem.

The Model Context Protocol (MCP) is an open standard that introduces a protocol layer between AI applications and the services they connect to. Think of it as USB-C for AI: a universal connector that lets any compliant client communicate with any compliant server, regardless of which model runs underneath.

Without MCP, every AI application builds its own integrations: a custom function schema for one client, a different one for another, yet another for whichever agent framework a team has chosen. The same capability gets re-implemented for each consumer. MCP exists to eliminate that duplication.

Here's how the architecture works:

• MCP clients are the components that hosts (i.e., AI applications such as Claude Desktop, a VS Code extension, a custom agent, etc.) instantiate to initiate connections to servers.
• MCP servers expose three types of primitives:
  • Tools: actions the AI can invoke.
  • Resources: data the AI can read.
  • Prompts: pre-built interaction templates.

The MCP transport layer is equally flexible. The protocol runs over standard I/O for local processes, or HTTP with Server-Sent Events for remote services, using OAuth 2.1 for authentication on remote connections.

What makes MCP structurally different from direct tool definitions is decoupling. A tool definition embedded in a model API call is tightly coupled to that application. An MCP server is portable: the same server works across any compliant client. Build a GitHub integration once, connect it everywhere.

There's also the matter of bidirectionality: an MCP server can request that the AI client sample from the language model, enabling interactions that go beyond a simple request-response pattern like an API. It's a more symmetric relationship than direct function calling, which flows strictly from model to function.

AI Skills Direct the Work

Skills occupy a different layer from tools and MCP servers entirely.

Where a tool is a capability and an MCP server is the infrastructure for exposing it, a skill is closer to a recipe: higher-level instructions that tell an AI when and how to use its available capabilities to accomplish a complex goal. A skill doesn't replace tools. It orchestrates them.

In practice, a skill combines three things:

• System prompts: Instructions that define a persona and a set of constraints.
• Logic/Workflows: A series of steps the model should follow.
• Tool selection strategy: Knowing which tool to pick in a specific sequence to achieve a complex goal.

Consider a customer support scenario. Handling a refund request might involve checking the customer record, looking up the original transaction, verifying return eligibility based on policy, and then either initiating the refund or escalating to a human, as shown in the following diagram:

Each step might invoke a different tool. The skill is the framework that defines the sequence, the conditions, and the decision points. Skills carry the domain knowledge and reasoning structure that raw tool access doesn't provide.

Anthropic formalized the skills concept for Claude Code, and the format is now an open standard gaining adoption across AI coding tools. The refund scenario above could be expressed as in the following example:

---
name: handle-refund-request
description: "Handle a refund request from the user."
---

You are a customer support agent for Acme Corp.
You have access to: `get_customer_record`, `get_transaction`,
`initiate_refund`, `escalate_to_human`.

When a user requests a refund:

1. Verify the account with `get_customer_record`
2. Retrieve the purchase details with `get_transaction`
3. If the purchase was within 30 days and its amout is less than $500, call `initiate_refund`
4. For amounts over $500, always escalate regardless of purchase date
5. If ineligible, call `escalate_to_human` and explain why
​
Never approve a refund without completing steps 1 and 2 first.

Compare this to the tool definition from the previous section. The tool schema said nothing about when to be called, what order to follow, or what to do when an amount exceeds a threshold. The skill encodes all of that:

• Available tools: The skill names the specific tools relevant to this task, not everything the agent has access to.
• Sequence and conditions: Steps 1–5 define the order and the branching logic.
• Guard rails: "Never approve without completing steps 1 and 2" is judgment the tools themselves can't encode.

The tools handle execution. The skill handles when, in what order, and under what conditions.

The distinction from tools becomes clearest at the boundary between capability and judgment. A tool knows how to execute a database query. A skill knows when a query is the right mechanism versus, say, asking a user for clarification first. That's the bridge skills provide: from what an AI can do to what it should do in a given scenario.

Key Differences at a Glance

The distinction between tools, MCP servers, and skills lies in their architectural layer, scope, and security considerations:

• Definition and scope: A tool is a fundamental capability, defined as a single, specific callable function that the model can invoke via its API schema. Above this is the MCP server, which acts as a standardized protocol server. It exposes a collection of capabilities, including actions, data, and prompts, which are used by AI clients via the MCP protocol. The highest layer is the skill, which is not a capability but a set of instructions guiding AI behavior toward a complex goal, managing a multi-step workflow or domain reasoning through the agent's orchestration layer.
• Coupling and portability: Another key difference is portability. Tools are tightly coupled to the application they are defined within. In contrast, MCP servers are portable, designed to work across any compliant client, making them a universal connector. Skills are specific to the particular task or domain they are designed for.
• Security surface: Each layer presents a distinct security surface. Security for tools focuses on function-level permissions. MCP servers manage risk through protocol-level consent and capability negotiation. Skills introduce behavioral guardrails and decision boundaries, controlling the overall logic and sequence of actions to ensure appropriate conduct.

The following picture summarizes these distinctions:

The relationship is hierarchical: skills direct what to accomplish, tools do the work, and MCP servers are the infrastructure that makes tools available consistently. None of the three replaces the others.

A Security Perspective

Each layer introduces distinct security considerations, and they compound when combined.

At the tool layer, the core risk is over-permission. A tool that can read and write to a database, when the AI only needs to read, creates unnecessary exposure. Prompt injection attacks (where malicious content in retrieved data tricks a model into taking unintended actions) are most damaging when tools have broad permissions. The principle of least privilege applies here as directly as it does anywhere in security engineering.

At the MCP server layer, the attack surface expands because MCP servers are external processes, often network-accessible, and connected to by multiple clients. The risks here include:

• Tool poisoning: A malicious or compromised server exposes functions that look legitimate but behave maliciously when called.
• Unauthorized access: Without proper authentication, any client could invoke a server's capabilities, including sensitive ones.
• Scope creep: Servers that expose more than intended, by design or misconfiguration, give connected clients broader access than warranted.

The MCP specification addresses this through explicit consent requirements and capability negotiation, but correct implementation is the server author's responsibility. Remote MCP servers should require OAuth 2.1-based authentication, and permissions granted to any connection should follow the least-privilege principle.

To mitigate risks in both tools and MCP servers, apply the following:

• Strict Scoping: Never give an AI tool a "God Mode" API key. Use scoped tokens that only allow the specific actions required for that tool.
• Human-in-the-Loop: For high-stakes tools (like making a payment or deleting data), always require an approval from the user before the application executes the model's tool call.
• Input Validation: Treat every argument generated by an LLM as untrusted user input. Validate the types, ranges, and permissions before hitting your backend.

At the skills layer, the risks become behavioral. Skills that don't account for adversarial inputs, that allow irreversible actions without human confirmation, or that chain too many autonomous steps without a checkpoint are dangerous in a specific way. By the time someone can intervene, the damage is done.

Auth0 for AI Agents addresses several of these challenges at the identity layer. Based on standards, it provides support for user authentication, delegation patterns for acting on a user's behalf, and asynchronous authorization for scenarios where sensitive operations need human sign-off before proceeding. Auth0's MCP support, now generally available, provides OAuth 2.1-based authentication for MCP servers.

The underlying principle is familiar from traditional IAM: identity infrastructure doesn't fundamentally change because the client is an AI, but the patterns for applying it need to account for how agentic systems behave differently.

Three Layers, One System

The shift from AI as a generator to AI as an actor is real, and the architecture that supports it is becoming clearer:

• Tools give AI a way to act on the world.
• MCP servers give it a consistent, portable way to access those actions.
• Skills give it the reasoning framework to act appropriately.

Each layer has its own design considerations, its own security surface, and its own place in a well-structured AI system. Understanding the distinctions is foundational to building systems that aren't just capable, but trustworthy. As the tooling matures, the teams that understand the layers will be the ones building systems they can actually reason about.

For a closer look at the vulnerabilities that emerge in agentic AI, five critical AI agent security risks is a practical next step. If you're working through identity for MCP servers specifically, the Auth0 AI documentation covers authentication, delegation, and human-in-the-loop authorization patterns.