The Complete Guide to Skills: Technical Evolution from Tools to MCP to Agent Skills

What Exactly Is a Skill? The Essence in One Sentence

Developers, AI practitioners, and tech enthusiasts throw the word "Skill" around constantly, yet few can clearly explain what it actually does. Setting aside convoluted definitions, a Skill is essentially a "super-powered toolbox" for complex tasks — it gives AI Agents the core capability to invoke abilities on demand and orchestrate workflows in specific scenarios.

To truly understand Skills, you can't look at them in isolation. You need to trace the technical evolution along the path: Function Call (Tools) → MCP → Skill. These three aren't replacements for one another — they build on each other in a layered, interdependent progression. This article is based on content from Bilibili creator Xu Shu's walkthrough of the Spring AI Alibaba Agent Framework, reconstructing the principles and practical implementation of Skills.

Layer One: Tools Solve the "How to Call" Problem

Large language models inherently lack the ability to access real-time information. When you ask one about the current weather in Beijing, it can't answer directly — so it searches through its available tools for one that can handle the request. After reasoning, it finds a weather-querying tool and returns a JSON payload containing the method name and required parameters (e.g., location: "Beijing").

The application recognizes this JSON and uses reflection to find and execute the corresponding method. So the essence of a Tool (Function Call) is converting unstructured natural language into structured, actionable JSON, allowing the LLM to indirectly invoke methods within the application.

One-line summary: Tools solve the "how to call" problem.

Layer Two: MCP Solves the "Where to Call" Problem

When requirements expand beyond checking the weather to querying GitHub repositories, blogs, map locations, and other third-party services, a new problem emerges. Writing a dedicated Tool method for every third-party service is extremely costly: the more services there are, the more Tool methods you need to write; and with multiple AI applications, you'd have to re-implement these methods in each one, since Tool methods can't be shared.

So why not let third-party services declare their own Tools and expose them externally? This is exactly what MCP (Model Context Protocol) was designed for. MCP addresses the problem of how LLMs can connect with third-party services to share Tools using a unified standard. It provides two invocation methods — STDIO and HTTP — where HTTP is further divided into SSE and Streamable. The protocol defines exactly how calls are made and what data is returned.

It's worth emphasizing that MCP still relies on Function Call. From the LLM's perspective, it makes no distinction between internal Tools and external third-party Tools — they're all just tools. The full flow looks like this: the LLM returns a JSON payload for calling a Tool, the application provides it to the LLM via Function Call, and then calls the external third-party shared Tools to complete the data transfer. MCP solves the "where to call" problem.

MCP (Model Context Protocol) is a standard protocol officially open-sourced by Anthropic in November 2024, with the goal of becoming the "USB-C port" between AI applications and external tools/data sources — just as USB-C unified device charging and data transfer standards, MCP aims to unify how LLMs connect with external services. The protocol architecture has three roles: MCP Host (the application running the AI model, e.g., Claude Desktop), MCP Client (the client module responsible for communicating with the server), and MCP Server (the capability declaration endpoint provided by third-party services). Third-party services only need to implement an MCP Server once to be directly invoked by any AI application that supports the MCP protocol, completely eliminating the previous pattern of each AI application writing its own integration code. Major platforms including GitHub, Google Drive, and Slack have already released official MCP Servers, and the developer community has accumulated a large number of open-source implementations.

Layer Three: Skills Solve the "How to Orchestrate a Series of Tasks" Problem

Real-world tasks often can't be completed by calling a single Tool. Consider tasks like "open a browser, navigate to Baidu, query a function, retrieve relevant information" or "get all file names and types on the desktop, then pass them to the LLM for reasoning" — these require a series of workflow steps combined with Tools.

In a traditional Workflow Agent approach, developers have to write extensive prompts telling the LLM how to break down different tasks and handle each step. For example, a web search might need to be decomposed into "open browser → go to Baidu → enter search term → retrieve page content → reason and return" — with prompts required for every step. This leads to enormously bloated prompt content.

Anthropic (the company behind Claude) recognized this problem and introduced Skills. A Skill consists of a single Markdown file with two components:

• Metadata: Describes what the Skill does, e.g., "web search"
• Instructions: Detailed orchestration of how to execute each step — for instance, step one launches a browser Tool, step two searches for keywords, step three can even execute Python or JavaScript scripts to parse page content

How Skills Achieve "On-Demand Loading"

The most critical design of Skills is progressive disclosure (on-demand loading), rather than the Workflow Agent approach of dumping all capability-handling prompts into the LLM at once.

The flow works like this: first, the metadata (i.e., description of purpose) of each Skill is sent to the LLM. When you say "I want to search Baidu for a function," the LLM reasons through which Skill can handle the request and returns a JSON payload indicating that it needs to invoke callSkill, along with the Skill name.

