MCP Core Maintainer Meeting - August 12, 2026

[localden]

Attendees:

• David Soria Parra (@dsp-ant)
• Caitie McCaffrey (@CaitieM20)
• Nick Cooper (@nickcoai)
• Kurtis Van Gent (@kurtisvg)
• Clare Liguori (@clareliguori)
• Ola Hungerford (@olaservo)
• Aaron Parecki (@aaronpk)
• Alex Hancock (@alexhancock)
• Max Isbey (@maxisbey)
• Sambhav Kothari (@sambhav)
• Ido Salomon (@idosal)
• Luca Chang (@LucaButBoring)
• Liad Yosef (@liady)

Purpose: Walk working-group leads through the core maintainers' proposed roadmap themes for the next six months and collect input ahead of a draft roadmap, agree on release cadence, and decide whether the Skills SEP is ready for a vote.

Key Decisions

1. Roadmap themes for the next six months

@dsp-ant presented the rough themes the core maintainers have converged on. These are directional rather than stack-ranked. Prioritization happens by which working groups actually commit effort, and themes that don't attract a driver deprioritize themselves.

The themes as presented:

• Agentic messaging primitives (@CaitieM20): harden the newer messaging patterns and the Tasks extension, coordinate with Triggers & Events, and add the primitives people keep asking for in agentic scenarios, such as partial results, streaming, and steering/updates to long-running operations. This does not introduce a core "agent" concept, since there is no alignment that tools and agents are meaningfully different. @kurtisvg flagged that he wants a path for some version of Tasks to land in the core spec rather than accreting things that keep it extension-only. @dsp-ant said the near-term job is for implementers to actually ship Tasks and feed back.
• Transport rationalization: with streamable HTTP aligned to standard HTTP patterns, the duplication between the data layer and the transport layer is increasingly annoying. @dsp-ant has prototyped running HTTP/2 over stdin/stdout, which would let stdio reuse HTTP semantics (headers, ETags, caching) and collapse the duplicated fields.
• Confidential parameters/configuration (@kurtisvg, @nickcoai): there is no standardized way to pass confidential parameters (credentials, instance/database selection) to remote servers, which is a major friction point in moving people off stdio. The goal is one precise answer for where each parameter type goes (args vs. env vars vs. header vs. _meta), across transports. Kurtis to reword the theme so it doesn't read as HTTP-specific.
• Enterprise security and agent identity (@aaronpk): proof-of-possession and other enterprise requirements as natural extensions of the authorization work, plus an opinionated, standards-based approach to first-class verifiable agent identities, distinct from today's human-centric OAuth flows.
• Improved primitives (@dsp-ant): make resources behave like a proper remote file system (hierarchical listing instead of infinite depth, range reads, put/upload) without reinventing WebDAV, make tool calls polymorphic in return type (the client says whether it wants structured or unstructured) instead of returning both, and run a dedicated work stream on progressive discovery with more server-side control, generalizing earlier attempts like primitive grouping.
• SDK automation (@dsp-ant): explore how far conformance tests plus model capabilities can go toward generating parts or all of SDKs, to reduce the large maintenance burden. @olaservo noted this doubles as a test of whether the spec is actually unambiguous. It will require supplementary specs for SDK-facing details (e.g. version-negotiation strategy) that the protocol spec doesn't capture.
• Ecosystem growth/extension adoption (@clareliguori): added during the meeting. Getting clients and servers to actually adopt extensions, so popular ones can stabilize and graduate into the spec, is a big enough risk to deserve a named theme.

