Plexara end-to-end: a worked example

What you will take away from this lesson

In 209 - Resources: the company files the agent should use, not reinvent, we closed out the three MCP primitives. Every subsystem in a Plexara MCP has now had its own lesson. This final 200-series lesson is the capstone: a single realistic question walked end to end, with a callout for every subsystem that fires along the way, plus an appendix of every tool a Plexara MCP exposes for when you need it.

Nothing here is new. The point is to see the pieces working together in one session rather than one at a time. If a step surprises you, the lesson that introduced that piece is linked right on the step.

Learning Objectives

01Follow one real Plexara session end to end, turn by turn, naming which subsystem fires at each turn.
02See discovery as the platform actually enforces it: one search across every source, fetch to read a result in full, and a warehouse query that is refused outright until discovery has happened.
03Watch a result become a durable object: saved with save_asset, corrected in place with an anchored manage_asset patch rather than a regeneration, and recorded with memory_capture for the Memory to Insight to Knowledge path.
04Pick from three styles of prompting (high-level, prompt-by-name, tool-by-name) and know when each is appropriate.
05Use the tool directory at the end as the reference it is: every tool the Plexara MCP exposes, grouped by toolkit, with badges that flag writes, admin-only operations, and the mandatory first call.
06Find any subsystem again from the series index: the eleven other 200-series lessons, plus the apps surface a tool result can carry.

Where we are in the curriculum

If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.

100 Series: the foundation

Open index

If a term in this lesson looks unfamiliar, back up to the 100 series. The 200 series assumes that mental model. Every row above is a direct link.

A single realistic question

Every lesson in the 200 series has described one subsystem. That is a sensible way to teach, but it is not how the subsystems show up in a real session. This capstone picks one ordinary analyst question and watches the subsystems work together turn by turn.

Turn by turn: what happens inside Plexara

The ten steps below walk through what happens between the moment the user hits enter and the moment a dashboard link comes back. Governance, platform_info, one search across every source, fetch, the search-before-query gate, a curated query template, enrichment on a byte budget, an asset and its anchored correction, and the memory that outlives the session are all present in this trace.

This is a transcript, not a diagram. Every step below was run against a live Plexara deployment, in the order shown, and the details are what came back: the sources search reached, the knowledge page that changed the answer, the runtimes, the version number the patch produced. Where reality differed from the tidy version, reality is what is written down.

What happens, turn by turn, inside Plexara

Step 01
User sends the first question
Governance scopes the session
Governance: 207
The question names ACME Corp, the entity cue that tells the agent this particular MCP is the right place to look. Without it, the agent might answer about retail sales at large. The persona attached to this user decides which tools exist for the rest of the session.
Step 02
Agent calls platform_info first
platform_info session gate
First day: 202
Every other tool is refused until platform_info has been invoked, so the agent calls it first. Back comes the ACME operating manual (the data estate, the query rules, the prompt library) and a session handle the agent then carries on every subsequent call. A call without the handle is refused.
Step 03
One search, every source the persona can reach
Discovery across every source
Discovery: 203
A single search call comes back with hits from nine sources at once: the catalog, the governance glossary, knowledge pages, this user’s memory, captured insights, saved assets, uploaded resources, prompts, and API endpoints. Results are grouped by source with a coverage summary saying how many each source matched against how many are shown, so nothing gets crowded out by a source that happened to rank well.
Step 04
fetch reads one result in full, and it changes the answer
fetch, and knowledge paying off
Discovery: 203
Among the hits is a knowledge page called ACME Fiscal Calendar. The agent passes its reference to fetch and reads the whole page: ACME’s fiscal year starts February 1, so fiscal Q3 is August through October, not July through September. The question the user asked has a different answer than it appeared to. Nobody had to tell the agent this; it was recorded once and found by search.
Step 05
The query would have been refused without step 03
Search-before-query gate
Governance: 207
Discovery before query is enforcement, not advice. Had the agent gone straight to trino_query, the tool handler would never have run: the platform short-circuits with a SEARCH_REQUIRED result telling it to search first. That is why the agent searched, and why an ungrounded guess at the data’s shape is not a path the agent can take.
Step 06
The curated query template, not a query from scratch
Curated query templates
Trino and curated queries: 204
datahub_get_queries on the matched dataset returns six benchmarked templates, one of which is a region-by-month revenue cross-tab with its measured runtime recorded on it. The agent adapts that template to the fiscal window rather than authoring an aggregation of its own.
Step 07
The query runs; business context rides along
Cross-enrichment on a budget
Token economics: 102
The aggregation returns both fiscal quarters, by region, in well under a second. Attached to the result is the catalog’s context for the tables it touched: description, domain, and the glossary definition of Sales Region. That context runs on a byte budget with a summary-first layout, so it stays a compact header on the answer instead of pushing the data out of the window.
Step 08
The dashboard is saved, not pasted
Assets, with provenance
Assets: 205
The user asked for a dashboard. The agent calls save_asset with the HTML directly rather than printing it into the chat and saving it afterwards, which would mean generating it twice. The portal returns a link and records provenance: the exact tool calls that produced this asset, attached to it.
Step 09
A small correction, patched in place
Anchored edits, versioned
Assets: 205
Reading it back, the analyst wants the biggest percentage mover named alongside the biggest dollar mover. That is a manage_asset patch: one anchored edit on the sentence in question, which lands as version 2 with a one-line diff. The rest of the dashboard is untouched and never re-sent. An anchor that matches nothing, or matches twice, refuses the whole call rather than guessing.
Step 10
What the session learned, kept
Memory to Insight to Knowledge
Knowledge: 206
Along the way the agent found that a date filter on this index needs a full timestamp, not a bare date, and proved it by running both. memory_capture records that against the dataset. Because it is a fact about a dataset rather than a personal preference, it enters review as an insight instead of going live, and the response names the near-duplicate already on file so the reviewer consolidates rather than stacking a second copy. Memory becomes an Insight, and an Insight that survives review becomes Knowledge every future session can find.

