tldr; Industry contributors can lead working groups and drive proposals, but final approval authority remains with people whose professional context is platform development, not production deployment in regulated or legacy-constrained environments. These perspectives should inform protocol direction at the decision-making level, not just through advisory channels.

I totally understand where you are coming from and in principle I agree that it should be the aspirational goal. Yet, we are honestly far away and you are right, current Core Maintainers are all from a very similar organizational background. Yet, I am quite hesitant to add any constraints or goals here. I worry it would be very hard to find what sufficiently diverse. Given that I prefer to keep the Core Maintainer group rather small (and honestly with 9 it already is quite big), I think we will always fail to include a wide variety of the industry. I do agree that we can do better here and should focus in the next iteration of the core maintainer group on this.

Thoughts on Protocol Stewardship in the Contributor Ladder

This is an excellent draft—clear structure, well-considered criteria, and the Kubernetes-inspired model makes sense. I'm not raising a criticism or concrete change proposal, just a discussion point.

Full disclosure: I worked through these thoughts with Claude to help articulate them. I usually don't have Claude do my actual writing for me, but my English can be somewhat rambly, and felt this was too important, so please forgive me for not writing this fully by myself.

MCP is both a software ecosystem (SDKs, tooling, inspector) and a protocol standard. The ladder handles the software project side well—contribution volume, technical execution, operational ownership. But I wonder if we're explicit enough about what protocol stewardship requires as people rise to higher roles.

The ladder mentions "deep understanding of MCP's vision and design principles" for Maintainers and "stewardship of project vision" for Core Maintainers. Good, but somewhat abstract.

Protocol design judgment is different from shipping excellent code. It includes things like:

• Ecosystem-wide reasoning: Does this work for a bank's compliance team AND a hobbyist's weekend project AND a state of the art AI platform AND an embedded system?
• Architectural foresight: Is this abstraction durable, or does it risk painting implementers into corners?
• Restraint: Knowing when not to add something—when a feature belongs in convention rather than specification
• Long-term stability awareness: Every protocol addition is essentially permanent. Deprecation is painful across an entire ecosystem.

It's easy for those of us deep in MCP to forget we're stewarding a standard, not just building a technology. The higher someone rises on the ladder, the more they're shaping the protocol itself—and that carries a different kind of responsibility.

Food for thought: Is there appetite for being more explicit about this dimension at the Maintainer and Core Maintainer levels? Not replacing technical excellence, but complementing it.

This might also help with bandwidth issues, as making sure protocol design and stewardship issues are caught before proposals reach the Core and Lead Maintainers should help reduce the traffic jams at that point. I guess I'm also advocating for cultivating greater awareness of the protocol design principles and vision throughout the organization - in addition to a culture of technical competency and high standards in terms of contributions.

And again, this is not meant as criticism, because I think the ladder is really well written. It is not necessarily about changing the verbiage or anything. I just felt it was relevant to raise this because the MCP org has this duality of both being deeply technical but also being a kind of standards body.

tldr; Industry contributors can lead working groups and drive proposals, but final approval authority remains with people whose professional context is platform development, not production deployment in regulated or legacy-constrained environments. These perspectives should inform protocol direction at the decision-making level, not just through advisory channels.

I totally understand where you are coming from and in principle I agree that it should be the aspirational goal. Yet, we are honestly far away and you are right, current Core Maintainers are all from a very similar organizational background. Yet, I am quite hesitant to add any constraints or goals here. I worry it would be very hard to find what sufficiently diverse. Given that I prefer to keep the Core Maintainer group rather small (and honestly with 9 it already is quite big), I think we will always fail to include a wide variety of the industry. I do agree that we can do better here and should focus in the next iteration of the core maintainer group on this.

Thanks @dsp-ant , I resolved my suggestions. Happy to see this addressed in the next iteration rather than forcing any specific language now.

Question: Is there any understanding yet as to how the role ladder defined here (contributor, member, reviewer, etc) will interact with the new LF/Agent organization policies?

My own observation as a long-time contributor, committer, maintainer, and project lead is that often it's extremely difficult for devs that are not employed by member companies of the organization (rather than based upon contribution, technical expertise/experience, community recognition, or other relevant criteria such as here. I've recently tried, for example, to become an individual/independent member of the new LF org, and it's currently not possible (corps and orgs only).

Another observation: Review of contributions (e.g. 'recognized for technical judgment') and 'decisions' about appropriate role should...if at all possible...be decentralized away from the current maintainers/core maintainers and toward the technical contributing community. First, as things grow, it becomes practically impossible for maintainers (especially the core maintainers) to perform this function as a small group...simply because of bandwidth...as the org/number of consumers/users of mcp grows. As well, I think it's very important for new blood to be introduced at all role levels continuously, as the concerns/needs/use cases of the dev community become clearer over time with deployment, usage, and user community feedback (e.g. new issues, features, contributors, etc).

