How MCP skills carry a workflow across the server boundary

A tool can fetch an invoice or open an issue. It does not, by itself, tell an agent which evidence to gather first, how to reconcile a discrepancy, or when to ask a person to approve a consequential action. Teams can put that workflow in the host, but then every host integration must maintain its own copy. The MCP Skills Extension, SEP-2640, gives a server another way to distribute it: serve an Agent Skill as MCP resources while leaving the decision to use it with the host.

Publishing the workflow lets a host discover it alongside the server's tools without treating its instructions as an automatic command.

The server publishes an entry, not an automatic command

The extension uses the existing MCP Resources primitive to serve a SKILL.md and any supporting files. A client that negotiates the optional io.modelcontextprotocol/skills capability can call skills/list to discover entries, or skills/get for a known URI. Each entry contains the skill URI, its frontmatter (including name and description), and either a complete file manifest or "dynamic" for content without a fixed manifest. The format of the skill itself follows the Agent Skills specification; the MCP extension defines how it is delivered, not a new authoring format.

Consider a finance MCP server that already exposes lookup_invoice and create_adjustment tools. It could also serve an invoice-dispute-review skill. Its description tells the host when that workflow might help. The SKILL.md might say to retrieve the invoice and purchase order, compare disputed line items, record the evidence, and request approval before any adjustment. A separate supporting file might contain a review checklist. This is an illustrative deployment, not an AIVAX feature announcement or a promise that the server's tools are safe to call.

In that example, the host could list the dispute-review entry without downloading its checklist. When a dispute arrives, it selects the entry, obtains any required approval, reads SKILL.md through resources/read, checks its bytes against the manifest, and fetches the checklist only if the workflow needs it. A skills/get response can resolve a directly referenced skill even if it was not listed. The URI identifies the skill within that server; across connections its identity is the server plus the URI. A host should not merge two skills just because their names or skill:// paths look alike.

Reading does not activate a skill

The host owns the boundary between receiving content and acting on it. Reading a resource can show the model what a file says, but the extension explicitly distinguishes that from activating the skill through the host's skill-loading path. Activation is subject to the host's approval rules. Reading a nested SKILL.md as supporting material does not silently activate the nested skill either.

For a fixed manifest, every file, including SKILL.md, has a byte size and SHA-256 digest. While acting on the skill, the host retains that entry, limits reads to its listed URIs, verifies bytes before use, and checks that the SKILL.md frontmatter matches the advertised entry. If the manifest changes, a previously persisted approval cannot silently carry over: approval binds to the complete URI-and-digest set. A digest confirms consistency with what the server advertised, not that the instructions are trustworthy. Dynamic skills cannot have persisted approval cover arbitrary future content; a host may decline them.

That separation also protects the tool boundary. A skill's prose can propose calling create_adjustment, but it cannot grant itself tool permissions. Host-side code execution and permissions such as allowed-tools need explicit approval; resource reads stay tied to the originating server. A skill from one server cannot quietly cause reads from another server. These are host obligations, not properties that a server can assert about itself.

What this changes for AIVAX—and what it does not

AIVAX already supports managed gateway skills: a gateway can make their names and descriptions available, and the model can invoke read_skill to load their inline instructions on demand. Separately, AIVAX MCP sources currently discover server tools and expose them as callable functions. Tool names, descriptions, schemas, and returned content can influence a model's context, but that is not the SEP-2640 skill discovery, resource reading, verification, and activation path. AIVAX does not currently advertise support for the Skills Extension.

The distinction is especially important for deployment plans. SEP-2640 is Final in the MCP Extensions Track, and the Skills Extension specification is published separately. The latest core MCP specification lists Resources, Prompts, and Tools as server features and describes extensions as optional, explicitly negotiated additions. Final extension status does not mean skills have become a mandatory core primitive, nor does ordinary MCP tool support imply skills support in a host.

The invoice example ends at a deliberate boundary: the server can provide the review procedure, but the host decides whether to load it and whether a later adjustment tool call is permitted. That is the operational value of distributing a workflow without distributing authority.