CS146S notes: three MCP mistakes fixed, Server never calls APIs

The write-up comes out of reading the CS146S (The Modern Software Developer) lecture notes at Stanford and checking the author's own mental model against an AI. Three specific misconceptions fell away. One was thinking the MCP Server looks at a user request and hunts for the right API on its own; the Server is passive and the LLM makes the pick. Another was reading tools/list as a way to grab every MCP the user has installed; it actually asks one specific Server what tools it holds, while a Host setting decides which Servers are connected. The third was assuming a Tool Call can fire before the user even asks a question; only the LLM emits a Tool Call, and before the question the Client is just pulling the tool list to prep the prompt.

The body also lays out the three roles a reader keeps tripping over. A Host is the app a user touches, like Cursor or Claude Desktop; inside it sits a Client, a communication library; and in front of each tool sits a thin MCP Server wrapper. In a summarized-mail example, the Client asks the Server what tools exist, passes the question and tool descriptions to the LLM, gets back a structured Tool Call like search_emails(from="Jack"), runs it through the Server to Gmail, then hands the result back for the LLM to phrase. The LLM is the brain, the Client is the hands.

The piece closes with design guidance: build tools around results, not raw operations (send_payment(user_email) over three chained calls), and split search from execute so only a thin index sits in the prompt. It also frames Skills as the how-to layer on top of MCP. How much of this holds in real deployments may depend on how closely tooling follows the CS146S framing, and on whether MCP Servers stay passive as the ecosystem grows.