modelcontextprotocol/agents-wg
Watch
1
0
Fork
You've already forked agents-wg
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Publish 5/29 meeting notes

Browse source
This commit is contained in:
Luca Chang 2026-05-29 13:52:33 -07:00 • committed by Luca Chang
commit 3d259e98db
1 changed files with 58 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

58
meetings/2026-05-29.md Normal file
View file

@ -0,0 +1,58 @@
# 2026-05-29 Agents WG
> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1WV4GrCPiCOIYfSE_ObtmQUKF_NkYBiISUPisyWDETdU/edit)
**Date:** May 29, 2026
**Attendees:** Luca Chang, Caitie McCaffrey, Sriram Panyam, Thierry Damiba, Madhavi PDB
## Discussion
The meeting followed up on action items from the previous week: the conformance test PR for tasks and the extension versioning proposals.
### Tasks Conformance Tests
The group discussed Sriram's [conformance test PR](https://github.com/modelcontextprotocol/conformance/pull/262) for tasks, which implements stateless functionality ([SEP-2575](https://modelcontextprotocol.io/seps/2575-stateless-mcp)) and addresses earlier feedback from Jordan. He has a follow-up for MRTR+tasks that will be raised separately to avoid overloading the current PR.
Caitie and Luca clarified that neither is a maintainer of the conformance repository, so the PR requires sign-off from Paul and the other conformance test maintainers. Sriram confirmed Luca had already pinged Paul, who expects to review it this week. Sriram wants to merge the initial round of tests before the PR grows too large, especially as more changes land in main. Caitie noted the core team is rewriting the conformance tests, so it is worth understanding how this work integrates; Sriram mentioned the PR includes refactored shared helpers that may be useful for the rewrite. Caitie encouraged Sriram to join the conformance working group, suggesting he ping Paul to volunteer time since the group is busy.
### Conformance YAML Requirement
Caitie raised that the conformance repository now requires each new component check-in to include a YAML file enumerating the MUST/SHOULD statements from the specification, mapping each to a conformance check (or an explicit exclusion). This ensures all spec language is enforced by tests. A skill generates the YAML by pointing it at the spec documents, avoiding manual creation. Caitie pointed Sriram to the [SEP-2322 YAML](https://github.com/modelcontextprotocol/conformance/blob/7d3b897618927422a27c98e520c999ad07dcc9d6/src/seps/sep-2322.yaml) as an example, noting this requirement is new as of two weeks prior.
The group agreed the YAML should be generated from the extension's specification documents in the [extensions repository](https://github.com/modelcontextprotocol/experimental-ext-tasks) as the source of truth, rather than from the SEPs, since the spec documents themselves are the ground state and are written separately. The conformance tests and YAML will all live in the conformance repository. The YAML will need to be added to [#262](https://github.com/modelcontextprotocol/conformance/pull/262), with the understanding it need not be exhaustive initially.
Tests are currently organized by SEP, but organizing by feature will likely be necessary as more SEPs are layered on, since the SEP-based format will become harder to maintain over time. The group agreed the current approach works for this release.
### Extension Versioning Proposals
Luca presented two extension versioning proposals from [himself](https://github.com/LucaButBoring/mcp-agents-wg/blob/feat/extension-versioning/proposals/XXXX-extension-versioning.md) and [Thierry](https://github.com/thierrypdamiba/agents-wg/blob/5882956673aa4f05ebac2b5fe35d06e12ff1d590/proposals/XXXX-tasks-versioning.md), highlighting key differences representing design decisions worth taking positions on. Among other points, both address a requirement in [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions) that a breaking change to an extension requires a new extension identifier.
- **Thierry's proposal** takes SEP-2133 at face value: a breaking change introduces both a semantic version (for comparability) and a new extension identifier.
- **Luca's proposal** interprets SEP-2133 liberally: a version parameter is added to the extension capabilities, and breaking changes are gated on that version. Because the change is gated on the version, it is not treated as a breaking change to the extension itself, so no new identifier is required.
Caitie worked through a hypothetical of removing `tasks/cancel` to ground the discussion, clarifying for Madhavi that this was illustrative and not planned. Madhavi asked why adding a version parameter would be a breaking change; Luca clarified that adding the parameter is not breaking — the discussion concerned how to handle a future breaking change to tasks itself, such as removing or renaming a method.
Caitie's inclination was to have extensions not rename themselves and instead embed a version in the extension settings, leaning toward semantic versioning over a date-based format. She noted the date format used by the core protocol is conventional, not required, and effectively limits the protocol to major versions, whereas semantic versioning would allow frequent minor releases without a large release mechanism.
### Proving Ground for Versioning
Caitie framed tasks as a proving ground for extension versioning, which she had preflighted with the core maintainers, with the intent of standardizing the approach across other extensions later. Luca encouraged interpreting the proposals as applying to extensions generically rather than to tasks specifically, since tasks is in the unique position of being bounced between the core spec and an extension.
Caitie identified three version-related problems that a solution needs to address:
1. An extension depending on a particular protocol version.
2. Making a breaking change to an extension between protocol versions, and letting people roll it out.
3. Letting SDKs, clients, and servers indicate support for new optional, non-breaking extension features.
She stated a goal of moving tasks back into the core protocol by the next protocol version, encouraging the group to make any necessary breaking changes before then. She noted the timing of the next spec release is still undecided — potentially as late as early 2027.
On the first problem, Caitie noted that declaring a minimum protocol-version floor may be insufficient: if the protocol later makes a breaking change, a floor-based declaration may no longer hold, implying a server might need to enumerate every supported version. Since that is burdensome for server maintainers to keep updated, she suggested it could be resolved through client-side implementation guidance rather than strict enforcement, so older un-updated servers keep working.
Caitie also reframed what the versioning machinery needs to accomplish in two directions. First, clients need to understand what requests they can send a server and expect a reasonable response, which is largely solved by server discovery — a server advertising its pinned protocol version and supported extensions. Second, servers, when receiving a request, need to understand what extensions a client supports across extension/protocol versions, including whether the client supports tasks (or some other extension) at all.
## Follow-ups
- **@panyam**: Add YAML file enumerating all spec language checks as a follow-up to [#262](https://github.com/modelcontextprotocol/conformance/pull/262).
- **@CaitieM20**: Do a deeper review pass on [#262](https://github.com/modelcontextprotocol/conformance/pull/262), and ping Paul and core maintainers next week on its status.
- **@CaitieM20**: Review the [PR](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2756) on the `2025-11-25` task compatibility mapping.
- **@LucaButBoring**: Draft updated versioning proposal outlining the three core problems to solve and two decision points (major versions within the extension version field vs. duplication via identifier; date-based vs. semantic versioning), with canonical examples for protocol dependencies, breaking changes, and optional feature support; review the proposal with Thierry.
- **@LucaButBoring**: Circulate the versioning proposal with Peter and the MCP Apps and Events & Triggers WGs for early feedback before core maintainer review.