In previous orgs, I've seen voting/democratic processes work well for representing dev community interests and concerns. Specifically, voting at the project/working group level as a way to review and 'promote' contributors up through levels of responsibility without a hierarchical mgmt structure and with maximum project-level autonomy. Voting has worked IMO even including representation on the Board of Directors.

If interested I can be more specific about these processes and their effects.

I've recently tried, for example, to become an individual/independent member of the new LF org, and it's currently not possible (companys only).

Out of curiosity, is there a stated rule about this, or is it de facto? This sounds like a significant problem.

I've recently tried, for example, to become an individual/independent member of the new LF org, and it's currently not possible (companys only).

Out of curiosity, is there a stated rule about this, or is it de facto? This sounds like a significant problem.

FWIW, I did submit a question to that effect to the new org 'info' email (or whatever it was). Never got a response.

Food for thought: Is there appetite for being more explicit about this dimension at the Maintainer and Core Maintainer levels? Not replacing technical excellence, but complementing it.

@PederHP: Yes. Absolutely! I would love better wording to be more explicit. Do think you could work on a PR towards this?

Thanks @dsp-ant , I resolved my suggestions. Happy to see this addressed in the next iteration rather than forcing any specific language now.

Thank you. I just want to emphasize that I do want a more diverse background in along all axises in the steering of the protocol. This includes diverse company backgrounds, but extends to other attributes as well.

Question: Is there any understanding yet as to how the role ladder defined here (contributor, member, reviewer, etc) will interact with the new LF/Agent organization policies?

The LF organization is for managing the AAIF. MCP is a project within the AAIF that steered on the technical side, independently. While we get funding for events and infrastructure, we define how we work within MCP ourselves. So there should be no interaction for contributors with the LF, unless you happen to be a Silver/Gold/Platinum member of the AAIF.

Another observation: Review of contributions (e.g. 'recognized for technical judgment') and 'decisions' about appropriate role should...if at all possible...be decentralized away from the current maintainers/core maintainers and toward the technical contributing community. First, as things grow, it becomes practically impossible for maintainers (especially the core maintainers) to perform this function as a small group...simply because of bandwidth...as the org/number of consumers/users of mcp grows. As well, I think it's very important for new blood to be introduced at all role levels continuously, as the concerns/needs/use cases of the dev community become clearer over time with deployment, usage, and user community feedback (e.g. new issues, features, contributors, etc).

I think we will slowly democratize via the Working Groups Charters, but I don't think we will for now make big changes to decision making. I understand that it can be frustrating at times, but the current mechanism has served the general protocol quite well and allowed us to move at a very fast pace.

Question: Is there any understanding yet as to how the role ladder defined here (contributor, member, reviewer, etc) will interact with the new LF/Agent organization policies?

The LF organization is for managing the AAIF. MCP is a project within the AAIF that steered on the technical side, independently. While we get funding for events and infrastructure, we define how we work within MCP ourselves. So there should be no interaction for contributors with the LF, unless you happen to be a Silver/Gold/Platinum member of the AAIF.

Where does that leave those of us technically qualified and experienced contributors that are not employed by a Silver/Gold/Platinum members of the AAIF?

We cannot join AAIF/LF, cannot participate in the technical decision making or decision making process, cannot introduce new projects under the mcp or aaif umbrella (afaict), and have zero representation in either the org mgmt (resources allocation choices), nor in the technical or dev+standardization process discussions (maintainers/core maintainers group). I would guess that the existing mcp server and client dev community has a high proportion of such people.

On the face of it, that doesn't seem to invite participation.

I think we will slowly democratize via the Working Groups Charters, but I don't think we will for now make big changes to decision making. I understand that it can be frustrating at times, but the current mechanism has served the general protocol quite well and allowed us to move at a very fast pace.

I agree that the protocol has gotten dev/community adoption and development quickly...kudos to everyone involved in that...particularly maintainers/core maintainers...it is a huge accomplishment.

However, I implore you to consider that building a participating, vibrant, innovative, open, diverse, collaborative dev community around the protocol, sdks, events, projects, money, protocol standardization, etc is core to making things long-lasting.

On the face of it, that doesn't seem to invite participation.

I should have said 'technical/project/dev participation'.

For context, here are the membership benefits of corporate membership for the AAIF.

New commits were pushed — removed the approved label. Re-approve with /lgtm.

This was accepted by MCP Core Maintainers in an asynchronous vote with 8 YES, 0 NO , 1 ABSENT and is accepted.