From MCP to Agent Skills: Why Agents Need a New Context Engineering Protocol

On November 25, 2024, Anthropic launched Model Context Protocol (MCP), which many thought that the Agent world had finally a single interface, and that the next thing was to make up for ecology, customers, distribution.

The questions in this article can also be addressedMCP (Model Context Protocol)、Agent Extra Resource Collection: Skills, MCP Server, Plugins and Practical ToolsHow the concept of a relatively close read together is developed in different contexts.

But reality is not that linear.

On October 16, 2025, Anthropic pushed Agent Skills to the stage; on December 18, 2025, Skills became open standards; on the same day GitHub Copilot announced support for Agent Skills; on February 2nd, 2026, OpenAI made public reference to the Skills mechanism in introducing Codex app. This timeline itself has shown one thing:Even when agreements already exist, developers are still looking for lighter, softer, less restrained capacity envelopes.

So this article will give a judgment:Skills is a valuable link in context engineering. It is not a leap forward relative to MCP, more like a light patch to the capacity containment approach after the model capacity has risen. It'll fire, mainly because it's simple enough.

That sounds like a deliberate denigration of Skills, but I'd like to say:The value of Skills is real, but it is not primarily about agreement innovation, but about project compression. It made a catalogue, a copy of a story that it would have done together with Host, Clit, Server, Schema, the license model and the installation link. SKILL.mdand several references. It didn't invent a whole new world, but it stepped on Agent's worst point in development:How the capacity should be handed over to the model.

The introduction: the fire of Skills, not because it is more advanced than MCP

One of the most easily made mistakes in the technological world is to write the popular error more advanced.

MCP is more complete than Skills, which is hardly controversial. It was not a Tool Calling agreement from the beginning, but a context agreement:tools 、resources、prompts、Registry、 .mcpbThe life cycle, competency consultation, client-based permission boundaries, authentication authorizations, etc. all indicate that it is trying to address the standardization of interfaces between Agent and the outside world. Whether SDK or the document itself, MCP is much more complex than Skills.

MCP design is really a real thing. Model Context ProtocolI'm sorry. All AI external context (tributions, tools, resources, human interaction) is considered comprehensively in the protocol design. Ideally, an AI model (without additional hints) and an MCP Server can be fully accompanied by AI Agent.

And Skills didn't grow up along this route. It did not attempt to unify its translation, did not attempt to resolve multiple-end consistent competencies, and did not attempt to incorporate all capabilities into a tight set of agreements. It's very simple:(b) Tie the Prompt, scripts, local information and workstream descriptions into a capacity package to allow the model to be read on demand.

Skills gives people the feeling that, since MCP has not achieved the desired results (or is misread as a tool standard only), we will be asking for a new standard.

That's why I don't think Skills is the next generation of MCP. It's more like a project sidewalk: when the protocol is too complete, too heavy, too heavy a mental burden, the developers naturally go back to the way they cover the file system, scripts and instructions.This is the capability package that is easier to understand, install and maintain.

It's not a shame. On the contrary, this suggests that the paradox of Agent's development is not whether we can design more elegant agreements, but whether we can deliver our capabilities to models, be maintained by teams, reused by projects, and create real value for the project itself.

Why is it always looking for lighter capacity seals, Agent?

From Tool Call to MCP, to Skills, ostensibly changing technical terms, the same issue is actually being discussed:What form should the capabilities be exposed to the model?

The earliest Tool Call is very clean, giving the model a tool name, a tool description, a parameter Schema, which knows when and how to call. The benefits of this paradigm are clear, stable, easy to audit, and the disadvantages are equally clear: it is particularly appropriate for functions and not for processes. (On why MCP has made some progress in relation to traditional Fund Action, discussed in previous logs, without repetition)

But in Agen, many of the important capabilities in the world are not just functions, but set.

For example, the "Current Analysis" "Reading the Warehouse Output Technology Program" "Creating a blog in my style" "Checking if a project is fit to go online" is not a few parameters that can be made clear. They typically include:

