{"version":"2.1.239","anchor":"mcp-servers-can-return-a-task-result-but-nothing-asks-for-on","canonical_anchor":"mcp-servers-can-return-a-task-result-but-nothing-asks-for-on","heading":"MCP servers can return a \"task\" result, but nothing asks for one yet","tier":"soon","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239\/e\/mcp-servers-can-return-a-task-result-but-nothing-asks-for-on","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239","markdown":"### MCP servers can return a \"task\" result, but nothing asks for one yet\n\nMCP servers can return a task result, but nothing opts in so they are rejected.\n\n**What**\n\nThe MCP client can now accept a `task` result from a server, but only when the individual request opts in, the server advertised the tasks extension, and the payload validates. Nothing in this build sets that opt-in, so every `task` result currently ends in an unsupported-result-type rejection.\n\n**Details**\n\n- The opt-in flag is read in exactly two places, the request path and the tool-call path, and set in none.\n- The flag and the extension name did not exist in 2.1.238 at all.\n\n**Evidence**\n\n`io.modelcontextprotocol\/tasks`\n\n- Area: MCP\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}