After Microsoft Put Skills on MCP, Why Is Discovery Still JSON? SEP-2640, skill://index.json, and skills/list

Up front: once a Skill rides on MCP, the procedure can stay Markdown. The discovery contract is still JSON. On 16 September 2026, Tommaso Stocchi of Microsoft Agent Framework published a side-by-side: a ski-resort advisor moved from “each specialist runs its own model” to “the parent loads a Skill on demand, then calls MCP tools directly.” Services stay distributed. Reasoning moves into the parent context. This site’s 11 September piece on MCP / Skills / Tools / Subagents covered the four layers. This article only adds what happened after that date: what the discovery document looks like, where SEP-2640 actually sits, and why you still check a JSON file first.

Written as of 22 September 2026. SEP-2640 (the Skills Extension) was marked Accepted on 3 September. It is not Final. The Microsoft demo pins a historical Draft of skill://index.json. The newer draft uses skills/list and skills/get. Two discovery shapes are in the field. Compatibility is a better first question than “did Skills replace Agents.”

What actually shipped on 16 September

Stocchi’s post is titled From Specialist Agents to Distributed Skills over MCP. The ski-resort advisor used to call four specialists over A2A: weather, safety, ski coaching, lift traffic. Each specialist owned instructions, tools, and a model loop. The second path turns the same domain services into MCP providers: each publishes a description, a SKILL.md, and typed MCP tools. The advisor uses MAF’s SkillsProvider and MCPSkillsSource for discovery and loading. SkillToolsMiddleware attaches that provider’s tools to the next model turn after load_skill succeeds.

Web research stays an ordinary agent tool. The hybrid is deliberate: keep autonomy where you need it; turn a bounded competence into a Skill. The four MCP endpoints live at /skillsmcp. The resource surface is usually just:

skill://index.json
skill://<skill-name>/SKILL.md

skill:// names a resource on an already configured MCP connection. It is not a hostname, and Skill prose must not open a new network hop. Authentication, transport, and authorization stay in infrastructure and code, not in Markdown.

This is not MCP replacing A2A

The original draws a clean line. A2A hands a task to another reasoner. A distributed Skill hands a competence and its operations to the current reasoner. One table is enough:

Concern	Agent as a tool (A2A)	Distributed Skill
What the parent discovers	A specialist agent it can call	A competence it can load
Where specialist instructions run	The specialist’s model context	The parent’s model context
Who selects domain operations	The specialist model	The parent model
What runs remotely	A specialist loop and its tools	MCP tools and their backing services
What stays distributed	Agents, services, data	Skill providers, services, data

The Agent Card name and description become a discovery entry. The system prompt becomes SKILL.md. Tool parameters become MCP input / output schemas. Business services stay behind the tool handlers. Endpoint, auth, and transport on the Card do not belong in the Skill description. That matches the 11 September piece: Skills are the procedure, MCP is the socket, Tools are the contract. What changed is how the procedure is discovered — not a collapse of the three layers into one.

The discovery contract: skill://index.json

An orchestrator does not need every procedure on every request. It needs a directory that is good enough to route. The weather provider’s index in the demo is:

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "weather",
      "type": "skill-md",
      "description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
      "url": "skill://weather/SKILL.md"
    }
  ]
}

This is the Agent Skills discovery index with MCP semantics: url is a resource URI, not an https host. $schema points at discovery 0.2.0 on schemas.agentskills.io. The description answers when to use the competence. SKILL.md answers how — naming operations such as weather_forecast, ranges, units, and a ban on inventing observations. Types and bounds on those operations still come from the JSON Schema in MCP tools/list.

At startup the parent pulls the catalog and tools/list over MCP. The model first sees Skill summaries and load helpers, not every operation schema. After load_skill("weather"), the middleware attaches that group. A tool appearing in context is not an execution.

SEP-2640: Accepted, not Final

SEP-2640 is the Skills binding on the Extensions Track: serve Agent Skills through MCP Resources. The extension id is io.modelcontextprotocol/skills. Directory layout, YAML frontmatter, and progressive disclosure stay with the Agent Skills spec. The SEP only binds transport.

As of the 10 September check in Stocchi’s post: the 3 September revision marked Accepted and moved discovery to skills/list and skills/get (paginated; entries carry uri, parsed frontmatter, and a resource manifest with sha256: digests). The matching PR was still open. The demo pins an earlier Draft: it reads skill://index.json and does not implement the new methods. The incubation repo is still Experimental.

Do not write second-hand “Final on 13 September” into a production checklist. What is solid on 22 September 2026: Accepted, not Final, two discovery shapes in use. Treating the Draft index as a core MCP requirement contradicts the footnote in the post itself.

The tool contract is still JSON Schema

