Publish 5/19 and 5/22 meeting notes

meetings/2026-05-19.md

@@ -0,0 +1,62 @@
+# 2026-05-19 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1tzAXt2SeW-gPmqac_TcXZ-CGl9vLzAVyEmAzMfFGDs4/edit)
+
+**Date:** May 19, 2026
+**Attendees:** Luca Chang, Vinay Ramesh, Madhavi PDB, Victor Lu
+
+## Discussion
+
+Luca presented a [document surveying existing agent use cases](https://github.com/modelcontextprotocol/agents-wg/pull/10) in publicly-available, production MCP servers. The group analyzed two concrete examples — the AWS Q Business tool and the GitHub Copilot assign-to-issue tool — then transitioned into Vinay's proposed framework for categorizing agent use cases across consumer, coding, and enterprise domains.
+
+### Production Agent Use Cases: Q Business
+
+Luca described the [Q Business tool](https://github.com/awslabs/mcp/tree/main/src/amazon-qbusiness-anonymous-mcp-server) from the AWS MCP server as a system that already existed independently and was wrapped with an MCP interface. The MCP wrapper operates as a single-shot stateless call, making a single tool call sufficient for the use case. Upon clarification from Vinay, Luca noted that the underlying Q Business API does support multi-turn interactions via a conversation ID — a parameter that a calling agent could manage explicitly if the wrapper surfaced it. Luca noted this aligns with [SEP-2567](https://modelcontextprotocol.io/seps/2567-sessionless-mcp) (explicit state handles), where session use cases can be handled by surfacing an ID as a tool parameter.
+
+Vinay noted that session or conversation IDs should not be exposed directly to the agent, arguing these should be managed at the protocol or authorization level rather than requiring the LLM to handle them. Luca acknowledged this and noted that tasks were introduced specifically to lift this kind of low-value, undifferentiated work to the application level.
+
+### Production Agent Use Cases: GitHub Copilot
+
+Luca described the GitHub Copilot ["assign Copilot to issue" tool](https://github.com/github/github-mcp-server/blob/main/pkg/github/copilot.go), which dispatches a Copilot instance to work on a GitHub issue and ultimately produce a pull request. The current implementation uses a polling mechanism — the MCP server holds the connection open and polls at one-second intervals, notifying the client via progress notifications.
+
+Luca proposed that modeling this as a task would eliminate the need to maintain an active server connection throughout the operation. Under a task-based model, the polling interval would be assigned on the task object itself, and the `tasks/get` operation would retrieve the current state. Vinay confirmed that existing task semantics already solve this case, as it involves no elicitation or sampling — it is a one-shot long-running operation.
+
+### Task Steer Proposal
+
+Luca referenced an [existing proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2669) that proposes a `task/steer` method enabling multi-turn interactions with a task, under a model where tasks are used as an abstraction over agents. The author had originally suggested including it in the [tasks extension](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663) itself. Luca noted he had not yet had time to fully review it. Vinay observed that this would change the semantics of how tasks currently operate. Luca explained this was the reason he had initially rejected it from the tasks extension — the scope was already large — but expressed interest in exploring it as a follow-on.
+
+### Framework for Categorizing Agent Use Cases
+
+Vinay presented a framework dividing agent use cases into consumer, coding, and enterprise domains, with interaction patterns categorized as:
+
+1. **Client-side multi-turn:** The server is stateless; the host provides interaction history or additional context on each invocation.
+2. **Server-side multi-turn:** A protocol-level identifier (task or otherwise) enables the server to persist state across invocations, governed by the server's lifecycle.
+3. **Agent definition:** The server publishes how its tools or resources can be composed, enabling the host to construct agent behavior from that definition.
+
+For consumer applications, Vinay used a shopping agent as an example of server-side multi-turn: a session identifier persists information across a shopping session, with individual tasks (buying a product, building a recipe) governed by the server's lifecycle. He noted that task lifecycles and session identifiers serve distinct purposes — a session spans multiple tasks.
+
+### Coding Agent Requirements
+
+Vinay highlighted that coding agents have a distinguishing characteristic: a shared file system primitive and potentially a shared execution environment. Agent definitions in this context describe how agents can participate in a shared workspace.
+
+Vinay described two patterns for coding: client-side multi-turn where the host grants access to shared state (e.g., a triage agent and a coding agent with different capabilities but shared workspace access), and server-side interactions where sensitive data constrains what can be exposed (e.g., a triage agent can describe what is being debugged but cannot share the underlying data). Luca noted that the server-side case maps directly onto the explicit state handles concept from [SEP-2567](https://modelcontextprotocol.io/seps/2567-sessionless-mcp), where an ID is associated with an underlying resource.
+
+### Enterprise Agent Requirements
+
+Vinay described enterprise scenarios using an electronic health record (EHR) system as an example, where a hospital's client assistant interacts with an EHR agent. Enterprise use cases require prescriptive control over tool access due to compliance, regulatory, and data egress constraints. Vinay concluded that agent definition protocols may suffice for consumer-grade tools, but enterprise systems likely require more robust server-side primitives.
+
+### Events and Tasks Integration
+
+Madhavi raised the relationship between trigger events and the current work on tasks. Luca noted that one thing tasks currently lack is a form of intermediate results, and events would be a natural fit for reporting progress from within a running task.
+
+**Update 5/27:** This is the subject of a Triggers & Events WG proposal: https://github.com/modelcontextprotocol/experimental-ext-triggers-events/pull/2
+
+### Gemini and DevTools MCP Server Research
+
+Madhavi mentioned ongoing research into how the Gemini and DevTools MCP servers manage file system interactions, observing that these servers appear to use multiple tool calls to interact with file system state rather than attempting to return everything in a single response. Luca expressed interest in hearing more as the research progresses.
+
+## Follow-ups
+
+- **@LucaButBoring**: Contact @SamMorrowDrums from GitHub to discuss the [Copilot use case](https://github.com/github/github-mcp-server/blob/main/pkg/github/copilot.go) as a potential adopter of the task abstraction.
+- **@vinoo999**: Submit a pull request to the Agents WG repo summarizing the consumer/coding/enterprise interaction pattern framework.
+- **Madhavi PDB**: Research event notifications and existing patterns in the Gemini and DevTools MCP servers, and document findings.

meetings/2026-05-22.md

@@ -0,0 +1,85 @@
+# 2026-05-22 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1dkUrdch_Xa3X5NC_X_kMGzNfjVQfwTQVdX6HiAJ0q0o/edit)
+
+**Date:** May 22, 2026
+**Attendees:** Luca Chang, Caitie McCaffrey, Sriram Panyam, Thierry Damiba, Madhavi PDB
+
+## 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](https://github.com/modelcontextprotocol/conformance) 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](https://github.com/modelcontextprotocol/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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663) 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:
+1. How to specify the minimum MCP spec version an extension requires (or all versions it supports).
+2. 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](https://github.com/modelcontextprotocol/experimental-ext-tasks), review them, and merge to main — similar to the [Transports WG](https://github.com/modelcontextprotocol/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](https://github.com/modelcontextprotocol/experimental-ext-triggers-events) 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](https://github.com/modelcontextprotocol/ext-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](https://github.com/modelcontextprotocol/csharp-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-25` version is only viable if both client and server support only `2025-11-25`.
+- There is no formal support guarantee or deprecation timeline for `2025-11-25` tasks — 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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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](https://github.com/modelcontextprotocol/experimental-ext-tasks/pull/2) in the extension repository and review [PR 2756](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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](https://github.com/modelcontextprotocol/csharp-sdk) to enable field and method overrides.
+- **@CaitieM20**: Land transport-level [conformance tests](https://github.com/modelcontextprotocol/conformance) 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.