The user sees the answer, the dashboard link, and a short conversation. Every step above happened in support of that one exchange, and this trace is the sequence a real session produced rather than an idealized one.

Three styles of prompting

The trace above used a high-level prompt: the user described the goal and the agent worked out the steps. That is the right default for most work. Two other styles are worth knowing about: invoking a named prompt from the library, and naming specific tools directly. Each has a place.

Three styles of prompting, and when to use each

01
High-level: describe the goal
When: Most of the time. The agent picks the right tools, respects the operating manual, and produces a grounded answer.
"For ACME Corp, what were Q3 2025 sales by region, and which region saw the biggest change from Q2? Save the analysis as a dashboard."
02
Mid-level: name a prompt
When: When a repeatable workflow already exists in the prompt library. Shorter to type; the output shape is predictable.
"Run create-interactive-dashboard for Q3 sales by region." Takes topic and applies the template consistently.
03
Low-level: name specific tools
When: When you already know exactly what you want. Forces a specific path that the agent would otherwise have to reason its way to.
"Call datahub_get_queries for the os_acme_transactions URN, run the region-by-month cross-tab template for fiscal Q3, and write the rows straight to a CSV asset with trino_export."

There is no “best” style. The right level is the one that matches what you already know. A new user benefits from high-level prompting and lets the agent figure it out; a power user reaches for tool-by-name only when they want to short-circuit.

Closing the loop

That is the curriculum. Ten lessons in the 100 series, ten in the 200 series, and one worked example that tied them together. The subsystems are not exotic individually; the compounding value comes from having all of them running at the same time, under governance, with memory and knowledge closing the loop each session.

Where to go from here

That is the trace end to end. If any step in it surprised you, follow the lesson link on that step and revisit the subsystem in depth. Two of them are worth reading next on their own account. The trace turned on a catalog that already said what things mean, and 211 - Governing the catalog without leaving the portal covers who keeps it that way and where. It also turned on a knowledge page nobody in the session had written, and 212 - Seeing the shape of what your team knows shows that body of knowledge drawn as the network it is, so you can see which parts of it hold the rest together and which citations do not resolve. If you want the broader editorial arguments (why Plexara exists, how it fits into the larger enterprise-AI conversation), the Insights collection is the companion to this curriculum. And when you come back to a real session with a real question, start with the high-level prompt and work down to more explicit styles only when you need to.

