MCP Separates Capability From Host
Build a narrow, stateless MCP server whose contract can be discovered, cached, invoked, and scaled without hidden connection state. Explain the separate responsibilities of MCP host, client, and server. Build the MCP 2026-07-28 per-request metadata envelope. Implement mandatory server/discover, complete results, and cache hints. Use Multi Round-Trip Requests for roots, sampling, and elicitation compatibility; explain why roots, sampling, and logging are deprecated for new designs. Deploy current Streamable HTTP without protocol sessions or sticky routing. Apply authorization, consent, integrity, and untrusted-output controls. Your team has three data systems and four AI hosts. Each host receives a custom connector for each system. Authentication, schemas, retries, logging, and tool descriptions drift across twelve integrations. Then the database changes one field. Half the connectors update. One silently keeps returning the old field. The model is blamed for inconsistent answers even though the integration layer is inconsistent. Model Context Protocol replaces many bespoke host-to-capability adapters with a shared protocol. A server advertises tools, resources, and prompts. A client discovers that contract and invokes it. A host connects those capabilities to a model and user experience. MCP does not remove integration engineering. It gives that engineering one visible boundary. These terms are exam-critical because collapsing them hides ownership. Host: the user-facing AI application. It owns model interaction, consent, policy, and one or more clients. Client:…
MCP Separates Capability From Host: Build a narrow, stateless MCP server whose contract can be discovered, cached, invoked, and scaled without hidden…
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.