How should input be understood
What information needs to be read first?
Steps that must be implemented in sequence
Which scripts are worth running directly?
What format should output match?

Such capabilities would appear rigid if they were forcibly rewritten as Tool Schema; if they were purely Prompt, they would be out of control because they were too long, too fragile and too difficult to maintain. Not everyone can maintain a word of a word for a long time. So the middle zone naturally emerged:It would be better to write capacity into a package that can be readable, expanded and distributed.

Skills was set up because it just grew up in this middle zone. It's softer than Tool Call, lighter than MCP Server, more stable than a large system hint. For most of today's Agent projects, this ecological position has been in existence, but sooner or later someone will wrap it up.

Skills, what is it? A description, script and a needs-based knowledge package.

Making a Skill

If MCP is considered to be the standard plugin for Agent to connect to the outside world, then Skyll is more like a work bag. It is more like a small catalogue of items that can be carried and distributed at any time, like SOP, scripts, templates, references and rules of use for a given type of mission. The mission opens when it arrives and the mission is irrelevant, so leave the context undisturbed.

From the way it's presented, a Skyll is at least just a belt. SKILL.md ; from the operational point of view, it is a three-storey stack of objects and objects: the content layer, the movement layer, the host layer. The content layer resolves what is in it, the movement layer resolves when it triggers, and the host layer resolves who loads, who executes and who binds the authority. It's like MCP, it's multilayered.

You can see the most typical of them:

pdf-skill/
├── SKILL.md
├── references/
│   ├── forms.md
│   └── reference.md
├── scripts/
│   └── fill_form.py
└── assets/
    └── template.pdf

SKILL.md It is the Master Note, but it is also in two parts. The first one, the first one, the first one, the first one, the first one, the first one. name and description;the last thing that's left is the Markdown text for the model. This design is simple:name It's a logo.description It's a trigger condition. According to the Anthropic document and the Agent Skills open code, Agent starts without putting all Skill text into the context, but with every Skill first read name and description, as a skills directory, put them in the system alert. User requests to hit a certain description After that, the model will read the whole thing. SKILL.mdI'm sorry. This is how Skills works:The index is exposed and then the text is loaded as necessary, using progressive disclosure to mitigate the corruption in the context. More crucially, this progressive disclosure is the default path.

Next up is the second floor: Why is there a lot of room in Skyll? scripts/I'm sorry. Some things are not cost-effective and unstable by modeling. For example, the PDF forms, batch changes, calls fixed CLIs, and generation of standard reports. Every time, the model is used to spell orders, waste token, and easily roll over. Skill's way of getting SKILL.md I'm in charge of the way, Jean. scripts/ Responsible for high frequency, machinery, high certainty components. In introducing the Skills architecture, Anthropic also made it clear that the model can read instructions and choose running scripts after Skill has been triggered; the script code itself does not have to be context-specific, and the model needs to get the results of the execution. More precisely, Skills did not recreate the Tool calling protocol, but instead allowed the model to read the description document and then call the host that had already provided it. bash, file system, code execution capability to run scripts, organize commands, parameters and even a small Python code, if necessary, and then decide on the next step based on the output.

Third floor is... references/ and assets/。references/ The solution is where the big pieces of knowledge are put.assets/ The solution is where the templates and materials are put. The beauty of Skill is precisely not that it fed the model more text, but that it allowed text, scripts, templates and static resources to be stored and loaded separately. This is also a gradual disclosure: a directory is given on start-up; a text is given after hit; and a document is read in the body when reference is made to the statement, schema, template. So, Skyll can be big, but the context doesn't have to start to swell.

And here, the Skill's "content layer" is clear:

SKILL.md: Master Notes, tell the models when they are used, how they are done, what they are taken into account.
scripts/: An enforceable certainty operation, responsible for the steady operation of high frequency.
references/: as needed, for the reference material, which is responsible for filling in large amounts of knowledge that are not suitable for permanent presence in the context.
assets/Templates, sample and static resources to support the final delivery.

