8.6 KiB
2026-05-22 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: May 22, 2026 Attendees: Luca Chang, Caitie McCaffrey, Sriram Panyam, Thierry Damiba, Madhavi Pasumarthi
Discussion
This session was extended to one hour and dedicated to the Tasks extension. Luca explained that going forward, meetings will combine tasks and agents discussions, with tasks frontloaded as the more urgent topic. The group covered conformance testing strategy, release timeline, extension versioning, SDK implementation challenges, backwards compatibility with 2025-11-25 tasks, and meeting cadence.
Conformance Test Strategy
Caitie described the current push to land SSE conformance tests required for the release candidate. The conformance test structure is being reorganized from scenario-based to feature-based, which maps better to extensions. The group adopted "Option Path C": stabilize the current test suite, then refactor at the RC stage.
The goal is to make tests more pluggable for non-SDK servers — allowing developers who roll their own implementations or don't use a standard SDK to verify compliance. Caitie noted that Microsoft has inconsistent MCP server implementations across teams and that customers now expect consistent behavior. Luca confirmed AWS has similar issues, with most people using the MCP Inspector for smoke testing despite its inconsistencies with other off-the-shelf clients.
Release Timeline
The spec release target is now July 28, with SDKs in beta by June 30. Caitie noted the focus is on release quality rather than strict date adherence. The tasks extension should land with at least a couple of SDK implementations by the July release. The extension depends on the new RC, so that must be locked down first.
Extension Versioning
Versioning was identified as a barrier to adoption. Luca noted that Google (per Kurtis) has stated no intention to adopt extensions until a stable versioning story exists, as they need to offer stability guarantees. Caitie proposed the group use tasks as the wedge to figure out versioning for all extensions.
The two dimensions to solve:
- How to specify the minimum MCP spec version an extension requires (or all versions it supports).
- How to create semantic versioning for the extension itself, decoupled from the main specification version.
Luca agreed to draft a versioning proposal. Madhavi raised whether TTL scope and caching (e-tags) could support versioning logic. Caitie responded that caching helps with data versioning within a spec version, but something more deterministic is needed for extension spec versioning itself.
Governance
The group agreed to draft proposals as PRs within the extension repository, review them, and merge to main — similar to the Transports WG's process. These will be informal conventions until the next main spec release. If the approach works for tasks, it could become the standard for all extensions. Caitie noted the Triggers & Events WG is also coming up as an extension and may benefit from the same conventions.
A2A Task Alignment
Caitie noted that ideally, MCP tasks will evolve to align more closely with A2A tasks — developers often look at the two and expect them to map to each other. While the two are currently disjoint in feature sets — Luca noted that while MCP tasks did draw from A2A tasks, MCP tasks as they exist today are more analogous to C# tasks (async operations) whereas A2A tasks are conceptual to-do items — both communities want them to evolve in a similar direction. The group agreed to use A2A's design as a stronger reference point, while doing what's right for MCP and ensuring differences from A2A are deliberate.
SDK Implementation and Result Type Extensibility
Luca raised that tasks straddles the line between purely additive extensions (like MCP Apps, which have their own separate SDK) and deeply integrated features (like auth). Tasks adds new methods and modifies existing ones, including the resultType layer, making it potentially infeasible to implement entirely outside an existing SDK.
resultType is currently defined as a union of specific string literals. Luca proposed adding an explicit requirement that clients treat unrecognized result type values as invalid responses. This preserves the union definition while making it safe to extend in the future — when an extension adds a new value, it is no longer "unrecognized" for clients that support that extension. Caitie agreed and asked Luca to submit a PR with this change, including a note in the schema that SDK maintainers must accept values beyond the base set.
Update 5/28: This is now complete: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2773
Caitie also committed to submitting a PR to the C# SDK to enable field and method overrides, unblocking extension development outside the core SDK.
Backwards Compatibility with 2025-11-25 Tasks
The group discussed how to handle servers and clients that may support both the old 2025-11-25 experimental tasks specification and the new extension. Rather than writing exhaustive conformance tests for every permutation, Caitie proposed a matrix table documenting expected behavior based on which versions each side supports. The key rules:
- If both sides support the new extension, use it.
- Using the old
2025-11-25version is only viable if both client and server support only2025-11-25. - There is no formal support guarantee or deprecation timeline for
2025-11-25tasks — it was experimental and SDKs can simply remove it.
Luca agreed to remove the confusing additional requirement from the spec and add a compatibility matrix to the backwards compatibility section of SEP-2663.
Update 5/22: This is now proposed: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2756
Client Support Attestation
Caitie noted that four or five clients on the MCP website claim to support tasks, but there is no attestation mechanism — they simply declare it. VS Code is known to support 2025-11-25 tasks; GitHub Copilot's support status is uncertain. Conformance tests could eventually serve as verification, but this is not urgent.
Thierry volunteered to help and was assigned to draft a proposal for how to handle task support documentation on the client list, to present at the next meeting.
Google DevTools MCP Server Findings
Madhavi reported that the Google DevTools MCP server has no tool-to-tool or multi-turn internal communication. It functions as a standard MCP server, relying on its file system SDK, client state, and LLM intelligence rather than passing data between tools or tasks.
Meeting Cadence
Luca raised whether the meetings should move from bi-weekly to weekly. Caitie agreed, noting it would maintain momentum on the tasks extension and provide a forcing function for reviewing PRs.
Follow-ups
- @CaitieM20: Approve the tasks PR in the extension repository and review PR 2756 (task correction).
- @LucaButBoring: Submit a PR to make result type extensible, adding an explicit requirement that clients treat unrecognized values as invalid responses.
- @LucaButBoring: Update the backwards compatibility section of SEP-2663 with a matrix table, removing the confusing additional requirement.
- @LucaButBoring: Draft a versioning proposal for extensions.
- @CaitieM20: Submit a PR to the C# SDK to enable field and method overrides.
- @CaitieM20: Land transport-level conformance tests in the existing framework.
- Thierry Damiba: Draft a proposal for how to handle task support documentation on the client list; present at next meeting.
- @panyam: Follow up on stateless conformance tests after Paul merges the current round.