Extensions: opt in and verify support

The mechanism

Extensions add capabilities beyond the core protocol. They require explicit compatible support; an SDK package name or a successful basic tool call does not prove an extension works. Keep extension requirements in the compatibility matrix and fail clearly when a peer lacks them.

The current specification identifies Tasks for longer-running work, Apps for interactive user interfaces and Skills for structured workflow instructions. Their detailed contracts evolve separately. A task handle, embedded UI or reusable instruction pack also adds application responsibilities: ownership, expiry, authorization and safe handling of content.

Choose the smallest feature that solves the problem. ParcelOps’s read-only fixture does not need durable task execution or embedded UI. Add those only when the user experience and operational requirements justify the extra state and attack surface.

Worked example

This is a feature decision record, not an extension wire schema. It prevents a planned capability from being marketed as implemented. Core support remains independently testable while optional features are evaluated.

{"core_protocol":"2026-07-28",
 "features":[
  {"name":"incident lookup","required":true,"status":"fixture_only"},
  {"name":"Tasks","required":false,"status":"not_implemented"},
  {"name":"Apps","required":false,"status":"not_implemented"},
  {"name":"Skills","required":false,"status":"not_implemented"}
 ]}

Practice: predict, inspect, explain

Offline exercise. Imagine a report that takes several minutes. List the requirements before selecting a Tasks implementation: who owns the handle, how results expire, how cancellation works, which inputs may be requested later and what happens after a worker restarts. For an App, add data exposure and UI trust questions.

Expected observation: naming an extension does not answer the application design. Document the host and server versions that actually support it and retain the fallback behavior. This chapter intentionally does not provide unverified extension commands or claim a completed integration.

Troubleshooting and trade-offs

If a demo works in one host but fails in another, compare negotiated extension support before changing the server’s core tool. If a durable handle can be read by anyone who guesses it, fix ownership checks. If an embedded UI asks for new authority, route that through explicit application review. Never treat a skill’s instructions as stronger than the user’s authorized scope.

Interview practice

Completion check

Write a feature record distinguishing required, optional, implemented and unverified capabilities.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Index
• Official documentation: Changelog
• Official documentation: Build with agent skills