There's nothing mysterious about this structure, but it's very in tune with the Intuitive Use of Agen. The most important thing in a Skill is not the script itself, but...It places different levels of capability in different places. Go, go, go!。

Enable Skill

But Skill can't get up with the catalogue structure alone. It's alive with dispatch layers, the layer of system hints and tools that host systems are stuffed to Agent. The official integration guide for Age Skills makes this very straightforward: scan skills catalogues at startup, decompose frontmatters, and then inject Skill-usable metadata into system programt to let models know what they can do. In other words, Skill will not jump out; the host will first give the model a list of skills in the system alert and then the model will decide whether to expand one of them as requested by the user.

The system hints usually address at least a few things: what Skill is available; how to handle a user-specific name for a Skill; whether to automatically trigger a job without a name but when the job clearly matches; and whether to trigger the whole thing. SKILL.md Injecting context or going to the file system first; whether multiple Skills can be combined when relevant; and, if Skill has scripts, which tools are defaulted to allow and which require additional confirmation. And because there's a clear “discovery-trigger-load-execution” link, Skyll is never just a hint folder, but a light running time mechanism.

Prompt just thought about what to say, and Skyll thought:How to give a whole category of tasks to a model and to be reused every time. The former addressed a dialogue, while the latter began to be engineering.

Further down, different products are actually placing different shells outside the same set of directions of realization. In Claude Code, Skill can put it in ~/.claude/skills/ As a personal ability, it can be placed in a project. .claude/skills/And followed the Guit to become a team-wide workflow, and Anthony supported the plugin to bring Skill in with it.

On OpenAI, as of March 11, 2026, HelpCenter has clearly written that the Skylls in ChatGPT are reusable, shared workflows that can be used automatically, one or more Skills can be created, installed, shared in the workspace. You'll find the products to be very different in appearance, but the bottom instinct is the same:Whatever the shell changes, Skills is doing the same thing -- handing over proprietary processes and organizational knowledge to models.

A little bit off the record.

Another interesting detail is that the Skill standard format, although deliberately light, is not entirely without borders. Open norms are right. SKILL.md The frontmatter actually has a lot of constraints:name To match the directory, to limit the length, and usually to name with a short line;description Not just the text, it directly affects whether the model can trigger this Skyll at the right time.

And some of the results will support it. compatibility、license、metadataAnd even experimental. allowed-tools fields, such as fields, which are used to express operational environmental requirements, authorized information or tool boundaries. That is, the lightness of Skills is not just a little bit of Markdown, but rather “only the most critical structures are standardized, leaving the rest to the host”.

If I were to sum up this section in a less nuanced phrase, I would say:Skill is not a new organ for Agent, but a brochure, toolbox and an appendix to be searched on demand. It is not a large design, but it works in a way that is easy: people can write, teams can pass, models can work, context doesn't explode immediately.

And of course, you can see from this, Skills, that there's an implicit premise: the model is strong enough to read the instructions, know when to turn over the appendices, run the script, and when to use the process and not the hard-ass. And that's why Skills looks like a catalogue structure, and behind it is a modeling dividend. We will proceed with this issue in the next section.

Why now? When the models get stronger, the tools of uncertainty are finally used.

If we turn back the time earlier, Skills, this kind of thing doesn't necessarily work that way.

Because it was born with an uncertainty: the model was not a rigorous JSON Schema, nor a fully standardized remote service, but a set of instructions, references and scripts. It needs to decide for itself whether it should be used, what to read first, what to read, when to run scripts, when to keep templates and not implement them.

It's actually very high demand.

Schema-based tool calling to press uncertainty onto the interface; Skills accepts a portion of the uncertainty and gives it to the model understanding capability. That's why I think it is. The conditions for Skills to be established are not just SKILL.md This format, instead, the model is strong enough to digest this semi-structured capability portal.

