The agent ecosystem has a terminology problem that masks a real architectural choice. "Tools" and "skills" get used interchangeably in marketing decks and conference talks, but they represent fundamentally different approaches to extending agent capabilities. Understanding this distinction is the difference between building agents that work in demos versus agents that work in production.
But here's the uncomfortable truth that gets lost in the semantic debates: from the agent's perspective, it's all just tools. Skills, toolkits, functions, MCP servers: they all end up as options presented to the model with a description and a way to invoke them. The distinction matters for how you organize and build capabilities. It matters far less than whether those capabilities can actually execute securely in production.
The core distinction: execution versus expertise
A tool is an executable function with defined inputs, outputs, and side effects. When an agent calls a tool, something happens in the world: a database gets queried, an API gets hit, a file gets written. Tools are the hands of an agent that do things.
A skill is packaged expertise that shapes how an agent thinks and approaches problems. Skills don't execute code directly; they provide context, instructions, domain knowledge, and behavioral patterns that make agents better at specific tasks. Skills are the training of an agent that knows things.
The distinction determines your architecture, your deployment model, your security surface, and ultimately whether your agent can do useful work.
How the major players define these concepts
Anthropic draws the sharpest line between tools and skills. Their Model Context Protocol (MCP) handles tools – executable functions exposed via a client-server architecture using JSON-RPC 2.0. Separately, their Agent Skills feature provides what they describe as "composable resources for Claude, transforming general-purpose agents into specialized agents." Skills are organized as folders containing instructions, templates, scripts, and reference materials that agents discover and load dynamically. Crucially, skills extend Claude's capabilities without requiring MCP's protocol overhead, essentially sophisticated prompts with associated files.
OpenAI doesn't formally use "skills" terminology. Their paradigm is tools all the way down. Function calling lets models generate structured arguments that match developer-defined schemas, and their evolution from "functions" to "tools" (December 2023) signaled intent to support multiple capability types beyond just callable functions. The Agents SDK provides orchestration, handoffs, and guardrails, but the unit of capability remains the tool.
LangChain uses a three-tier hierarchy: tools are functions that agents can invoke; toolkits are collections of related tools for a common purpose; and agents combine LLMs with tools in reasoning loops. Like OpenAI, LangChain doesn't formally distinguish skills from tools. The bind_tools interface works identically across providers, treating everything as callable functions regardless of the underlying complexity.
Why this distinction actually matters
The tools-versus-skills divide maps to a deeper architectural question: where does agent intelligence live?
In a tools-heavy architecture, the agent is relatively generic. Intelligence comes from well-designed tools with clear interfaces. The agent's job is tool selection and orchestration. This is the OpenAI and LangChain model: give a capable model good tools and let it figure out how to use them.
In a skills-heavy architecture, intelligence is baked into the agent itself through specialized knowledge and behavioral patterns. Tools become simpler utilities; the agent knows how to approach problems in specific domains. This is the Anthropic's Agent Skills model: the agent carries expertise, not just capabilities.
The practical implications are significant:
Token economics favor skills. Anthropic's own engineering team discovered that one GitHub MCP server can expose ninety-plus tools, consuming over 50,000 tokens of JSON schemas before the model starts reasoning. Skills, being prompt-based, can encode domain expertise without the schema overhead. Their "Code Execution with MCP" approach reduced a 150,000-token workflow to roughly 2,000 tokens by having agents write code to call tools rather than loading all definitions upfront.
Security surfaces differ dramatically. Tools require authentication, authorization, and careful scoping of what agents can actually do. Security researcher Simon Willison identified fundamental MCP vulnerabilities including rug pulls (tools mutating definitions after installation) and tool shadowing (malicious servers intercepting calls to trusted ones). Skills, being prompt-based, don't have the same attack surface, but they also can't do anything without tools to execute. And that's the crux: eventually, every useful agent needs to authenticate to external services and take real actions. The vocabulary you use to describe capabilities matters less than whether you've solved that authentication problem.
Portability varies. MCP tools are theoretically portable across any MCP-compatible host. Skills are currently Anthropic-specific. If you're building multi-model agents or want vendor flexibility, tools provide a more standardized interface.
The local tools dimension
Orthogonal to skills-versus-tools is the question of where tools execute. Local tools run on the same machine as the agent (or in a user's environment), while remote tools run on external servers accessed via network calls.
Local MCP servers using standard input/output transport keep data on-device with minimal latency, enabling offline operation and avoiding network dependencies. Remote servers enable zero-setup deployment and shared access across teams but introduce latency and require proper OAuth 2.1 authentication.
This matters more than most teams realize. Local tools can access the user's filesystem, environment variables, and local services. Remote tools require explicit data sharing. The security and privacy implications cut both ways. Local tools have more access but less exposure, and remote tools are more contained but require trusting the server operator.
Here's where the skills-versus-tools debate reveals its limitations: whether you call something a "skill" or a "tool," if it needs to hit Gmail, Slack, Salesforce, or any other authenticated service, you face the same OAuth complexity. Ninety-nine percent of MCP servers today are built for single-user use. The moment you need multiple end-users authenticating to their own accounts (a basic requirement for any production SaaS), the terminology debates become irrelevant. What matters is infrastructure that handles auth properly.
What production teams have learned
The teams actually shipping agents have converged on some non-obvious insights:
Tool design matters more than tool count. Successful coding agents often use fewer than ten tools. The temptation to expose every possible capability backfires with models getting confused, token budgets exploding, and error rates climbing. Anthropic's engineering team found that requiring absolute file paths eliminated a class of errors that plagued agents using relative paths after directory changes. Small interface decisions compound.
Skills fill gaps that tools can't. When Monte Carlo built production agents, they discovered that engineers and data scientists needed to cooperate closely, logging and marking each LLM call to track which agent tasks caused issues. The "skill" here wasn't a tool. It was organizational knowledge about debugging patterns, domain-specific heuristics, and failure modes. This kind of expertise doesn't fit neatly into a function signature.
The framework complexity trap is real. Cognition (Devin) explicitly warns against multi-agent architectures: "In 2025, running multiple agents in collaboration only results in fragile systems." Their recommendation is single-threaded agents with context compression. The most successful implementations aren't using complex frameworks. They're building with simple, composable patterns.
Authorization is the production killer. This is the lesson that doesn't get enough airtime. Teams spend months building sophisticated agent logic, carefully designing tool interfaces, debating skills versus tools architectures. And then hit a wall when they try to ship. The agent can't actually do anything because connecting to real services with real user credentials is a different class of problem entirely. Roughly 70% of AI projects fail to reach production, and authorization complexity is a primary culprit.
A framework for choosing
When should you invest in tools versus skills versus both?
Invest in tools when:
- You need agents to take actions in the world (APIs, databases, file systems)
- You want capabilities that work across different models and frameworks
- The capability is well-defined with clear inputs and outputs
- You need audit trails and access control for what agents can do
Invest in skills when:
- You need domain expertise that shapes how agents approach problems
- Token efficiency matters (complex tools with many options)
- You're building on Claude specifically and can use Agent Skills
- The knowledge is about judgment and approach, not just execution
Invest in both when:
- Building production systems where agents need both expertise and capabilities
- Domains where knowing what to do (skill) is as important as doing it (tool)
- You want skills to guide tool selection and usage patterns
But regardless of which path you choose, invest in authentication infrastructure first. The most elegant skill/tool architecture is worthless if your agent can't securely access the services it needs to act on.
The real takeaway
The skills-versus-tools distinction isn't about picking a winner. It's about understanding that agent capabilities come from two different sources: what agents can do (tools) and what agents know (skills).
The industry's conflation of these concepts obscures a real architectural choice. Teams that treat everything as tools end up with bloated context windows, confused models, and brittle integrations. Teams that invest only in skills end up with agents that think brilliantly but can't actually do anything.
The builders getting this right are thinking carefully about which capabilities belong in which layer. They're keeping tool counts low and interfaces clean. They're encoding domain expertise in skills rather than hoping models will figure it out from tool descriptions. And they're recognizing that the protocol wars (MCP versus function calling versus whatever comes next) matter less than the fundamental question of where intelligence lives in their agent architecture.
But from the model's point of view, everything you give it is just an option to pick from. Whether you call it a skill, a tool, a function, or an MCP server, the agent sees a description and a way to invoke it. The taxonomy matters for your mental model and code organization. It doesn't change what the agent experiences.
What does change the agent's ability to be useful is whether it can actually execute. And that's an infrastructure problem, not a terminology problem.
Where Arcade fits
At Arcade, we've taken a deliberately simple position on the skills-versus-tools debate: they're all tools.
Not because the architectural distinctions don't exist but because from the agent's perspective, everything ends up as an option to select and invoke. The real challenge isn't deciding what to call your capabilities. It's making them work in production with real users, real credentials, and real security requirements.
That's why we built Arcade as an authentication-first runtime. We handle OAuth for 100+ services – such as Gmail, Slack, GitHub, Salesforce, and more – so your agent can take real actions without you building complex credential management. Tokens never flow through the LLM. Authorization happens just-in-time with least-privilege scoping. Whether you're exposing capabilities via MCP, LangChain, OpenAI's SDK, or direct API calls, the auth layer works the same way.
The founding team has spent their careers on identity and infrastructure. When we started building agents ourselves, we hit the same wall everyone hits: the agent was smart, the tools were well-designed, but actually connecting to services securely was a different class of problem. So we built the runtime layer we wished existed.
Our take on the skills-versus-tools debate: stop debating and start shipping. Use whatever abstraction makes sense for your domain. Call things whatever you want. But invest in infrastructure that lets your agent actually take actions securely, at scale, with proper user authentication.
That’s what makes the difference between a demo and a product.