The portal Assets page: Assets and Collections tabs, Mine, Shared, and All filters, a search box, a type filter, a tag filter, and a grid of asset cards each with a rendered preview, a title, a description, a content type badge such as text/html, image/svg+xml, or text/markdown, tags, a size, and a date, one carrying a feedback count. — Where the worked example ends up. The dashboard, the pipeline chart, and the inventory report from sessions like the one above sit here as assets, each previewed, typed, and tagged, findable by anyone they were shared with. The session closes; the work does not disappear with it.

The portal Feedback page: Recent, Worklist, and General tabs, a New feedback button, and a list of feedback threads each naming the asset, collection, or knowledge page it is about, a title, a type badge such as Correction, Question, or Suggestion, a status badge such as Open, Answered, or Resolved, who raised it, and a reply count. — Feedback is how the loop closes on the human side. A correction on a dashboard, a question about where a column comes from, a suggestion for a collection: each one is a thread attached to the thing it is about, with a status, and the corrections are the raw material the next capture turns into memory and, once reviewed, into knowledge.

The 200 series, in one place

This lesson is also the index. Each row below is the subsystem lesson behind one part of the trace, and the two at the end cover ground the trace only leaned on: who curates the catalog the search reads from, and what the accumulated body of knowledge looks like once you can see its shape.

One surface the trace did not show is the interactive one. A tool result can carry a reference to a small interface, and a client that knows how renders it beside the answer instead of narrating it: the prompt library as something you browse rather than something read aloud, the deployment summary as a panel rather than a paragraph. Plexara ships two of these, and 201 covers what they are and why they stay presentation-only.

200 Series: the platform, subsystem by subsystem

Open index

210 is the lesson you are reading. Every other row is a subsystem the trace above touched, covered in depth.

Appendix: the tool directory

The rest of this lesson is reference material. Plexara groups its tools into eight toolkits. Every tool name below is the exact identifier the agent would invoke. Most tools are read-oriented and side-effect-free; writes and administrator-only operations are flagged.

You do not need to memorize this directory. The point of the trace above was that the agent chooses tools on your behalf. Scan this section when you want to know what is possible, or when you need to name a specific tool in a prompt.

Toolkits: 8
Tools: 42
Write-capable: 17
Mandatory first call: 1

Platform

The session gate, the connection list, and the tools about the toolbox itself. platform_info is mandatory as the first call in every session and is backed by a runtime session gate (202); platform_find_tools ranks the tool list by intent so the agent can locate a capability without reading every description.

platform_infoMandatory first callSession-gated
Returns the deployment description, tags, toolkits, feature flags, persona, portal URL, prompts library, and the agent_instructions operating manual. Issues the session handle every subsequent call carries.
Runtime-enforced by a session gate that refuses every other tool in the deployment until platform_info has been invoked in the current session.
list_connections
Lists the configured data connections across every toolkit (Trino catalogs, DataHub endpoints, S3 buckets, API gateways) with their name, kind, and type.
Each connection arrives with a bounded sample of the canonical knowledge pages documenting it, so the agent learns what a backend is for and not only that it exists.
platform_find_tools
Ranks the platform’s own tool list against a plain-language description of a task, so the agent can find the right tool by intent instead of reading three dozen tool descriptions.
Persona-scoped at read time: it never returns a tool the caller could not call. Ranks on meaning rather than keyword overlap, so "find out where this number came from" reaches the lineage tool without naming it.
manage_promptWrites
Resolve and run a prompt by any handle (name, display name, reference, or free text) with the use command, plus create, update, delete, list, and get.
Carries the content verbs (patch, locate, get_content, outline, stats, diff), so editing a long prompt is an anchored patch rather than a full rewrite. Editing an approved shared prompt saves a pending draft while the approved version keeps being served.
show_promptsPresentation only
Asks the client to render the prompt library as an interactive browser for the human. It performs no data operation and returns only a short confirmation.
The MCP App bound to it populates itself from its own manage_prompt calls. Separating the two is what keeps the agent’s routine prompt work from opening a window nobody asked for (201).

DataHub

Schema, lineage, glossary, and curated query retrieval. Discovery itself is not here: it belongs to the universal search tool in the Knowledge toolkit, and searching the capability rather than the manual is what these structural reads follow (203). The write tools at the end are used inside the knowledge-apply flow (206) rather than directly by end users.

