agents-wg/meetings/2026-07-31.md

2026-07-31 Agents WG

Raw Gemini-transcribed meeting notes and transcript available on Google Docs

Date: July 31, 2026 Attendees: Luca Chang, Madhavi Pasumarthi, 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 — 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 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 with the agent/list and agent/get implementation.