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 eight distinct kinds of things to a connected client. Three of them are base MCP primitives every compliant server has. Five 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 five is the one that matters. 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, rendering an interface where one helps, and enforcing governance at the point a tool is invoked.

Tools are the primitive everything else is reached through, so the inventory is worth seeing whole once. Around forty tools ship across eight toolkits, and the grouping is not cosmetic: platform_info reports which toolkits a deployment has turned on, and a persona grants or withholds tools within them.

The order below is the order that matters rather than the order the toolkits were built in. Discovery comes first. A session that starts anywhere else is guessing at what exists, and searching the capability rather than the manual is the habit the whole surface is arranged around.

Of everything in that inventory, two names deserve to be learned first. A single search call fans across every source the caller can reach: the catalog, the business glossary, knowledge pages, uploaded resources, your own memory, captured insights, feedback, saved assets, the prompt library, API endpoints, and the configured connections. Results come back grouped by source with a coverage summary rather than flattened into one list, so a forty-thousand-dataset catalog cannot bury the single knowledge page that answers the question.

fetch is its other half. A search hit is a pointer carrying a title, a snippet, and a reference; fetch takes that reference and returns the complete record behind it, under exactly the scope search applied. Between them they replaced the per-backend search tools and per-source readers that used to exist, which is why an agent no longer has to decide where an answer lives before it starts looking. 203 covers the pair in full.

One more tool is worth knowing by name early: platform_find_tools ranks the tool list itself against a plain-language description of a task. It is discovery pointed at the toolbox rather than at the data, and it is how an agent locates a capability without reading three dozen tool descriptions to find it.

The map above lists resources, memory, and knowledge as separate rows, and assets show up in the Portal toolkit. Seen individually they look like four storage systems that happen to hold different file types. They are not. The difference between them is authorship, and the file format is close to irrelevant: the same PDF can legitimately be a resource or an asset depending on who made it and why.

The question a person should ask when filing something, and the question the agent asks when reaching for something, is the same one. Did this exist before the conversation? Then it is a resource, and the agent should reproduce it rather than rewrite it. Did the agent make it in a session somebody wants to keep? Asset. Is it a fact you want found, cited, and synthesized into new answers? Knowledge page. Is it about how one particular person works? Memory.

The distinction sticks better once you have seen it fail. Every misfiling has the same shape: the agent reads the layer as a statement about where the content came from, and acts accordingly.

Everything described so far arrives as structured data the agent reads and summarizes for you. That is the right shape for most answers, and a bad shape for a few. A prompt library is easier to browse than to read aloud. A deployment summary is easier to scan as a panel than as a paragraph. MCP Apps are the answer to that narrow but real problem: a tool result can carry a reference to an interface, and a client that knows how renders it beside the answer.

The mechanism is small enough to hold in your head, which is worth doing because it explains the security posture as well as the behavior.

Nothing needs to be installed or turned on for either of these. Platform Info and List Prompts are part of what Plexara serves, and the first one shows up on the very first tool call of every session.

Below is the actual app, loaded against the ACME Corp demo deployment and rendered here the same way a client renders it. This is what platform_info looks like when the client can draw it: the connected toolkits, the feature flags, the personas, and the operating manual, all in one panel instead of a wall of JSON. 202 walks through the same content as the agent reads it.

The obvious worry about a UI layer is that it becomes required: capability drifts into the app, and clients that cannot render it fall behind. Plexara forecloses that by construction.

A single question, "How are ACME Corp sales doing in the Southwest region?", touches almost every row of the map. The agent calls platform_info, which gates the session and returns the operating manual along with the prompt library (tools, resources, and prompts). It calls search once, and the response comes back grouped by source with semantic enrichment attached automatically (tools + enrichment), including a memory from an earlier session where the user pinned down what they mean by "sales" (memory). Governance has already filtered out any tools or connections this persona is not allowed to use, so nothing in that response is something the user could not have seen (governance). The agent reads the most promising hit in full with fetch, then calls trino_query; the returned table metadata is enriched but deduplicated against what was sent earlier in the session (enrichment). The chart it builds is persisted with save_asset rather than pasted into the chat (assets). If a user correction surfaces along the way, memory_capture routes it 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.

Eight 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.