Finding, Routing To, and Trusting a Server
A name in the registry is a claim about who published a server, not a guarantee about what it does. A gateway decides whether a request may reach that server at all. An SDK's tier says how much of the protocol its implementation actually speaks. Three separate questions, three separate answers. Explain what the MCP Registry stores and what it deliberately does not store, why it only accepts publicly accessible servers, and why it is currently a preview surface. Verify a server's reverse DNS namespace the way the registry does, through GitHub or domain based authentication, and separate that from the ownership proof a package registry checks. Read a server.json entry's packages and remotes, and explain why its schema version is independent of the protocol version the server actually speaks at runtime. Explain what a stateless gateway is responsible for: validating Mcp-Method and Mcp-Name against the request body, routing on that header pair, and respecting cacheScope instead of inventing its own cache authority. Use an SDK's conformance tier as a portability and trust signal, and explain how a tier is earned and how it can be lost. A team decides to add a third party MCP server to an internal assistant. Three separate questions show up immediately, and they do not share an answer. Where does the team find a…
Finding, Routing To, and Trusting a Server: A name in the registry is a claim about who published a server, not a guarantee about what it does. A gateway…
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.