Two groups in the MCP project disagree about a design decision on which the Core Maintainers have already voted. Which role in MCP technical governance holds final decision authority and can veto that decision?
Select an answer to reveal the explanation.
Short Explanation
Think of it as a ladder you climb: contributors propose, Maintainers run their areas, Core Maintainers steer the whole project, and Lead Maintainers have the last word. That top rung is the BDFL role, and it can veto anyone below it. Don't confuse owning an area with owning the final call.
Full Explanation
MCP technical governance is hierarchical, similar to Python and PyTorch. Contributors file issues, make pull requests and join discussions. Maintainers steward specific areas such as SDKs, documentation and Working Groups, decide independently within them, and escalate when needed. Core Maintainers steer the specification and overall direction, can veto Maintainer decisions by majority vote, and appoint or remove Maintainers. Lead Maintainers hold final authority, can veto any decision by Core Maintainers or Maintainers, appoint and remove Core Maintainers, and are expected to explain their reasoning publicly; this is the role commonly called Benevolent Dictator for Life. Working Group facilitation is a Maintainer-level responsibility for a working area, and Working Groups produce SEPs but do not hold final authority over them. SDK Maintainers own their SDKs and can be overruled by Core Maintainers. Contributors have no voting power over specification decisions, and governance is not settled by majority votes on pull requests. Exam caveat: Maintainers, Core Maintainers and Lead Maintainers together form the MCP Steering Group, and membership belongs to individuals rather than companies. Operational check: when escalating a dispute, record it in the project's public channels and identify which governance level owns the decision before asking for a vote.