# Infrastructure Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog
The whole hunk
111 lines, new page
/
lines
A whole new page. There's nothing to diff it against, so here is what it says.
# Infrastructure Charter > Charter for the MCP Infrastructure Working Group. ## Group Type **Working Group** ## Mission Statement The Infrastructure Working Group builds and maintains MCP's shared infrastructure and automation. It makes routine administration self-service for maintainers and contributors. Governance defines who can do what; Infra implements those decisions through standard tools and workflows. ## Scope ### In Scope * **Access and accounts:** Organization invitations, team membership, permissions, and account provisioning. This includes letting authorized leads of MCP working groups invite contributors to the organization and manage access for their own groups, including contributors who cannot yet open pull requests. * **GitHub administration:** Creating and configuring repositories, managing teams and access, and automating common administrative tasks. * **Group setup:** Setting up repositories, permissions, email, meetings, and other resources for approved MCP groups. * **Meetings and communication:** Google Workspace accounts, aliases, mailing lists, calendars, scheduling, agendas, and notifications. Discord integrations and MCP bridges for important project events. * **Shared services:** Improving MCP's [planning](https://plan.modelcontextprotocol.io), [voting](https://voting.modelcontextprotocol.io), and [meeting](https://meet.modelcontextprotocol.io) services with their current owners. * **Hosting and publishing:** Websites, documentation hosting, CI/CD, deployment, package publishing access, domains, DNS, and certificates. * **Supporting resources:** Compute, storage, credentials, and other infrastructure MCP needs now or adopts later. * **Maintenance:** Monitoring, upgrades, recovery, ownership changes, and removal of unused resources. The Infrastructure WG should start with gaps and repeated manual work. Infrastructure that works well should stay in place. Changes to an existing setup or its ownership should be agreed with its owners. The Infrastructure WG should build on existing repositories and tools. Shared workflows should make resources easy to create, manage, and remove. Configuration and changes should be recorded so they can be reviewed and reproduced. ### Out of Scope * Setting governance policy, deciding who holds a role, or changing approval requirements. * Setting voting rules, moderation policy, or communications policy. * Protocol and SDK design, release decisions, website content, and other groups' roadmaps. * Taking over services or requiring migrations without agreement from their owners. * Infrastructure for individuals, companies, or third-party MCP deployments. ### Related Groups * **SDK WG and SDK maintainers:** The Infrastructure WG provides shared tools for repository setup, access, CI, and publishing. SDK maintainers keep responsibility for their SDKs and releases. * **Other WGs and IGs:** The Infrastructure WG provides tools for group setup, membership, communication, and infrastructure. Each group keeps responsibility for its work and services. ## Leadership | Role | Name | Organization | GitHub | Term | | ---- | ----------------------- | ------------ | ---------------------------------------------------------------------- | ------- | | Lead | David Soria Parra (DSP) | Anthropic | [@dsp](https://github.com/dsp), [@dsp-ant](https://github.com/dsp-ant) | Initial | | Lead | Den Delimarsky | Anthropic | [@localden](https://github.com/localden) | Initial | | Lead | Sambhav Kothari | Bloomberg | [@sambhav](https://github.com/sambhav) | Initial | ## Authority & Decision Rights This table covers decisions about the Infrastructure WG's own work. | Decision Type | Authority Level | | ------------------------------------------------------------- | ------------------------------------------------ | | Meeting logistics and scheduling | Infrastructure WG Leads (autonomous) | | Infrastructure WG priorities | Infrastructure WG Leads (autonomous) | | Infrastructure and automation design within scope | Infrastructure WG consensus | | Routine maintenance of Infrastructure WG-owned infrastructure | Infrastructure maintainers, within agreed policy | | Changes to another team's infrastructure | Agreement with the responsible owners | | Infrastructure WG scope expansion | Core Maintainer approval required | | Infrastructure WG Member approval | Infrastructure WG Member sponsors | ## Membership The initial Leads are listed above. The Infrastructure WG will record additional members and their participation levels as they join. Access is managed in [modelcontextprotocol/access](https://github.com/modelcontextprotocol/access). ## Operations The Infrastructure WG tracks tasks in GitHub issues in the relevant repositories. A shared GitHub Project board will track priorities, owners, status, and target dates. The board will be linked here once created. Contributors can take on tasks based on their availability. | Meeting | Frequency | Duration | Purpose | | --------------- | ------------------- | ------------ | -------------------------------------------- | | Working session | As needed initially | To be agreed | Review priorities, designs, and ongoing work | Coordination starts in the Infrastructure Working Group discussion on MCP's Discord. Links to the Infrastructure WG channel and meeting notes will be added once confirmed. Meetings will be published at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io). The [Working and Interest Groups governance rules](/community/working-interest-groups) apply. ## Deliverables & Success Metrics ### Active Work Items The Infrastructure WG's deliverables are working infrastructure, automation repositories, and documentation for using and maintaining them. Initial work should build on [modelcontextprotocol/access](https://github.com/modelcontextprotocol/access) and the existing service repositories. The first priorities come from the founding discussion: access and account provisioning, organization invitations, planning and voting tools, meetings, and Discord notifications and MCP bridges. The initial deliverables are listed below. Tasks, owners, dates, and progress will be tracked on the board. * Let authorized leads of MCP working groups invite contributors to the organization and manage access for their own groups * Improve account, email, and permission provisioning * Improve planning, voting, and meeting services * Automate meeting setup, calendars, agendas, and notifications * Add Discord notifications and MCP bridge support for important events * Automate group setup and routine repository administration * Provide shared workflows for hosting, deployment, DNS, and supporting resources * Document existing infrastructure, its owners, and remaining manual tasks ### Success Criteria * Maintainers and contributors can complete routine administrative tasks through self-service workflows, with approvals defined by project governance. * Routine requests take less time and require fewer manual steps. The Infrastructure WG measures both before and after automation. * The same roles and approval rules are applied consistently across supported systems. * Maintainers use shared workflows for common tasks. The Infrastructure WG tracks adoption and failures. * Resources managed by the Infrastructure WG have a named owner, recorded configuration, and instructions for maintenance, recovery, and removal. * Automation supports access changes, ownership transfers, and cleanup as well as initial setup. Steps that still need manual action are documented. ## Changelog | Date | Change | | ---------- | ----------------------------------------------------------------------------------- | | 2026-09-22 | Initial draft with David Soria Parra, Sambhav Kothari, and Den Delimarsky as Leads. |