Skills is not a design innovation that emerges in a vacuum, more like a byproduct of an enhanced model capacity. When models are already good at reading documents, scripts, understanding work streams and describing routers, developers naturally tend to deliver capacity in a lighter and softer way. The marginal gains of strict Schema began to decline and the gains of light-volume seals began to rise.

Or say:The difference between Skills and Tool Call is who is to assume the certainty of the interface. schema-based tool calling More certainty is written into the interface layer; Skills transfers a portion of certainty to the model understanding layer. The former are model-friendly, the latter are developers friendly; the former are more suitable for binding actions, and the latter for loose work streams and team knowledge.

This is also the most interesting relationship between Skills and the early Tool Use study. The tools used to be used have been trying to get models learned to find the right tools in the API; today, front-line models are strong enough to gradually shift from training models to tools to lower frictions in the development of the capabilities. Skills just stepped on this migration line.

Anthropic has been provided in official files. programmatic tool callingI'm sorry. It allows Claude to be in code execution The Python code is written in the container and tools are called as functions; multiple tools in the middle are called, filtered and aggregated in scripts, rather than being re-scoped in model at every step. Officially, the value is also straightforward: multiple-step workflows can reduce delays and the continued use of contextual windows for intermediate results.

This detail is also moving towards scriptization on the side of the schema-first: Skylls lets models read SKILL.md , then call the bash/ CLI script, programmatic tool calling, and let the model write its own script in the controlled code execution environment. It is not a standard field for MCP core, but part of the Anthropic Tool Use infrastructure; it responds to the same engineering issue: How to make a model do not have to be called in a rigid JSON function, but still manage its own processes, process intermediate results and continue to do it down.

It also stems from the progress in basic modelling capabilities, and MCP will have the ability to use CLI scripts, provided that the main Agent himself (agents to access Skills and MCP) has the authority to order, CLI script is the result of the advancement of model capabilities, not the invention of Agent Skills.

MCP unfinished business: the agreement was written there long ago, and experience didn't grow.

If only the concept was in, Skills wasn't going beyond MCP too much.

MCP, it's not just from the beginning. tools。resources、promptsAnd later. instructionsThis indicates that it was intended to systematize the external context required for the model. Even conceptually, MCP is much bigger than many people today understand: It discusses not how models are added to functions, but how external capabilities, external knowledge and cross-border convergence are organized.

The problem is not that the agreement is not thought out enough, but that it is written there and does not automatically grow up to be experienced.

If only capacity coverage is mentioned, MCP does not in fact lack a catalogue before developing such progressive disclosure mechanisms as needed. The law was published in the public version of November 5, 2024, and the law was published in the public version of November 5, 2024.tools/list、prompts/list、resources/list I've already supported it. paginationAnd they can each do it. listChanged The notification informs the client that the directory has changed. The protocol layer is well placed to expose a part of the tool, Prompt or resource, and then press cursor to continue to take it back, instead of spread the entire capability at once.

In 2025 and 2026, Anthropic continued to push the matter forward on the product layer: the MCP tool search default will be activated when the tool description is more than 10% of the context, and the MCP tool will be marked as defer_loading: true, search first, then spread.

MCP Connéctor and tool search tool also tool_reference、default_config.defer_loading These mechanisms have become ready-made capacities. In other words, MCP does not lack a gradual disclosure mechanism, but rather a simple, easy-to-understand default experience that can be understood by ordinary developers. It is not yet enough.

MCP is too abstract, and the engineering team in Anthropic has considered almost everything that could be considered at the time: protocols, curricula, multilingual SDK, distribution communities, and continuous capacity-building. Integrity means strong and means a higher burden of access. Developer handles server, client, installation, privileges, life cycle, capability exposure, client support matrix, and faces different products Yeah. prompts、resources、instructions The appearance of the difference.The protocol must be designed so that if the product experience is not low enough, it will not automatically become the first option for developers. Understanding MCP and developing MCP is a professional task in itself.

