[EPIC] MCP client maturity

[ypldan]

Goal

Make QuickApps a spec-compliant, stateful MCP client. Today every tool call opens and tears down a fresh connection — stateful MCP servers simply do not work (#389); server-provided instructions are ignored (#282); and capability coverage beyond plain tool calls is being explored in a design PR (#384) tracked by #425. Individually these read as gaps; together they are one theme: the MCP integration was built for the happy path and needs to grow up to the spec.

Scope — child issues

• Preserve MCP session across tool calls #389
• Utilize MCP instructions #282
• MCP capabilities extension: resources as context sources #425
• Adopt MCP specification 2026-07-28 #431

Out of scope

• Exposing QuickApps as an MCP server (#244 — the opposite direction).
• The code-interpreter MCP facade (#424) — a consumer of this epic's results, not part of it.

Dependencies and sequencing

• #389 first and with priority — it is a hard prerequisite for the code-interpreter migration (#423) and unblocks every stateful MCP server; it also naturally carries the auth/reconnect semantics the others assume.
• #282 and #425 are independent of each other but both touch session initialization — cheaper after Preserve MCP session across tool calls #389 lands.
• #431 (MCP spec 2026-07-28 adoption) runs alongside rather than displacing Preserve MCP session across tool calls #389 — the session-based ecosystem stays the primary target for years — but it re-baselines the other children (instructions move to server/discover, capability negotiation becomes per-request) and greenfield servers like the code-interpreter facade (#422) should target the new spec from day one.

Additional information

Related: #424 (code-interpreter epic — depends on #389), #244, PR #384 (design doc adopted by #425).