Plexara
What you will take away from this lesson
In 207 - Governance: personas, access, and audit, we covered the runtime checks that decide which tools a caller can actually reach. This lesson shifts back to MCP primitives. Tools are the ones people think of first; prompts and resources are the other two that round out what an MCP server can advertise. This lesson is about prompts.
An MCP prompt is a saved recipe. A team that finds itself asking for the same analysis every week can codify it as a prompt and run it as a one-click workflow after that. Plexara ships with a default library and lets administrators and knowledge curators add more, scoped to a user, a persona, or the whole workspace.
Learning Objectives
- 01Explain what an MCP prompt is: a named, reusable instruction the server advertises, with named parameters and a predictable output shape.
- 02Name the default prompts a Plexara deployment ships with (explore, dashboard, report, lineage, capture) and what each one does.
- 03Describe the three scopes a custom prompt can live at (user, persona, organization) and when each is appropriate.
- 04Invoke a prompt two ways: as a one-click button in clients that surface prompts, or by name inside a text message in any client.
- 05Recognize when a recurring workflow is a candidate for a new prompt, and understand how prompts turn ad-hoc habits into governed, shareable assets.
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
- 101What is a Large Language Model?Brilliant at language, blind about your data. Tokens, hallucination, the grounding problem.
- 102Tokens and your budgetSubscription-plan economics, session limits, and Plexara enrichment dedup.
- 103Context, compression, and memoryThe keep / compress / clear playbook and how memory carries across sessions.
- 104Frontier models, specialized models, and why enterprise AI uses bothThree knowledge sources (training, web search, tools). MCP as the exposure protocol.
- 105What is an AI agent?The think/call-tool/observe loop. Professor's knowledge, child's literalism.
- 110Is MCP just an API wrapper?MCP as an application layer. Spectrum from thin wrapper to full application server.
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.
What an MCP prompt actually is
In the Model Context Protocol, a prompt is a named, reusable instruction the server advertises to the client. The server defines the prompt once, along with any parameters it accepts, and the client can invoke it any time. MCP-aware clients surface prompts as one-click buttons or slash commands; clients that do not surface them still let the agent run them by name from inside a text prompt.
A useful mental model: prompts are saved recipes. A well-authored prompt composes several tools into a predictable sequence that produces a predictable output shape. Two different users running the same prompt on two different topics get two correctly shaped answers without either user having to re-describe the workflow.
Anatomy of an MCP prompt
Name
A stable identifier like explore-available-data or create-interactive-dashboard. The agent and the user both refer to prompts by name.
Description
A short human-readable summary of what the prompt does. Clients use this to build picker UI.
Category
Used to group prompts in UI (workflow, toolkit, or custom categories defined by the authoring team).
Arguments
Named parameters the prompt expects. Each argument has a description and a required/optional flag, so the client knows what to ask for at invocation time.
Content
The actual instruction the server hands back to the agent when the prompt is invoked. Usually a structured multi-step checklist the agent follows: search the catalog, then query, then produce the right kind of artifact.
Plexara's default prompt library
Every Plexara deployment ships with a baseline set of workflows reported in the prompts array of the platform_info response. They are intentionally broad: discovery, dashboard building, report generation, lineage tracing, asset management, and knowledge capture. Each is useful on its own and also serves as a reference implementation for teams authoring prompts of their own.
The default prompt library (from the ACME demo)
explore-available-dataarg: topic
Search the catalog for datasets related to a topic, present them with descriptions, ownership, and quality scores, and flag deprecation warnings.
create-interactive-dashboardarg: topic
Discover the relevant datasets, query them, build an interactive visualization, and save it as a shareable asset.
create-a-reportarg: topic
Discover the relevant datasets, analyze them, and produce a structured Markdown report with tables, metrics, and conclusions.
trace-data-lineagearg: dataset
Trace upstream sources and downstream consumers for a dataset, including column-level lineage where available.
save-this-as-an-assetIdentify the key output from the current conversation and save it as a shareable asset with name, description, and tags.
show-my-saved-assetsList the assets you have saved, with names, descriptions, tags, and creation dates.
capture-this-as-knowledgeReview the conversation for corrections, business context, data quality observations, or newly discovered relationships, and capture each as an insight for the knowledge pipeline.
Every Plexara deployment reports its prompt library in the platform_info response. The exact list can be customized per deployment; the defaults above are from the public ACME Corp demo.
Custom prompts: three scopes
Plexara lets administrators and knowledge curators add prompts beyond the defaults through the Portal and the knowledge system. Scope determines who sees which prompts, which means the prompt library each user sees is tailored to them without anybody having to maintain a separate copy.
This is the mechanism teams use to encode their own recurring work. A finance team might have a Quarterly-close narrative prompt. An ops team might have a Top-five incidents this week prompt. A compliance persona might have a Regulatory export prompt that assembles the required datasets in the required format. The workflow stops being tribal knowledge the moment it is authored as a prompt.
Where a custom prompt can live
User-scoped
- Visible to:
- The specific user who authored or was given the prompt.
- Good for:
- Personal shortcuts. A prompt a single analyst wrote for their own recurring review that no other user would find useful.
"My Monday open-tickets triage."
Persona-scoped
- Visible to:
- Everyone acting under a particular persona (for example, every analyst).
- Good for:
- Role-specific workflows. Everyone in the same role should have the same fast path for the same recurring job.
"Finance quarterly-close narrative" visible to every user under the finance persona.
Organization-wide
- Visible to:
- Every session on the deployment, regardless of persona.
- Good for:
- Universal workflows that apply across roles. The default library ships at this scope.
The built-in create-interactive-dashboard and trace-data-lineage prompts.
Custom prompts are added through the Plexara portal or the knowledge system. What a given user sees is the intersection of the three scopes for their session.
Two ways to invoke a prompt
Invocation depends on whether the client surfaces MCP prompts in its UI. Some do; some do not. The practical answer is that either way works, and the user gets to pick.
Two ways to invoke a prompt
In a client that surfaces MCP prompts
The prompt appears as a one-click button or slash-command. Clicking it opens a small form for any required arguments. The client handles the MCP call; the agent receives the prompt content and runs it.
In any client, by name in text
"Run the explore-available-data prompt for the inventory topic" or "Use trace-data-lineage on urn:li:dataset:...". The agent recognizes the prompt name, calls the server to fetch the prompt content, fills in the arguments, and runs the result.
Parameterized prompts keep the template small
Prompts accept named arguments. explore-available-data takes a topic; create-interactive-dashboard takes a topic; trace-data-lineage takes a dataset. A client that surfaces prompts UX-first typically asks the user to fill in those arguments through a form. A text invocation supplies them inline. Either way, the prompt template stays small and the output stays predictable.
Where this leads
Prompts are one of the three MCP primitives. The remaining one, resources, is what the next lesson covers before the 200 series closes with the capstone.
Key terms
Five terms cover the vocabulary of prompts. MCP prompt and argument are the two you will see in tool-call logs; the three scope names are what administrators use when deciding who gets to see what.
Key Terms
- MCP prompt
- A named, reusable instruction an MCP server advertises to its client. The server defines the prompt once; any session can invoke it by name with arguments. Distinct from the text a user types at the agent.
- Argumentparameter
- A named input a prompt accepts. Arguments have descriptions and required/optional flags so the client can prompt the user for them at invocation time.
- Prompt scope
- Who sees a given prompt. User-scoped prompts are visible to one person; persona-scoped prompts are visible to everyone acting under a role; organization-wide prompts are visible to every session on the deployment.
- Prompt library
- The full set of prompts a deployment exposes. Returned in the prompts array of platform_info. The union of the default library shipped with Plexara and any custom prompts the organization has authored.
- Invocation
- The act of running a prompt. Either via a client UI (button or slash command) or inside a text message to the agent ("run the explore-available-data prompt for the inventory topic").