MCP extensions

What the spec changed and who should care

MCP extensions are the negotiated layer built on top of the core protocol. The core says how to list and call tools; extensions are the place for everything the first draft deliberately left out, and the 2026-07-28 revision gave that layer a formal framework — defined ways to declare, negotiate and fall back when one side does not support a feature. Opt-in and negotiated is the whole design: a client that does not implement an extension should lose the feature, not break.

Three carry most of the weight. Tasks give long-running work a durable handle: you submit a job, get back something you can poll, and the call does not have to hold a connection open while the work runs — the difference between an agent that can kick off an hour-long build and one that can only make synchronous calls. Apps let a server surface inline UI in the client — a form, a chart, a picker — instead of dragging every interaction through text. Skills over MCP deliver structured agent instructions from a server: not data to use or a function to call, but a described procedure the agent can adopt.

Who should care: server authors whose tools outlive a request, anyone whose interface needs something better than a text blob, and platform teams distributing standard working practices to agents. As with the core spec, the exact negotiation semantics belong in the dated spec text, not here.

When it earns its place in a stack

Tasks earn their place the moment a tool's runtime exceeds a request timeout — video renders, batch jobs, multi-stage analyses. The alternative is polling hacks built out of ordinary tools, which every team rebuilds slightly differently. Apps earn their place when the human-in-the-loop step needs precision: picking from fifty similar files by name in chat is miserable; picking from a list is one click. Skills earn their place when the same procedure has to reach several agents from one source of truth, rather than being pasted into each system prompt.

None of it earns its place speculatively. These are opt-in layers with uneven client support as of late September 2026; if your client ignores the extension, the correct design is a graceful fallback, and if you cannot test that fallback, do not depend on the feature.

Limits

• Support is a matrix, not a flag. Which clients implement Tasks, Apps or Skills, and how faithfully, has to be checked per pairing; the negotiation mechanism guarantees polite refusal, not working features.
• Durable handles need somewhere durable. Tasks move the problem from the connection to the server: state, retries and result storage become your responsibility.
• Inline UI widens the attack surface. Rendering server-supplied interface inside a client is a trust decision; the security post linked below is worth reading before enabling it broadly.
• Skills are instructions from outside. A server that can hand an agent a procedure is a server that can steer it. Treat skill sources with the same suspicion as any other untrusted input.

Alternatives on this board

• MCP 2026-07-28 — the core spec these layers are negotiated over.
• Claude Code — if the real need is one agent with a permission layer and hooks, not a protocol extension.
• OpenAI Agents SDK — handoffs and sessions in code, when you control both ends and do not need the interop.