Discovering a Server and Negotiating What It Can Do
A server describes itself once through server/discover, but every request still declares its own capabilities: nothing the server needs is assumed just because a client asked what was available. Read a server/discover request and its DiscoverResult: supportedVersions, capabilities, instructions, serverInfo, ttlMs, cacheScope. Explain why implementing server/discover is mandatory for a server while calling it stays optional for a client. Read the shapes of ServerCapabilities and ClientCapabilities and say what each flag promises. Explain why a server must not rely on a capability the client did not declare on that specific request, and what MissingRequiredClientCapabilityError (-32021) carries. Walk a version-negotiation retry from UnsupportedProtocolVersionError (-32022) through a client picking a mutually supported version. Lesson 06 gave a host one client per server and a clear split of responsibilities, but it left an open question: the first time a client talks to a server it has never seen, how does it learn what that server is and what it can do, without a setup conversation to ask? The stateless core from lesson 04 already ruled out an initialize handshake and a session that remembers the answer. Every request still has to be self-describing. That cuts both ways. A client needs a fast way to learn a server's identity, its supported protocol versions, and the shape of what it offers, ideally in one round…
Discovering a Server and Negotiating What It Can Do: A server describes itself once through server/discover, but every request still declares its own…
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.