Also raised for consideration: reworking content annotations (@olaservo noted the audience metadata is unused today), possible prompt deprecation, "graph over MCP" where servers return links to other resources (@sambhav noted it's close to progressive discovery), a standardized server feedback/intent mechanism (@idosal explained that servers today invent intent or reasoning tool arguments to learn why they were called, which has leaked entire conversations), and SDK versioning guidance (@LucaButBoring described debugging across a dozen client and SDK versions, and @nickcoai hopes this falls out of transport rationalization).

Outcome: Themes resonated with no objections. The group adopted @nickcoai's suggestion that core maintainers check in every 4 to 8 weeks and explicitly drop themes that fall below a threshold of interest and engagement. Working groups to bring their input (deliverables, additional themes) within the week.

2. Early core-maintainer alignment for SEPs

Prompted by @sambhav asking why in-flight extensions (Skills, interceptors) aren't on the roadmap and observing that extensions struggle without core-maintainer involvement. @clareliguori noted the extensions that moved fast all had a core maintainer engaged early. @kurtisvg argued the real lesson from the transport WG is early alignment on the problem statement, since agreement inside a working group alone isn't enough, and drive-by SEPs with problem and solution bundled together waste cycles. @dsp-ant doesn't want mandatory periodic reporting (churn without outcome) and would rather working groups proactively ask for meeting slots.

@alexhancock proposed using the SEP format itself: authors write just the preamble, abstract, and motivation and present those to core maintainers early, which gives enough signal to confirm directional alignment before serious investment. @olaservo added it would also filter AI-generated proposals.

Outcome: Consensus on the lightweight early-presentation approach. @alexhancock to look at existing processes and drive a concrete recommendation (via the governance WG channel). Interceptors specifically needs more consensus-building on its usefulness (use cases, conversations) before a vote makes sense.

3. Release cadence: six months, no slipping

@kurtisvg asked whether four months was feasible. @CaitieM20 and @maxisbey pushed back on the grounds that big platforms can barely absorb a spec change every six months, and many are still adopting the last release. @dsp-ant said six months is the fastest a spec of this kind can go, and twelve would be ideal but too slow for AI. @nickcoai noted that fixed dates mean features roll to the next release rather than the date slipping, and that if SDK automation succeeds the cadence could tighten later.

Outcome: Next specification release on December 15, firm, with no slipping (@clareliguori insisted on this) and the following release on June 15. Features that miss the date roll over. @dsp-ant to reconcile the backward schedule (which still says December 1) with this date, and core maintainers confirm the final date next week.

4. Roadmap timeline

• Working groups and interest groups add their input (mini-roadmaps, deliverables, themes) to the roadmap doc this week.
• Part of the exercise is to review the proposed list of working and interest groups and decide which should exist and which should close, plus attention to non-protocol work (governance, processes, ecosystem).
• @dsp-ant assembles the draft roadmap on August 19 (he's out from the 21st), leaving a couple of days for review. Roadmaps are directional. Expect a re-look at the roadmap when the RC freezes so working groups have direction through the freeze.

Outcome: Draft roadmap lands August 19. @dsp-ant to announce the process again in the maintainer channel for those not present.

5. Skills SEP: not voting yet

@olaservo presented the current state: archives removed, data-passing and enumeration/fetching semantics updated, rationale moved to the WG repo to keep the SEP readable, threat model documented. OpenAI has shipped preliminary support in their plugins, and several adopters are implementing against the draft and waiting for an official v1.0. Remaining items (caching guidance, more opinionated defaults, limits on skill count and size) were framed as post-vote follow-ups. @CaitieM20 and @clareliguori supported voting now, since teams are waiting for it to be official. @dsp-ant initially leaned toward voting and accepting with changes.

@kurtisvg, back from being out and not yet through the latest revision, then raised concerns:

• The spec supports both a virtual file system representation and a download-to-local-file-system install path, and the "no implicit local execution" security requirement is ambiguous with respect to scripts. He'd argue for clients consistently using the virtual file system for security reasons, but the local path is easier, so that's what clients will do. @olaservo said local install is the expected default and the spec needs to be more opinionated about saying so.
• When clients diverge, servers target the minimum viable subset (as happened with elicitation and Tasks). Google wants to implement this, and internal security concerns plus competing alternatives make consistency matter.
• Every connecting client downloading e.g. 150 skills, with a request per resource, is real strain on servers.
• skills/list enumerating each skill's resources, skills/get, and reading the directory via resources are three ways to get overlapping answers that can disagree, repeating the confusion the group has seen with sessions and structured content. @olaservo said the breadth exists because adopters brought very different scenarios (including unbounded skill lists where a full index is impractical) but agrees the default path needs another opinionated pass.
• How access to skills is locked down, and how skills interact with user permissions, isn't addressed in the spec.
• He'd prefer a smaller v1 subset extended incrementally over covering every scenario at once.

@olaservo pushed back on staying in limbo: adopters have been asking for a citable v1.0 for months, changes can still land after a v1, and the process has been genuinely frustrating from the author side. @dsp-ant was sympathetic but noted that whatever ships as v1 will effectively be the shape of skills-over-MCP for a long time. If the delta were small he would vote and fix after, but these concerns don't look small, so better to resolve them first.

Outcome: No vote yet. @kurtisvg to write down his concerns (doc or PR comments) as the basis for discussion. He and @olaservo meet early next week to work through them, and @dsp-ant is told when the group is ready to vote.

Actions

• Working group leads: add your group's roadmap input (deliverables, themes) to the roadmap doc within the week, and review and comment on the proposed list of working and interest groups.
• Core maintainers: check in on roadmap themes every 4 to 8 weeks and drop those below the interest threshold, and confirm the December 15 release date.
• @dsp-ant: produce the draft roadmap by August 19, update the backward schedule, and re-announce the roadmap process in the maintainer group for those not present.
• @clareliguori: add ecosystem growth/extension adoption as a roadmap theme.
• @alexhancock: drive a recommendation for presenting SEP preamble, abstract, and motivation sections to core maintainers early, via the governance working group.
• @kurtisvg: document Skills SEP concerns in a doc or on the PR, reword the confidential-parameters theme, and meet with @olaservo early next week.
• @olaservo: review Kurtis's write-up, address the gaps around default installation path, listing redundancy, and governance, and signal when the Skills SEP is ready for a vote.

[WSorr]

The “first-class verifiable agent identities” direction is interesting, but I think there is one layer that should probably remain below agent identity itself.

We are experimenting with a durable person-owned principal that exists independently of any agent, model, runtime, wallet or MCP session.

Agents are replaceable delegates. They receive bounded capabilities from that principal.

That gives a different decomposition:

principal -> bounded capability -> agent/runtime -> effect -> receipt

The agent identity can prove who the delegate is, but it should not become the root of authority.

Otherwise replacing the agent/runtime risks silently changing the authority model.

In our current experiment, a personal runtime delegates a 24h trading mandate to a remote agent while the principal remains offline. The remote model/runtime may change; the mandate must not.

So I’m curious whether the agent-identity work here is expected to model only delegate identity / proof-of-possession, while root authority remains external to MCP, or whether MCP eventually intends agent identity to carry authority semantics too.

My instinct is that keeping those separate will matter a lot once agents become ephemeral and replaceable.