Every MUST Needs an Owner
The specification hands its MUSTs to a host, a client, and a server. A live deployment hands them to people, and the MUST nobody agreed to own is the one that fails first. Assign the six roles behind a real MCP deployment, server author, host and client developer, platform or gateway operator, security and governance owner, registry publisher, and end user, the spec requirements each one actually owns. Trace how the owner of the same requirement can shift across three adoption paths: local stdio, remote Streamable HTTP with OAuth, and a gateway-fronted enterprise deployment. Explain the MCP governance structure: stewardship under the Agentic AI Foundation, the Lead Maintainer, Core Maintainer, and Maintainer hierarchy, and the difference between a Working Group and an Interest Group. Follow a proposal from an idea through the SEP workflow to a Final status, and connect that workflow to the feature lifecycle a requirement moves through once it ships. Treat SDK tier selection as an adoption decision a role makes, not a checkbox, by reading the tiering system's conformance and response-time commitments. Read the specification end to end and it describes three participants: a host, a client, and a server. Read a real MCP rollout end to end and it involves at least six kinds of people, and none of them is named "host" on an…
Every MUST Needs an Owner: The specification hands its MUSTs to a host, a client, and a server. A live deployment hands them to people, and the MUST nobody…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.