@akshay_pachaar: MCP meets agent skills MCP already gave agents a standard way to connect to tools, resources, and external systems. Now…

X AI KOLs Timeline Tools

Summary

MCP now defines a standard extension for agent skills, enabling on-demand discovery and loading of reusable workflows for AI agents through existing resources.

MCP meets agent skills MCP already gave agents a standard way to connect to tools, resources, and external systems. Now it also defines a standard way to discover and load Agent Skills directly from MCP servers. The flow is simple: → connect to MCP server → discover available skills → inspect skill metadata → load the relevant 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱 only when needed Under the hood, Skills are served through MCP’s existing Resources primitive. That means 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱, references, scripts, examples, and other supporting files are exposed as resources that the client can read on demand. This is especially useful for context window management. Instead of loading every workflow instruction upfront, the agent can first discover what skills are available and pull in only the one required for the current task. A useful mental model is: tools = what the agent can do resources = what the agent can access skills = how the agent should perform a reusable workflow Previously, that workflow knowledge often lived separately in docs, repos, prompt files, or custom integrations. Now the MCP server can expose the capability and the playbook for using it together. So you get: → standardized skill discovery → on-demand context loading → cleaner distribution and versioning → reusable workflows that travel with the server MCP was already the connection layer. Skills now add a standardized way to ship reusable agent know-how on top of it. The illustration below visually summarizes everything that we discussed so far. Read more: https://github.com/modelcontextprotocol/ext-skills… Cheers! :)
Original Article
View Cached Full Text

Cached at: 09/17/26, 10:30 PM

MCP meets agent skills

MCP already gave agents a standard way to connect to tools, resources, and external systems.

Now it also defines a standard way to discover and load Agent Skills directly from MCP servers.

The flow is simple:

→ connect to MCP server → discover available skills → inspect skill metadata → load the relevant 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱 only when needed

Under the hood, Skills are served through MCP’s existing Resources primitive.

That means 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱, references, scripts, examples, and other supporting files are exposed as resources that the client can read on demand.

This is especially useful for context window management.

Instead of loading every workflow instruction upfront, the agent can first discover what skills are available and pull in only the one required for the current task.

A useful mental model is:

tools = what the agent can do resources = what the agent can access skills = how the agent should perform a reusable workflow

Previously, that workflow knowledge often lived separately in docs, repos, prompt files, or custom integrations.

Now the MCP server can expose the capability and the playbook for using it together.

So you get:

→ standardized skill discovery → on-demand context loading → cleaner distribution and versioning → reusable workflows that travel with the server

MCP was already the connection layer.

Skills now add a standardized way to ship reusable agent know-how on top of it.

The illustration below visually summarizes everything that we discussed so far.

Read more: https://github.com/modelcontextprotocol/ext-skills…

Cheers! :)


modelcontextprotocol/ext-skills

Source: https://github.com/modelcontextprotocol/ext-skills

Skills Over MCP Working Group

This repository is the home of the official Model Context Protocol Skills extension (io.modelcontextprotocol/skills), based on SEP-2640, and of the Skills Over MCP Working Group’s working documents.

Specification

ResourceWhere
Specification (source of truth)specification/stable/skills.mdx — the extension spec, written against base protocol revision 2026-07-28
Official documentationmodelcontextprotocol.io/extensions/skills/overview — condensed overview with examples and message flow
SEP-2640: Skills Extensionmodelcontextprotocol.io/seps/2640-skills-extension — the accepted SEP (Status: Final; PR #2640 merged 2026-09-13)
Client supportExtension client matrix — which clients implement the extension

The stable specification is a released snapshot and is not edited in place. Changes are proposed as dated entries in the decision log (see AGENTS.md for the process) and, once accepted, land in a draft revision of the specification that ships as a new release.

ℹ️ The docs/ folder holds the decision log, the design rationale, and the implementations list. Earlier design documents, findings, and trackers are frozen in docs/archive/. None of it is part of the specification.

Charter: modelcontextprotocol.io/community/working-groups/skills-over-mcp — mission, scope, membership, active work items, and success criteria. Project board: Skills Over MCP WG Meeting notes: Skills Over MCP WG discussions Discord: #skills-over-mcp-wg Open work: Pull requests and issues — proposals, decisions, implementations, and other in-flight contributions welcome.

Repository Contents

DocumentDescription
SpecificationThe Skills extension specification (io.modelcontextprotocol/skills) — source of truth
Decision LogADR-lite record of the group’s decisions, and the vehicle for proposing changes to the specification
RationaleDesign rationale for the Resources-based extension
ImplementationsServers, SDKs, and hosts that serve or consume skills over MCP
ArchivePre-release design documents, findings, and trackers, frozen when SEP-2640 was marked Final

For the case for serving skills over MCP, see the official overview and the Motivation section of SEP-2640.

Contributing

See CONTRIBUTING.md for how to participate.

Similar Articles

Why use MCP when Agents can use APIs directly?

Reddit r/AI_Agents

The article questions the redundancy of MCP in agentic workflows when AI agents can directly call APIs, noting MCP's value in consensus and governance but suggesting it might be unnecessary for web API-based implementations.