That's where Skills hit. It did not attempt to answer all the questions, but only the most immediate ones:How do I put this power into Agent so it can be used today? How do I allow everyone to give Agent a power that doesn't stay in the hands of a few developers?

The former is addressed by Skills itself: it is simple enough to understand and more dependent on modelling capabilities than on fine engineering. Many Agent can access Skills without having to achieve a Client, with file reading and a few hint adjustments. The latter is more direct: to build a Skill for generating Skills and to put it in front of every user.

So I'm going to understand Skills as a side patch for MCP, not a substitute. It does not win the integrity of the agreement, but the experience. More precisely, Skills took the patient from the developers before MCP had reached the extreme of "light sealing + light distribution + light activation."

That's why MCP went on. RegistryRefill .mcpbRefill server instructions, also replace SDK/ API tool search and defer_loadingI'm sorry. The world of the deal finally realized that:Interfaces are not defined in their entirety and distribution, installation, mental burden and default experience are equally part of the agreement.

MCP server instructionsMCP did not include this feature when it was first released, and the development team in Anthropic realized that we needed to complement the whole presentation of Server rather than the tool-only description.

New instructions The field is a user manual dedicated to the AI model (User Manual) and it is understandable that Skills has a text description section that describes the functions of this Server so that the previous development would not force global rules into the tool description.

Anthropic suggests focusing on information that is not transmitted by Tools and Resources per se, mainly in three categories: cross-functional dependencies, best operating mode (Operational patters), and system restraints and limitations (Constabilitys and limitations)

But be careful,server instructions The solution is a service-level user manual, not a gradual disclosure itself. The real responsibility is to give the catalogue first, then to expand it as needed. MCP tool search、tool_reference and defer_loading。

If you open up Skills, it's a few pieces of core parts that are actually found in the MCP.

SKILL.md This is a more descriptive stream of work. server instructions + prompts
references/ Closer. prompts
scripts/ Closer, Host, open. bashNormal tools And more. programmatic tool calling The product of integration.
assets and resources There's a certain continuity.
metadata and progressive reading tool search + defer_loading。

They're not itemized, but they're combined and they're already covering the core of Skills' capability. From this perspective, MCP has no shortage of capabilities, but the missing path for ordinary users to use them naturally.

Why did Skills win the developer?

If it's purely technical, it shouldn't be; but if it's real, it's very reasonable.

It's better for team knowledge.

The most often settled team is never just API, but rules, templates, styles and processes. How to write a report, how to review the code, how to organize a study, how to align the output to the organizational tone, these things are more like a Skyll/Claude.md than a Tool.

It's more suitable for local work streams on projects.

Many of these capabilities are not worth being treated as independent services. Several scripts in a repo, a checklist, a set of output templates, tied together with project codes, project specifications, project context. Skills packed these things in situ, but more intuitively.

It provides a light-weight capability distribution format

Many teams wanted to distribute not standardized API, but a set of ways to do things: a note, a template, a few scripts, some references. MCP can cover a lot of these capabilities, but Skills makes it easier: one. SKILL.md A few directories would be enough to start sharing. It wins at low cost of packing and distribution.

Pass. SKILL.md This portal, the alerts, instructions and work streams are treated for the first time as diffuse works. For many teams, this distribution is closer to real needs than to strict agreements, and to daily collaboration. Looking back today, Skills won not by monopolistic power, but by putting together a catalogue of capabilities that were scattered across the MCP, host runtime and Tool Use infrastructure.

It's loose enough.

That is the most important point I have. Skills' fire, not just because it's good, but also because it's good.Less than that.I'm sorry. It does not require developers to understand a set of strict agreements, does not require that each capability be written into a normative interface, or that all Host behaviour be agreed first. It is loose, so it is easy to be adopted; it is easy to be adopted, so it spreads fast.

It's too simple to use.

Users hardly need to understand the details of the protocol behind them: load it, describe it clearly, let Agent find out for himself, and Skyll can start working. Additional token costs of hierarchical exposure are also usually manageable. If you want to share your abilities, even using Skill, which generates Skills, to help create it, you need only a few hints and rounds of dialogue, rather than a full set of service/client/schema technology bars.

