Add 7/31 meeting notes

meetings/2026-07-31.md

@@ -0,0 +1,59 @@
+# 2026-07-31 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/17tB4UEd_JOQJPh_rHb6tengAOgn2aj781x3uFajkooI/edit)
+
+**Date:** July 31, 2026
+**Attendees:** Luca Chang, Madhavi PDB, Sriram Panyam
+
+## Discussion
+
+The meeting covered two threads: kicking off roadmap planning for the next MCP specification release, and continuing the `agent/list` work from the [prior weeks](2026-07-24.md) — now grounded in Madhavi's working Python SDK implementation, with the discussion centering on tool schema consistency and TTL design during rolling deployments. The roadmap thread also branched into a broader exchange on evolving tasks into an agent-to-agent communication primitive and the authorization questions that raises.
+
+### Roadmap Process and Agent-to-Agent Communication
+
+Luca explained the roadmap procedure: working groups submit high-level one-sentence goals to core maintainers via a private channel, which then feeds into a public draft on GitHub within a couple of weeks. He shared the Transports Working Group roadmap as a template for what the Agents WG will produce.
+
+Sriram and Luca discussed the potential for tasks to evolve into a more robust agent-to-agent communication primitive. Sriram argued that agents should function as generic infrastructure-agnostic primitives — not restricted to local execution but placeable on different hosts, servers, LLMs, or cloud providers. Luca noted that while there is overlap between A2A concepts and MCP tasks, the value proposition of A2A includes strong governance and authentication mechanisms for operating across trust boundaries. He observed that MCP's current design assumes trust in the server, though existing client-side OAuth primitives could be leveraged to harden cross-boundary communication. Sriram suggested that converging on existing A2A patterns could inform the roadmap rather than reinventing those primitives.
+
+### Authorization Across Multi-Step Agent Workflows
+
+Madhavi raised questions about interceptors and authorization, particularly for agents that spawn multiple tasks or perform actions across different roles. Sriram framed the challenge: a tool call is relatively short-lived and scoped, but an agent that spawns other agents, files Jira tickets, creates pull requests, and sends emails must handle transitive authorization chains — proving permission to act even when the request is five steps removed from the original user interaction. He described the need for multi-step handoffs, possibly requiring user re-consent when crossing scope boundaries.
+
+Luca introduced the concept of subtasks, which would allow tasks to spawn other tasks. He noted this creates potential complications around divergent authentication requirements and could lead to poor user experience if not managed carefully. He noted that step authorization — already an MCP feature — is intended to address tools with divergent auth requirements, but becomes practically annoying when required on every tool call in a long chain, a problem subtasks would compound. Sriram cautioned that overly burdensome authorization flows might push users to bypass them entirely with overprivileged tokens, though he believed OAuth 2.1 has primitives to make such flows less painful.
+
+### `agent/list` and `agent/get` Proposal
+
+Madhavi presented an updated version of her [research document](https://github.com/modelcontextprotocol/agents-wg/pull/20) and a sequence diagram proposing new `agent/list` and `agent/get` RPC methods. The approach is intended to reduce tool sprawl by allowing clients to select specific sub-agents rather than initializing with all tools simultaneously. She walked through her Python SDK implementation: server builders register agents using Data Transfer Objects (DTOs) that associate tool names with agent definitions; `agent/list` returns agent names, descriptions, and capabilities without full tool schemas; `agent/get` returns the scoped tool schemas for a selected sub-agent.
+
+Luca asked about the body of the agent decorator functions in her implementation, clarifying that unlike `mcp.tool` decorators (which contain the tool's actual logic), `mcp.agent` decorators simply call the DTO and do not need implementation. Madhavi confirmed this and demonstrated her code, where agents are registered as strings pointing to tool names, and the DTO handles schema retrieval during `agent/get`.
+
+### Tool Schema Consistency and Caching
+
+Luca raised concerns about tool schema consistency when schemas are embedded in `agent/get` results rather than cross-referenced from a separate `tools/list` call. He described two complications: first, what happens if the same tool has different schema iterations between different agents or between an agent and the top-level tool list; second, how to represent the TTL from `tools/list` in individual agents that share those tools.
+
+Madhavi initially proposed directly retrieving tool handlers at the point of `agent/get`, bypassing the TTL concern. Luca clarified that the challenge is dependency ordering: if tools are nested inside agents, then tool schema changes create an implicit dependency on agent definitions, and the system must handle what happens during rolling deployments when some containers serve the old schema and others serve the new one. He noted that the Transports Working Group roadmap includes tool versioning to address exactly this problem, and that embedding schemas directly in `agent/get` would require extending that system to cover agents too. He suggested that having `agent/get` reference tool names (as pointers into `tools/list`) would allow the agent layer to build on top of the tool versioning work without extending it.
+
+Madhavi agreed to investigate TTL handling. The conversation converged on the question of how a client would know that stale agent information caused a tool call failure during a deployment.
+
+### TTL and Deployment Notification Strategy
+
+Luca explained that reliance on list-changed notifications via SSE streams is inherently inconsistent: those streams drop when the MCP server deploys, and the server does not send a change notification because from its perspective nothing has changed. Madhavi acknowledged that the client must proactively make a fresh call to synchronize when encountering errors, and that without a reliable notification mechanism, the client's only recourse is checking TTL and retrying.
+
+Madhavi proposed implementing an Agent TTL to manage changes in agent capabilities, ensuring the client tracks updates for both `agent/list` and `agent/get`. She raised the question of whether developers should define a separate TTL for `agent/get` or reuse the tool TTL. Luca responded that an Agent TTL is necessary because the client needs to be able to pick up changes to an agent's tool list (e.g., adding a tool to an agent), which is independent of the global tool list.
+
+They discussed whether Agent TTL should supersede Tool TTL. Luca clarified that the two operate independently because agents do not necessarily utilize every tool hosted on an MCP server — they have different scopes. Madhavi initially argued that any tool change affecting an agent should expire the Agent TTL, forcing a refresh; Luca agreed this would be consistent but noted it adds latency by requiring multiple round trips.
+
+The participants reached consensus that any change to tools or agent definitions should trigger expiration of the Agent TTL. While this adds latency due to multiple turns, it provides the most consistent way to avoid runtime errors by forcing the client to perform `agent/list` or `agent/get` when changes occur.
+
+### Implementation Investigation and Trace Analysis
+
+Madhavi planned to examine the code to determine whether she can create an association between tool updates and Agent TTL resets at the handler level. She indicated she would implement try-catch logic to ensure that failed `agent/get` calls route back to refresh the agent definitions. Luca noted that relevant proposals are part of the V2 build of the MCP Python SDK, though he was uncertain about the latest release details. Madhavi said she would verify the SDK implementation status and noted she thought the updates had been released since May 11th.
+
+Madhavi reviewed trace logs showing the initialization flow: `agent/list` calls followed by `agent/get` calls for selected sub-agents. She discussed how different queries might lead to the client holding either all sub-agent schemas or only scoped tool schemas depending on the specific dependencies of the request, though Luca clarified that how much of that information actually goes into the LLM context is an integration choice.
+
+## Follow-ups
+
+- **@LucaButBoring**: Compile high-level one-sentence goals for the upcoming specification release and submit to core maintainers through the private channel.
+- **@LucaButBoring**: Draft a detailed roadmap for the Agents WG and publish on GitHub.
+- **@madhaviai**: Investigate TTL behaviors to determine how to create an association between tool definition changes and Agent TTL resets; verify this can be implemented at the handler level in the Python SDK.
+- **@madhaviai**: Continue pushing updates to [PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20) with the `agent/list` and `agent/get` implementation.