In the AI world new concepts and approaches come and go almost daily. In 2023, Retrieval-Augmented Generation (RAG) received all the attention because it was the first efficient way to add your own data to Large Language Models (LLMs) without having to train or fine-tune the model itself. It quickly became visible that, although RAG has many advantages, it was not meant to be, nor capable of becoming the universal standard for adding information and “tools” to LLMs.
In late 2024, Anthropic released the Model Context Protocol (MCP), which it later handed over to the Linux Foundation to make available to the industry as an open standard. In contrast to RAG, MCP does not require the content of the data to be converted into vectors. Instead, it is based on a client-server architecture. The MCP client integrates with AI frameworks and harnesses to tell the LLMs which operations and data points are available, while the MCP server executes the commands.
Throughout 2025, MCP became the standard for providing information and tools to LLMs, with all major AI frameworks supporting it and nearly every application providing its own MCP server. Depending on the operating system you are using to read this blog, the operating system itself might even receive an MCP server soon.
From a NetApp perspective, we offer a wide variety of MCP servers. These range from the Harvest MCP server for providing your ONTAP system logs to AI agents, to the AIDE MCP server for bringing information stored on ONTAP systems into LLMs, to the ONTAP MCP server, which allows LLMs and AI agents to control ONTAP systems themselves. We are always working on adding more MCP servers to our portfolio. The currently available MCP servers can be found here: https://github.com/NetApp/mcp
But with all the praise for MCP in this article so far, why should you consider anything other than MCP? The answer lies in the details. While the MCP standard started with the goal of designing the server and client in an optimal way for LLMs to interact with them, the reality in 2026 is different. Most MCP servers out there are simply wrappers around existing REST APIs and rely on the LLM to figure out how best to perform processes.
Arguably, the biggest current disadvantage of MCP servers is that they clog up the model context. Yes, the supported context lengths of models have skyrocketed over the past two years, but the usable context is still limited, and every additional token adds cost. When using agentic frameworks, MCP clients regularly consume up to 15% of the overall context. Remember: those tokens are sent and billed with every request.
But let’s approach this topic from a different perspective. Let’s say we want to create an AI agent that helps us administer an ONTAP system. We can open an SSH connection to our ONTAP system and simply tell the AI agent what to do. Even without any MCP server or Agent Skill, current state-of-the-art LLMs will do a surprisingly good job. After all, LLMs are trained on basically all of the openly available internet, almost certainly including docs.netapp.com. But if you replicate this experiment, which the author of this blog highly advises against, you will also realize that the LLM tends to hallucinate and sometimes makes major mistakes.
At this point, Agent Skills become interesting. Like MCP, Agent Skills were initially invented by Anthropic, but the concept is now a fully open standard. Instead of being based on a client-server architecture like MCP, Agent Skills are just text files that follow predefined conventions and integrate into an AI application.
Think of Agent Skills as a cookbook that provides the LLM with extra information. Every Agent Skill starts with its name and a short description of what it is, when to use it, and when not to use it.
If we stick with the ONTAP administration example, this would be the place where you define that the skill should be used when you want to administer ONTAP systems, but not, for example, when you want to administer a StorageGRID system. After the name and description, the actual guide starts, explaining which commands are supported and how to execute them.
What makes Agent Skills special is that only the name and description need to be loaded into the model context at startup. The LLM itself can decide when an Agent Skill becomes relevant and only then load the full instructions into the model context. This way, we can save a significant amount of model context while providing the AI agent with many different tools.
In the example of administering an ONTAP system via an open SSH connection, the Agent Skill can “teach” the agent to execute SSH commands properly and thus reduce the number of hallucinations and errors. This becomes especially important when using smaller on-premises LLMs instead of huge LLMs like Claude 4.8 Opus or GPT 5.5.
But does this mean that Agent Skills are a replacement for MCP servers? No, they are not. Think of them more as a lightweight alternative that can be useful in many scenarios. Another use case is to use Agent Skills as a cookbook for using complex MCP servers. This way, you can reduce the amount of occupied model context while explaining more clearly to the LLM how to use the MCP server.