datahub_browse
Lists catalog contents by category (tags, domains, data products). Useful for orientation rather than targeted lookups.
datahub_get_entity
Fetches a DataHub entity by URN. Returns the full metadata record, including custom properties.
datahub_get_schema
Returns the column schema for a dataset entity. Use when the agent needs column types and descriptions before writing a query.
datahub_get_lineage
Upstream and downstream lineage for a dataset. Used to understand where data comes from and what depends on it.
datahub_get_glossary_term
Business glossary lookup. The agent uses this to disambiguate terms like "revenue," "active customer," or "net amount" against the organization's canonical definitions.
datahub_get_queries
Retrieves curated, pre-benchmarked query templates for a dataset. The fast path the operating manual tells the agent to prefer over free-form queries.
datahub_get_data_product
Returns data-product metadata (a named grouping of related datasets).
datahub_createWriteAdmin
Writes a new catalog entity. Not typically invoked directly by end users; used inside the apply_knowledge flow.
datahub_updateWriteAdmin
Updates an existing catalog entity (description, tags, glossary terms, etc.). Called by apply_knowledge when applying approved insights.
datahub_deleteWriteAdmin
Removes a catalog entity. Restricted to administrator sessions.

Trino

SQL execution, structural navigation, plan inspection, and large-result export across every Trino catalog the deployment reaches (204). Read-only enforcement is applied at the platform layer, not left to the query author (207). A query here is also refused outright until discovery has run in the session, which is the gate step 05 of the trace describes.

trino_queryRead-only enforced
Executes read-only SQL against any configured Trino catalog. Write statements are refused at the platform layer.
trino_executeWriteClient-prompted
Executes any SQL, including inserts, updates, deletes, and DDL. The write path is a separate tool from the read path on purpose.
Annotated as destructive so clients prompt before running it, where trino_query is annotated read-only and can be auto-approved. A connection pinned read-only refuses writes here too.
trino_browse
Lists catalogs, schemas, and tables. Used for structural navigation once search has pointed at a backend.
trino_describe_table
Returns the column schema for a Trino table, with an option to include sample rows.
trino_explain
Returns the Trino execution plan for a query. Used when the agent needs to reason about why a query is slow or how it will be executed.
trino_exportWrites asset
Runs a query and writes the result to a persisted asset (CSV, JSON, or Markdown) instead of returning rows in the conversation.
Use when the result set is large enough that putting it in the context window would be wasteful.

S3

Object storage access under prefix ACLs and size caps. Every tool here is restricted to the paths the persona is allowed to reach, and the restriction is applied when the call is made rather than described in a policy (207).

s3_list_buckets
Enumerates buckets configured on the deployment, within the configured prefix ACLs.
s3_list_objectsPrefix-restricted
Lists objects inside a bucket. The platform layer enforces the prefix restriction; the agent cannot browse outside allowed paths.
s3_get_objectSize-capped
Reads object content. Subject to the configured maximum file-size limit.
s3_get_object_metadata
Reads object metadata (size, last modified, content type) without downloading the content.
s3_presign_url
Returns a time-limited signed URL for a specific object. Useful when a dashboard or report needs to link to raw data.
s3_put_objectWrite
Uploads an object, taking text directly or base64 for binary content. Blocked when the connection is pinned read-only.
s3_delete_objectWrite
Removes an object. Irreversible unless the bucket has versioning enabled, and blocked when the connection is pinned read-only.
s3_copy_objectWrite
Copies an object within a bucket or between buckets, optionally rewriting its metadata on the way. Blocked when the connection is pinned read-only.

Memory

Per-user memory organized along five dimensions. Recording is one action, memory_capture; memory_manage covers the lifecycle afterwards. Reading memory back is not a memory tool at all: the universal search tool reaches memory alongside every other source it covers, so prior-session context arrives in the same result set as the catalog and the knowledge pages (206).

memory_captureWrites
The one way to record knowledge. Checks existing memory for that user before it writes, so a restatement supersedes the record it corrects instead of stacking a near-duplicate beside it.
Memories are organized along five dimensions: Knowledge, Events, Entities, Relationships, Preferences.
memory_manageWrites
The lifecycle of a memory that already exists. Supported commands: update, forget, list, review_stale, review_duplicates, consolidate.
Reading memory back is not here. It moved into the universal search tool, which reaches memory alongside the catalog, knowledge pages, insights, assets, and prompts in a single query.