So, as of today, this does not mean that MCP cannot do the same, but they implicitly fail to wrap these capabilities into the same low threshold of understanding.

There is always a paradox in a standardized world: standards are often heavier than standards; and the lighter they are, they are often less standard.Skills is clearly standing on the side of the front.

Simple costs: Skills standards are inadequate, security risks and maintenance liabilities

But simple is never free.

My biggest reservation to Skills is not its worth, but its re-introduction of many constraints that should have been shared by the interface, agreement and host, to model understanding and team discipline.

Models are heavier.

The strength of Tool Call is clarity: name, description, parameters, a model that is not so smart as to be more easily versed in the right direction. Skills is different. Models to be from SKILL.md It understands when to use it, and it decides whether to continue reading. references/, and then decide whether the script is supposed to run. This is certainly more flexible, but it is also clearly more dependent on models.

That is why I keep a little bit of vigilance about the scripting tool. The script CLI looks like it saved Schema, and in fact simply transferred part of the complexity of the interface to the model: the model needs to read itself, identify the script capability, decide parameters and the timing of implementation. It's more flexible, but not more sober than Tool Call.

I'm not sure if I'm going to be able to do this.Skills saves the complexity of the interface layer; this complexity will shift to the model understanding layer.

The border is even more blurred.

MCP is not absolutely safe, but its risk exposure is clear: you know what tools sserver exposes, what level of permission the client has to confirm, and what calls are part of the agreement. The risk of Skills is easier to hide in ordinary documents and scripts. When a capacity package carries both instituments, references, and scripts, it is already close to the supply chain, and is no longer just a Prompt problem.

That's why project level Skills has to be careful about the project. They appear to be knowledge packages, often with enforcement powers in practice.

In fact, the poison of Skills is not the only thing that exists in the world, especially after the fire of Openclaw, where toxic Skills are filled with the whole community and nobody cares. In the MCP wave of 2024, while MCP was also likely to be poisoned, at least there were companies that had endorsed the MCP Servers for them, and Skills was being manufactured by everyone and was being distributed by Hub, which had little or no audit mechanism.

Portability is weaker than I imagined.

Open standards do not represent a uniform running time. Claude, Copilot, Codex, who says they support Skills, does not mean that they are completely consistent with directory scanning, access control, network access, reliance on installation, script environment and UI appearances. Skill can be spread, doesn't mean Skill can be executed without harm.

In other words, Skills is more like it now.Removable cover format, not the standard of a uniform interface in the strict sense.

It's easy to turn into a new document project.

At first you thought you only wrote one. SKILL.mdAnd then you find yourself maintaining a whole set of information structures: not conflicting descriptions, not invalid references, not drifting scripts, not expired templates, and possibly different trigger effects on different models. The more Skill, the more obvious the problem is.

Progressive disclosure is also not in vain. Authors must control the distribution and density of information at all levels: less writing, less modeling, more misperception, more inability to read, more writing, more time load, more time, more token consumption, more consumption. So you're gonna find that, instead of eliminating complexity, Skills is going to switch some of that complexity from interface design to information design.

One of the findings of an empirical study in February 2026 on the disclosure of Claude Skills, which counted 40,285 public skills, was that there was a clear risk of redundancy and extraordinary security in the ecology. This is not surprising to me, because as long as a capacity is contained in a light and relaxed capacity, it will certainly experience a brutal growth before it begins to re-establish governance.

So my judgment on Skills has never been "dangerous, don't use it" but:It is worth it, but it must be used with engineering vigilance.

Skills' position in Agent: it's part of the context project, not the end.

I think the easiest place to discuss Skills is to write it into a big idea that represents the future of Agent.

It's not.

Skills addresses how capacity enters the context: what knowledge, processes, scripts should be given to models, and how to seal and distribute. It is valuable, but only loaded, and not fully contextualized.