The demo’s forecast takes hours with Range(1, 24) and UseStructuredContent. The SDK publishes the tool definition. The handler validates the range, then calls the domain service. SKILL.md guides which tool to pick. It does not replace the parameter schema or server-side checks.

Authoritative operations come from tools/list. Execution is tools/call. Instructions are resources/read. All three hops are JSON-RPC. A Skill can say “paginate”; it cannot persist your cursor. It can mention an approval step; it cannot enforce authorization. That is the same layer as why Tool Calling depends on JSON Schema: prose picks a road, the contract rejects illegal arguments.

Three paired runs: faster, not cheaper in tokens

The same prompt (“considering weather and waiting time, where should I start?”), the same Aspire app, gpt41, three fresh conversations. The A2A path used 6 / 6 / 7 model calls (specialists can overlap). The Skills path used 3 each time: load_skill, then direct MCP operations, then the final answer. Mean client wall-clock was about 6.35 s versus 15.48 s.

Tokens did not fall. Across three runs the Skills side observed about 13,533 versus about 11,134 for A2A — roughly 22% more. Fewer model hops are not a smaller cumulative context: instructions, group schemas, and results stack across the three calls. A2A cache counters were incomplete. This is not a bill, and not a controlled study. The original says so: three pairs, not proof of equal correctness or completeness.

The structural takeaway is one sentence: what you drop is the nested specialist loop, not the JSON round-trips. Discovery indexes, tool schemas, structured results still hop. They just live as a few contracts in the parent context instead of a speech from every specialist.

Two discovery shapes, hosts that miss each other

The split was already visible in August–September 2026. UseMcpSkills in Microsoft.Agents.AI.Mcp still reads skill://index.json. A server that only implements skills/list gets “no index resource.” A server that only ships the index, without the extension declaration or digests, is invisible to a newer host. Some hosts already mark index-based servers as legacy.

Do not bet on a winner. For a small catalog, serve both: a Draft index for older clients, skills/list / skills/get for hosts that declare the extension. An absent or empty listing must not be treated as “this server has no skills” — the draft allows partial enumeration for large or generated catalogs.

Three JSON documents you still check locally

The discovery document. Entries from skill://index.json or skills/list: name, type, description, url / uri. Check them against $schema. Extra keys, empty descriptions, or an https host in url are routing bugs, not copy edits.
Tool schemas. Take inputSchema from tools/list. Fill required, set additionalProperties: false, tighten enums and ranges. Names the Skill prose mentions must match the list.
Structured results. The demo turns on Structured Content. Output back to the parent should still be legal JSON, then checked against a schema. Do not return a whole database row or a stack. See why agents need JSON even more after the Agents API.

Inspect the discovery document with local JSON tools

Before you wire MAF or any host, lay out three texts in the browser: the discovery index, one schema from tools/list, and a sample tools/call arguments object.

JSON validator — is the grammar legal; if you have a schema, check fields, required, and extra keys together.
JSON formatter — expand a one-line index and see whether url is really skill://.
JSON Diff — compare a Draft index entry with a skills/list entry so the two catalogs do not diverge.

Nothing leaves the browser. Stabilize the discovery contract, then let the parent load SKILL.md. The procedure can change wording. Field names and URIs should not move every week.

FAQ

Is SEP-2640 Final now?

No. The 3 September revision is Accepted. Stocchi’s 10 September check still had an open PR. The demo uses a historical Draft of skill://index.json. Do not drop old clients on a “already Final” story.

Will distributed Skills replace A2A?

Not as a blanket rule. Keep an Agent when you need an independent lifecycle, private context, or a specialized model. Migrate to a Skill when you only need a procedure plus operations. Leaving web research as an agent tool is that distinction.

Is skill:// a URL the host should resolve?

No. It names a resource on an already configured MCP connection. Skill prose must not use it to open another host.

If I have SKILL.md, do I still need JSON Schema?

Yes. Markdown guides tool choice and how to read results. Types, ranges, and required fields still come from the tools/list schema and a check you run yourself.

Is skill://index.json enough on its own?

For some current Microsoft clients, yes. For hosts on the newer draft, no. Serve both on a small catalog. One shape alone is invisible to the other half of the field.

Is the Skills path cheaper?

In the demo, wall-clock was faster and observed tokens were about 22% higher. It is not a controlled study. Compare routing and structured results first, then the bill.

Summary

The 16 September demo did not announce that agents are obsolete. It announced that a competence which does not need nested reasoning can ship a procedure and operations, with a JSON discovery surface. Service boundaries stay. What you drop is the specialist model loop. What you still hold is the discovery index, the tool schema, and the structured result.

SEP-2640 is still Accepted. The Draft index and skills/list will live side by side for a while. Flatten the three JSON documents in a local validator before you hand them to a host. The 11 September layering still holds. What no longer holds is “a Skill is only a folder on disk.” Models and harnesses will take new versions. name, url, and inputSchema should not loosen with them.