No client-suite scenarios for the tasks extension (io.modelcontextprotocol/tasks) #374

Activity

1. realmehmetali commented on Jul 18, 2026

   

   realmehmetali

   on Jul 18, 2026

   More actions

   I would like to take a focused first slice of this. After reviewing the current client-scenario harness, AGENTS.md, and src/seps/sep-2663.yaml, I propose one end-to-end tasks-client-lifecycle scenario rather than separate create/poll/header scenarios.

   The mock server would negotiate io.modelcontextprotocol/tasks, return a normal CallToolResult for one supported call and a CreateTaskResult for a task-capable call, then expose working → completed states through tasks/get. One run can emit checks for:

   • sep-2663-client-handles-polymorphic-result: the client handles both result shapes after negotiating the extension.
   • The client follows the returned taskId with tasks/get rather than treating the task envelope as a completed tool result.
   • sep-2663-client-emits-mcp-name-on-tasks-methods: each observed tasks/get carries Mcp-Name: <taskId>.
   • The client reaches and handles the terminal completed result without continuing to poll.

   I would extend the existing everything-client as the passing implementation and add deliberately broken client handlers for at least “treat CreateTaskResult as complete / never call tasks/get” and “poll without Mcp-Name”, with tests asserting the corresponding failures.

   I would leave pollIntervalMs cadence out of this first PR because the traceability YAML currently marks it excluded as client-internal behavior, and leave “CreateTaskResult on an unsupported request type” for a separate mutually-exclusive negative scenario. Does that boundary match the WG’s intended client-suite design?
2. dhruvtv commented on Sep 29, 2026

   

   dhruvtv

   on Sep 29, 2026

   More actions

   • We'd like to pick this up, since Add client conformance for SEP-2663 task results #405 closed when its author's account was deleted.
   • Plan: one tasks-client-lifecycle scenario (as suggested above) that also covers Add client conformance for SEP-2663 task results #405's review point: the tasks capability on every task operation.
   • Is that scope right before we open a PR?
3. realmehmetali commented on Oct 6, 2026

   

   realmehmetali

   on Oct 6, 2026 – with ChatGPT Codex Connector

   More actions

   Thanks for taking this forward, @dhruvtv. One lifecycle scenario matches the shape I proposed. The review on #405 is worth preserving: validate the extension capability on every task operation exercised, and separately test a client that polls but omits that capability, alongside the no-poll and missing Mcp-Name cases. The current traceability YAML still excludes polling cadence, so I would keep that out of this first slice. Maintainers should confirm the final scope and check IDs.