And that's why, after Skills emerged, the concepts of memoory, Contex Engineering, Subagent, have not disappeared, but have become more and more important.

Memory It deals with reservations, compression and memory, not with definitional capacity.
Context Engineering The treatment is context segregation and task split, not encapsulation capacity per se.
MCP Standardized tools will not lose value, and they will encapsulate capacity to a certain function, and the development of MCP remains very relevant for a standardized scenario.

From this perspective, Skills is well located:It's the first layer of Context Engineering, the first layer of Agent's ability exposure and capacity loading. Context management includes not only loading, but also compression, isolation, oblivion and restoration, so Skills will not be the end.

The more difficult questions are in the back:

When should we forget what we read?
When do you keep the conclusion and not the error of the test process?
When should complex tasks be removed to subagent instead of continuing to contaminate the main context?

If the loading phase is limited in the optimal space, forgetability becomes more critical, that is, Context, or the management of memooryI'm sorry. The system needs to move non-critical information out of context in a timely manner, leaving the focus space for the current task.Loading and forgetting are a set of side actions that respond to the same development issue with memory, retrieval: Context.

These questions, Skills, cannot answer. It's the context project, it's the single generic Agent's question to answer.

Conclusion: This technology is useful, but not divine.

If it is necessary to define Skills in one sentence, I would say:

It is not a new uniform agreement, but a competency-packing technique: to organize instructions, references, scripts and loads on demand into a default experience.

This assessment does not sound ambitious, even somewhat ordinary, but I think it is closer to reality. Skills is really valuable, and it gives Agent the ability to have private project capabilities, team-based processes and organizational experience. It's hard to exaggerate these things in the past. It's more stable than pure Prompt, softer than pure Tool Call, less than self-constructed MCP Server. It is worth taking seriously.

But I don't want to write it as a technological leap.

It does not redefine the agreed boundaries, does not have an automatic unified competency model, does not have natural long-term memory of solutions, and does not eliminate the complexity of context governance. The most appropriate thing it did was to admit a fact that many engineers had felt about:In the Age of Age, standards do not necessarily win first, but simple often win first.

So my conclusion is very clear:

Skills deserves to be adopted. Especially when you're going to seal up team knowledge, local processes and light automation, it's almost natural.
Skills is not worth dementing. It is not a full upgrade of MCP, nor is it the final end of the Agent architecture; in the MCP technology, its most prominent capabilities are today largely replicating.
Skills is still ultimately to be read in the larger context engineering framework. It's one of them, but it's just one of them.

Skills is not the answer to the question, but is forcing us to ask a more practical question:How we should organize our capabilities into context and construct a truly useful intelligence.

References

Anthropic, Equipping agents for the real world with Agent Skills
Anthropic, Introducing Agent Skills as an open standard
Anthropic Docs, Agent Skills overview
Anthropic Docs, Skill authoring best practices
Anthropic Claude Code Docs, Extend Claude with skills
Anthropic Docs, Bash tool
Anthropic Docs, Programmatic tool calling
Anthropic Docs, Tool search tool
Anthropic Docs, Connect to external tools with MCP
Anthropic Docs, MCP connector
Anthropic, Managing context on the Claude Developer Platform
Model Context Protocol, Pagination (2024-11-05)
Model Context Protocol, Tools (2024-11-05)
Model Context Protocol, Prompts (2024-11-05)
Model Context Protocol, Resources (2024-11-05)
Model Context Protocol Blog, Introducing the MCP Registry
Model Context Protocol Blog, Server Instructions: Giving LLMs a user manual for your server
Model Context Protocol Blog, Adopting the MCP Bundle format (.mcpb) for portable local servers
OpenAI Help Center, Skills in ChatGPT
Agent Skills, How to add skills support to your agent
Agent Skills, Specification
GitHub Changelog, GitHub Copilot now supports Agent Skills
OpenAI, Introducing the Codex app
arXiv, Agent Skills: A Data-Driven Analysis of Claude Skills for Extending Large Language Model Functionality