Exercise 1: A New Component Missing From the Agent Side Only — Possible Solution
====================================================================

The most likely cause is that mcp/server.ts wasn't restarted after the
catalog and registry were updated - or, less commonly, that the MCP
server is importing its own separate reference to the catalog rather
than the exact same shared object the browser path uses. This
chapter's own real point is that the MCP server and the browser-facing
API route are meant to draw from the identical catalog - if the new
component shows up in the browser but not for an agent, something has
broken that shared-source relationship rather than the new component
itself being genuinely invalid.

Since the MCP server holds its own running process, separate from the
Next.js dev server, a change to catalog.ts doesn't automatically
propagate into an MCP server instance that was already running before
the edit - the process needs to be restarted (or, if actually
importing a stale or duplicated copy of the catalog rather than the
real shared one, that duplication needs fixing directly) so it picks
up the current, real catalog contents.

ANSWER: The most likely cause is that the running MCP server process
hasn't picked up the catalog change - either it needs restarting after
the edit, or (less commonly) it's importing a separate, stale copy of
the catalog rather than the same shared object the browser path uses.
This chapter's own point is that both paths are meant to draw from one
identical catalog, so a mismatch here means that shared-source
relationship has broken somewhere.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly diagnoses the most likely real cause (a stale running
process or a broken shared-source assumption) based on the chapter's
own explicit "same catalog" claim, rather than assuming the new
component itself is the problem.