carlos-aguilar

Carlos is a Customer Advocate at Auth0, where he helps guide users and developers to find the right solutions for their needs. He has an eight-year professional background in the SaaS and cybersecurity industries, with extensive experience in customer-facing roles such as account management and customer success management. In his free time, he enjoys hiking and actively seeks out opportunities for outdoor activities and sports.

Customer Advocate

Carlos Aguilar

Audit your Auth0 tenant’s security and configuration, assess capability and plan fit, and generate a personalized report with prioritized recommendations for B2C, B2B, or internal applications.


Audit Your Auth0 Tenant with Auth0 Agent Skills

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Learn the critical differences between AI tools, MCP servers, and skills to build more capable, secure, and standardized AI agents.

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](https://www.linkedin.com/posts/jason-lopatecki-9509941_why-skills-are-exploding-and-mcp-is-already-activity-7443091557408219136-R617), and [others aren't convinced of the usefulness of MCP](https://www.reddit.com/r/mcp/comments/1kkyajj/could_you_explain_how_mcps_are_different_and/) 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](https://developers.openai.com/api/docs/guides/function-calling), [Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview), or [Gemini](https://ai.google.dev/gemini-api/docs/function-calling) 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](https://docs.anthropic.com/en/api/getting-started), 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:

```python
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)](https://modelcontextprotocol.io/) 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](https://modelcontextprotocol.io/specification/2025-11-25/client/sampling), 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: 

![Diagram showing the flow for a purchase refund AI skill](https://images.ctfassets.net/23aumh6u8s0i/5MtOpUxsRGt5wpXxjk2vai/91a8d1587c42e879e63a116f7820a33a/refund-flow-ai-skill.png)

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](https://agentskills.io/) gaining adoption across AI coding tools. The refund scenario above could be expressed as in the following example:

```md
---
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:

![Table showing the architectural layer, scope, and security considerations for AI tools, MCP servers, and skills.](https://images.ctfassets.net/23aumh6u8s0i/6itvWszwqLr5KWd14MRpPC/a7a77a67089227a3d2c12e103111003d/ai-tools-mcp-servers-skills.png)

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](https://owasp.org/www-community/attacks/PromptInjection) (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**](https://owasp.org/www-community/attacks/MCP_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](https://modelcontextprotocol.io/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](https://auth0.com/ai/docs) 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](https://auth0.com/blog/auth0-auth-for-mcp-servers-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](https://auth0.com/blog/how-to-fix-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](https://auth0.com/ai/docs) covers authentication, delegation, and human-in-the-loop authorization patterns.

What AI Tools, MCP Servers, and Skills Actually Do

Bharath Natarajan

Bharath Natarajan is a Senior Product Manager at Auth0, where he leads the developer platform strategy and evolution of SDKs, MCP Server and CLI tools. Operating at the critical intersection of developer experience and enterprise security, he is passionate about modernizing integration pathways and building intuitive tools that empower developers to seamlessly build, scale, and secure their applications.

Senior Product Manager

Auth0 Agent Skills are now available, giving AI coding assistants the knowledge to implement Auth0 correctly across any framework

"agent skill"