callSkill is fundamentally still a Function Call — the application has a Tool method named callSkill that determines which Markdown file to read based on the Skill name (web search reads the web search .md, file operations read the file operations .md), then sends the corresponding Skill's Markdown to the LLM so it can reason through and execute the next step.

This is why Skills are also called Subagents — each Skill is just one component within a larger agent, and they're inherently easy to transfer and share.

One important conclusion: Skills are fundamentally still Function Calls. They simply have a built-in Function Call that reads the Skill text, which is why Skills require an LLM that supports Function Calling.

"Progressive Disclosure" is a concept originally from UX design, referring to only revealing complex information when users need it, in order to reduce cognitive load. Skills transplant this idea into prompt engineering: if an agent supports 20 Skills and all instructions are stuffed into the context at once, it not only consumes a large number of tokens (directly increasing inference costs), but also causes the LLM's attention to scatter over the long context, degrading instruction-following quality. The on-demand loading approach keeps only each Skill's name and brief description (metadata) permanently in the context, dynamically fetching the full instructions only when the model determines a particular Skill is needed. This is fundamentally equivalent to the operating system's "lazy loading" mechanism — programs don't load all modules on startup, only mapping them into memory when actually called, dramatically reducing resource usage and improving system response speed.

Implementing Skills with Spring AI Alibaba on Any LLM

This Skill mechanism was originally provided by the Claude model and currently only has native support from Claude. But now that we understand the underlying principles, we can use Spring AI Alibaba combined with Tools to implement Skills on any LLM.

In the latest version of Spring AI Alibaba, the Skill implementation is already built-in and encapsulated. Developers simply need to:

1. Define a Skill Agent and specify the root directory path where Skill files are located (e.g., a directory containing three Skills like web search, each being a skill with a metadata name and description)
2. The framework already has a file-reading Tool defined internally that will automatically read these Markdown files
3. Provide a Hook for executing shell commands (since Skills can execute Python and other scripts beyond reading Markdown, requiring CMD commands to run files)
4. Provide Python Tool utilities (backed by a GraalVM third-party library underneath)

Practical Demo: Searching for Protein Folding Prediction Papers

In the demo, a Controller endpoint receives the request "search for the latest papers on protein folding prediction," which maps to a Skill designed for searching papers in physics, mathematics, and computer science — it uses Python to retrieve papers from arXiv and similar sites.

Observing the console reveals the complete automatic reasoning process:

• The LLM first reads the Markdown file for the corresponding Skill
• It discovers a Python file needs to be executed, so it first uses the Python Tool to check whether a Python environment is available
• After confirming the environment, it runs the Python script to search the target website
• The first search returns no results, so it automatically reasons that there may be a command execution issue and inspects the Python file syntax
• After confirming the script logic is correct, it reruns and finds five papers
• It notices the results aren't closely related to protein folding, then refines the search using a category-based approach for greater precision

The entire process is fully orchestrated automatically according to the Skill description file — including automatic checking and self-correction. All developers need to provide is the Skill's Markdown file and the corresponding Python script.

Spring AI Alibaba is an enterprise-grade AI application development framework released by Alibaba based on the Spring AI framework, aimed at lowering the barrier to integrating LLMs in the Java ecosystem. Spring AI itself is an AI abstraction layer maintained by the Spring team, providing unified API wrappers for multiple model providers including OpenAI, Anthropic, and Ollama, allowing developers to switch underlying models without major changes to business code. Spring AI Alibaba builds on this by further integrating Alibaba Cloud models like Qwen (Tongyi Qianwen), and extends capabilities with Agent, RAG (Retrieval-Augmented Generation), and workflow features. It's worth noting that since Skill execution depends on Function Call capabilities, you must confirm that any underlying LLM you select supports Tool Use / Function Calling. Major models including GPT-4o, Qwen-Plus, and the Claude 3 series all support this, but some lightweight open-source models do not yet have this capability.

Ready-Made Skill Resources and Summary

If you'd rather not write Skills from scratch, the community already has a wealth of ready-made options. You can search on Skills.sh, which currently has over 40,000 Skills available on demand.

Looking back at the full technical progression:

• Tools / Function Call solve "how to call" — converting natural language to structured JSON
• MCP solves "where to call" — a unified standard for connecting to third-party shared Tools
• Skill solves "how to orchestrate a series of tasks" — encapsulating metadata and instructions in Markdown, loading on demand, fundamentally still a Function Call

Understanding this three-layer progression is what allows you to truly explain what a Skill is and which technology to reach for in any given scenario. For developers looking to deploy Agents with Spring AI Alibaba, mastering the progressive disclosure and Subagent design philosophy of Skills is a critical step toward building intelligent agents that are evolvable and dynamically extensible.