Knowledge

Discovery and admin-reviewed catalog write-back. search and fetch are open to every user and are the front door to the whole platform; the apply path is administrator-only (203, 206, 207).

searchFirst call for any question
The one way to discover. A single query fans across the catalog, the governance vocabulary, context documents, knowledge pages, the caller’s memory, insights, feedback, assets, resources, prompts, API endpoints, and connections.
Results arrive grouped by source with a per-source coverage summary rather than as one flat list, so no single source crowds out the others. 203 covers the response shape in full.
fetch
Reads one search result in full. Takes any reference a hit carries and returns the complete record behind it, under exactly the scope search applied.
Registered alongside search. A persona granted one without the other can find records it cannot open.
apply_knowledgeWrites catalogAdmin
The review-and-apply gate. Enumerates pending captures, supports bulk or per-entity review, synthesizes related ones into cohesive changes, and writes approved changes back as a tracked, reversible changeset.
Knowledge lands in one of two homes: a DataHub entity when the fact is tied to a dataset or column, or a canonical knowledge page when it is broader business context. Recording is not here; that is memory_capture, described in 206.

Portal (assets and feedback)

Asset persistence, collection management, and the feedback threads people leave on both (205). Dashboards, reports, charts, and exports live here as first-class, shareable objects rather than as transient chat output.

save_assetWrites asset
Persists generated content (HTML, JSX, SVG, Markdown, JSON, CSV) as a named, shareable asset in the portal.
Use this path whenever the agent would otherwise return a large block of content into the conversation.
manage_assetWrites
List, get, update, delete, or revert existing assets. Edits go through update rather than regenerating from scratch, which preserves provenance.
Collection management lives here too: the agent can group assets (dashboards, reports, markdown, CSVs) into sections within a named collection, and collections are shareable as a single unit.
manage_feedbackWrites
Reviews and answers the comments people leave on the agent’s work. Threads hang off an asset, a collection, or a prompt, or off a shared general channel.
A list with no target is the "what is waiting on me" query: unresolved threads on everything the caller owns or can edit, plus anything awaiting their validation. Feedback is its own tool rather than an action on manage_asset so an agent finds the loop by name.

API

Registered HTTP APIs, reached the same governed way as the warehouses. The deployment holds the credentials and applies them, so the agent addresses an operation by name and never handles a secret.

api_list_specs
Lists the sections of a registered API connection’s catalog, each with its title, description, operation count, and base path. The first call against an API that bundles more than one specification.
api_list_endpoints
Lists the operations an API connection exposes, ranked against an optional plain-language query rather than dumped alphabetically.
Persona policy still applies at invoke time, so a listed operation can still be refused when it is called.
api_get_endpoint_schema
Returns the parameters, request body, and per-status response shapes for one operation, so the agent can form a correct call in one attempt.
api_invoke_endpointWrite-capable
Makes the authenticated request. The connection’s credentials are applied by the platform, so the agent addresses an operation by name and never sees a secret.
Response bodies above the connection’s configured ceiling are truncated and flagged rather than silently cut.
api_exportWrites asset
Runs an operation and writes the response to a persisted asset instead of returning it into the conversation. The same escape hatch trino_export provides for query results.

Key terms

Three terms unique to this lesson. Most of the vocabulary across the curriculum has been covered in earlier key-terms sections; this is the short list of what the capstone adds.

Key Terms

Capstone: An end-to-end walkthrough lesson. This one threads a single realistic question through every Plexara subsystem the 200 series covered, so the pieces are visible working together in context rather than in isolation.
Prompting style: The level of specificity in a prompt. High-level prompts describe the goal; prompt-by-name prompts invoke a library prompt by identifier; tool-by-name prompts force a specific tool path. Each is right in different situations.
Tool directory: The appendix at the end of this lesson: every tool a Plexara MCP exposes, grouped by toolkit, with badges that flag writes, admin-only operations, session-gated calls, and the single mandatory first call.
Search-before-query gate: The rule that a warehouse query is refused until discovery has happened in the session. It is enforced in front of the tool handler, so a query that skips discovery never runs at all; the agent gets a SEARCH_REQUIRED result telling it to search first.

210 - Putting it all together: a worked end-to-end example