A developer adds a server that supports the Tasks extension and expects long tool calls to become tasks automatically, but every call still returns an ordinary result. What explains this?
Select an answer to reveal the explanation.
Short Explanation
An extension is like an optional feature on a rental car: it's there, but nothing happens until you ask for it at the counter. Both sides have to opt in, and the trap is assuming support on one side switches it on.
Full Explanation
MCP extensions are always disabled by default and require explicit opt-in. Negotiation is two-sided: the client advertises the extensions it supports in the extensions field of the io.modelcontextprotocol/clientCapabilities it sends in each request's _meta, and the server advertises its own in the capabilities returned by server/discover. For Tasks, a server must check that the client declared io.modelcontextprotocol/tasks in that request's capabilities and must never return a task to a client that did not, so a server that supports tasks keeps returning ordinary results until the client opts in. The initialize handshake no longer exists in revision 2026-07-28; capabilities travel with every request, so there is nothing to repeat. Extensions are not tied to a transport, and nothing in the Tasks model requires moving from stdio to HTTP. The MCP Registry stores server metadata for discovery and has no role in activating protocol features at runtime. Exam caveat: once both sides opt in, the server still decides per request whether to create a task, so a short call may return an ordinary result anyway. Operational check: inspect an outgoing request's _meta for the extension under clientCapabilities, confirm server/discover lists it, and then retry a long-running call.