Evaluate MCP Apps and Tasks for future workshop modules

[jongalloway]

Summary

Prototype and assess the opt-in MCP Apps and Tasks extensions before deciding whether either deserves workshop content.

Follow-up to #616. Both extensions were intentionally deferred during the MCP SDK 2.2.0 migration: Apps is experimental and host-dependent, while the current samples have no durable long-running operation.

Evaluation questions

MCP Apps

• Which workshop-supported clients render MCP Apps?
• Does an interactive UI teach something materially better than the existing tool output?
• Is suppressing MCPEXP003 acceptable in attendee code, or should Apps remain an external resource only?

Tasks

• Is there a genuine long-running workshop operation that benefits from polling and persistence?
• Can the example explain InMemoryMcpTaskStore as development-only without implying production durability?
• Is a durable IMcpTaskStore example feasible without adding infrastructure that breaks one-day pacing?
• Can Tasks compose with the proposed MRTR confirmation flow coherently?

Acceptance criteria

• Build minimal throwaway prototypes against the current 2.x extension packages.
• Record supported client/host behavior and API stability.
• Estimate attendee time and prerequisite cost for each extension.
• Make an explicit adopt, defer, or external-resource-only decision for Apps and Tasks separately.
• If adopted, create implementation issues with runnable scenarios and deterministic validation.
• Do not introduce experimental warning suppression or in-memory persistence into active workshop snapshots during the spike.

References

• MCP C# SDK 2.0 announcement
• MCP specification revision 2026-07-28