201 - Anatomy of a Plexara MCP

The 100 series closed with the argument that MCP is an application layer, not a thin wrapper over APIs. This lesson opens the application. What is actually inside a Plexara MCP server when you connect your client to one? Which parts are standard MCP and which parts are Plexara-specific? And where does the rest of the 200 series take each piece?

This is a map lesson, not a deep dive. Every subsystem introduced here has its own dedicated lesson later. If anything in the map looks interesting, follow the link in its row and come back.

The 100 series built the foundation that every lesson in this series assumes. Each title below is a direct link back; the index card links to the 100-series landing page.

The 200 series narrows focus to one specific MCP server. It is not a survey of MCP implementations in general. It is a guided tour of what Plexara advertises to an agent, organized the way a power user should think about the surface.

A Plexara MCP server advertises seven distinct kinds of things to a connected client. Three of them are base MCP primitives every compliant server has. Four of them are Plexara-specific subsystems built on top. You do not need to memorize this table; the map below exists so that when a later lesson refers to "memory" or "the knowledge pipeline" or "the semantic enrichment layer," you already know where it fits.

The distinction between the top three rows and the bottom four is load-bearing. The 110 lesson drew a spectrum from thin-wrapper MCP servers to full application servers. The difference, concretely, is everything below the line in the map above. A thin wrapper exposes tools, resources, and prompts. An application server uses those primitives to build subsystems that do useful, coordinated work: enriching returned data with catalog context, recalling memories from prior sessions, promoting observations into organization-wide documentation, and enforcing governance at the point a tool is invoked.

A single question, "How are ACME Corp sales doing in the Southwest region?", touches almost every row of the map. The agent consults the tool list (tools). The server gates everything behind platform_info and returns the operating manual along with the prompt library (resources and prompts). The agent calls datahub_search, and the response comes back with semantic enrichment attached automatically (tools + enrichment). Governance has already filtered out any tools or connections this persona is not allowed to use (governance). The agent looks in memory to see whether the user had a preferred definition of "sales" in earlier sessions (memory). It calls trino_query; the returned table metadata is enriched but deduplicated against what was sent earlier in the session (enrichment). The answer is formed and, if a user correction surfaces, routed toward the admin review pipeline for possible promotion to organization-wide documentation (knowledge).

The user experiences this as a single fluid answer. The map is what that fluid answer decomposes into when you look at it carefully.

Before any of the subsystems engage, the session passes through a single gate. Until platform_info has been called, every other tool refuses with a structured error. This is a deliberate design choice and it is the subject of the next lesson.

The rest of the 200 series walks through the subsystems one at a time, starting with the gate.

Six terms cover the vocabulary you will need as the rest of the 200 series unfolds. "Primitive" vs "subsystem" is the distinction worth keeping sharp because it maps directly to the division in the anatomy map above.