agents-wg

SEP-2133 establishes that extensions evolve independently of the core protocol and SHOULD be versioned, but it leaves the versioning approach unspecified and defers extension dependency declaration to future work. This proposal fills both gaps with a single mechanism. Each extension carries a semantic version in its settings object, and MAY declare the core protocol version its behavior depends on. A difference in the major version means the two peers are incompatible; they negotiate a shared major version through inline retry, as they negotiate a protocol version (see protocol version negotiation). A difference in the minor version is not a conflict: each peer uses the features common to both, and neither rejects the other. A difference in the patch version changes nothing about how the peers interoperate. A new error code, (Unsupported Extension Version), reports a major-version mismatch and tells the client which major versions the server supports, so it can retry against one of them. Motivation and Context SEP-2133 scoped itself narrowly: it defined how extensions are governed, identified, and negotiated, but excluded two compatibility concerns from its scope. Under _Not Specified_, it omits both extension dependencies on core protocol versions and a concrete versioning approach, recording only that "Extensions SHOULD be versioned, but exact versioning approach is not specified here." Three problems follow from those omissions, and each currently surfaces as a runtime failure rather than a negotiated outcome. 1. An extension's protocol-version dependency is undiscoverable. 2. An extension cannot roll out a breaking change of its own. 3. Optional, non-breaking features cannot be advertised. This proposal address all three issues by introducing a versioning scheme and negotiation pattern that can generalize across extensions. Based on #11 from and my previous versioning draft. How Has This Been Tested? Hasn't. Breaking Changes Technically if extensions are already using as a settings field, but as far as I've seen they aren't. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [x] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [ ] I have added or updated documentation as needed Additional context AI Use Disclosure: Claude wrote this and I made it revise its own work for several hours after I tore it apart.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] I see a lot of confusion about agents, skills, sub-agents and other related concepts as they are implemented in various frameworks, such as LangGraph or Strands. The confusing terms are leading to complex implementation and hard migration between frameworks. Describe the solution you'd like A clear and concise description of what you want to happen. Agents can be described as a combination of LLM, instructions, and tools, working in ReAct or other simple loop definitions. Tools are best defined as MCP tools, and therefore, agents should be defined as MCP clients, with additional definition of LLM and instructions. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Another level of abstraction is the ability to create a team of agents, by creating an MCP server, where each agent is a tool. Since we defined an agent as LLM, instructions, and a set of MCP servers, we can build specialized agents that each uses a different LLM, work under different instructions, and utilize different MCP servers. Using the MCP protocol, the agents can discover which other agents are available in their team, by reading the description of the tools, and call them in the same way they call other MCP tools. Each agent can forward any part of the original task to any of the other agents through this bridge. With the support of MCP tasks, such calls are easy to monitor, pool, and get the results, making the otherwise complex team orchestration, a standard MCP based workflow. In interactive MCP clients such as Claude Desktop, the users can choose to read resources and trigger prompts to enrich the conversation context with additional relevant information. Once we define agents as MCP clients, we can instruct them to also read resources from each or any MCP server (for example, default agent:instructions, or agent:skill:code-review), and trigger prompts. Additional context Add any other context or screenshots about the feature request here. The MCP perspective is not only semantic of shifting from agents with tools, to tools with instructions and LLM. It allows to describe the agentic framework with the minimal set of concepts (Occam's razor), and the development of the MCP spec toward this goal.

This document captures observations from building and operating production deep-agent systems and compares those capabilities against existing MCP primitives and emerging MCP extensions. The goal is not to propose a specific solution, but to understand: Which production agent capabilities are already covered by MCP Which capabilities can be modeled using existing MCP patterns Where protocol gaps may exist for agent-oriented systems Which areas may benefit from future agent definitions, delegation primitives, capability discovery, or orchestration-related extensions