Plexara
Portal Tour · Administration
See Exactly What Your Agents Can Reach
One Page That Answers Whether Anything Is Wrong
Dashboard is the administrative landing view and it carries six tabs: MCP, API Gateway, Health, Indexing, Events, and Notifications. The first of them opens on tool-call activity across a window you choose, from the last hour out to seven days. What fills the last of them, and where an admin points outbound mail, is covered on Email Notifications.
Volume, Success, and the Rhythm of a Working Week
Why it matters
Adoption questions and incident questions look identical from the outside. Both start with how much is being asked, by whom, and whether it is succeeding.
How it works
Summary cards report total calls, success rate, average duration, unique users, unique tools, enrichment rate, and errors, each with its trend against the prior window. An activity timeline charts call volume with errors overlaid, and a usage-rhythm heatmap lays the last seven days out by weekday and hour, which is where a nightly job or an abandoned Friday afternoon becomes obvious. Below that sit top tools and top users, response-time percentiles, a clickable recent-errors list, the knowledge review queue, and every connected backend with its tool count.
Every Call, With the Arguments It Was Made With
Why it matters
When something goes wrong you need the exact call, its arguments, its response, the persona that allowed it, and the session it belonged to. A sanitized summary answers none of that.
How it works
The Events tab indexes every tool invocation, filterable by user, tool, status, and time, with sortable columns and CSV or JSON export. Any row opens a detail drawer carrying identity (user, persona, session), execution (tool, connection, duration), status and enrichment, transport sizes, and the full request parameters as JSON. Distributed tracing follows one request through sign-in, context gathering, and the underlying data call.
Which Node Is the Problem
Why it matters
Incident response starts with knowing whether the stack is degraded and which node is degrading it, before anyone starts guessing.
How it works
The Health tab reports per-node uptime, CPU, resident memory, heap, and goroutine counts across the fleet, with a clear status for each and a dash wherever a metric is genuinely missing rather than a zero that reads as healthy.
Watch Semantic Ranking Stay Healthy
Why it matters
Embedding work runs off the request path, so a slow provider or a run of retries degrades ranking toward keyword-only with nothing but a log line to say so. Search quietly gets worse and nobody is told.
How it works
The Indexing tab reports the embedding provider, model, and dimension, then a plain verdict per corpus: up to date, indexing, or degraded, each with real indexed-of-expected coverage and when it last ran. Equivalent states look identical, so a healthy corpus is recognisable at a glance rather than read. Below sit a throughput timeline, embed latency at the median with a 95th-percentile marker, in-flight jobs with their lease countdown and progress, retry backoff with attempt counts, and open failures grouped by error signature. A failure resolves itself and leaves the panel once a later job for the same unit succeeds. Re-index re-enqueues everything out of sync for a corpus.
Did the Email Actually Arrive
Why it matters
A share that never reached its recipient looks exactly like a share nobody opened. Without a delivery read, the first sign of trouble is somebody saying they never got it.
How it works
Counts by status sit above the list, failed, pending, sending, and sent, and each doubles as a filter. Every row shows when it was raised, who it was addressed to, the subject the message carried, its category, its status, and how many attempts were made. Opening a row exists for the failure case: it shows the error the mail server returned, verbatim, alongside the attempt count before the queue gave up. Filters narrow by recipient, status, and category. It holds recent history rather than an archive, and the window it covers is stated above the list.
Teach Every Session the Same Thing
Agent Instructions is the operating guidance every agent session receives before it does anything. It is the highest-leverage screen in the administrative half, because it is the one place a rule reaches every conversation without anyone repeating it.
Your Context on Top of the Platform Baseline
Why it matters
Guidance that lives in somebody’s head gets applied on the sessions they are watching. Written once and served to every session, it applies on the ones nobody is watching.
How it works
A split markdown editor puts source on the left and live preview on the right. Above it sits the read-only platform baseline: the platform-owned guidance composed beneath your own, naming only the tools this installation actually exposes, so you can see what is already covered and add only your business context on top rather than restating it. Every change made through the administrative sections is recorded with who made it and when, so the guidance has a history rather than a current value.
Turn Whole REST APIs Into Governed Tools
An agent can call any external REST or HTTP API by reading that API’s own OpenAPI description to learn its operations and inputs, then signing in and calling it under per-role rules. Ten APIs do not add a thousand tools, and every call rides the same audit pipeline as native data access. Read the API Gateway page.
One Spec, Every Connection That Points at It
Why it matters
Generating one tool per endpoint explodes the catalog: ten APIs would add a thousand tools an agent has to sort through, which wrecks tool selection long before it wrecks anything else.
How it works
A catalog is a versioned bundle of OpenAPI specs that many connections share, so one upload documents every connection pointing at that vendor. Specs are ingested by paste, file upload, or a public URL fetched once. The whole surface is then served through four tools: browse the spec sections, list a section’s operations, read one operation’s exact schema, and invoke it. Each spec carries an embedding-health badge and a last-fetched time, with refresh, retry, edit, and delete beside it, and a catalog cannot be deleted while a connection still references it. Large or binary responses stream straight to an asset instead of into the answer.
Watch Where the Outbound Calls Go
Why it matters
Outbound traffic is the part of an integration nobody watches until a vendor rate-limits you or an endpoint starts failing quietly.
How it works
The Dashboard’s API Gateway tab charts connection-to-operation traffic as a flow, with an inbound-versus-outbound health split by status category and breakdowns by status class, method, and calling identity. Every endpoint is semantically indexed, so operations rank by what they mean rather than by name matching, and a plain REST route exposes the same connectors to clients that are not agents at all.
Everything Produced, Across Everyone
The administrative Assets view is the platform-wide read of what agents have produced: every asset from every user, with the provenance that says where each number came from.
What Was Produced, and Who Produced It
Why it matters
A workspace nobody can see across is a workspace where the same report gets built four times and no one notices the fourth is wrong.
How it works
The table lists every asset on the platform with its name, owner, content type, file size, sharing state, and creation date, searchable and filterable by type, owner, and connection.
Where a Number Actually Came From
Why it matters
An artifact without lineage is a claim you cannot check. When a figure is disputed, the argument only ends when somebody can point at the query.
How it works
Asset detail renders the content in the same full viewer users get, alongside the originating session, the tool calls that produced it, the datasets those calls touched, and the full version history. Delete, download, and share are available from the same screen.
Every Backend, Including Other MCP Servers
Connections manages the backend instances the platform serves from: Trino, DataHub, S3, and MCP gateways. A gateway connection proxies an upstream MCP server and re-exposes its tools as native ones, under the same persona rules, audit trail, and enrichment as everything else.
Upstream Tools Under One Access Model
Why it matters
Every MCP server a team adopts is another endpoint, another sign-in, another silo. Agents end up juggling connections instead of getting one coherent surface.
How it works
A split-pane list groups connections by kind with their descriptions and tool counts; selecting one shows its metadata, its configuration with a show-sensitive toggle for credentials, and its actions. A gateway connection re-exposes an upstream server’s tools under a local prefix so they sit alongside native tools and obey the same rules. Test connection dials the upstream with the values on screen, before anything is saved, and reports whether tool discovery succeeded. Refresh tools re-reads a saved upstream and re-registers its catalog live, so every connected agent’s tool list updates without anyone reconnecting.
Sign In the Way Each Upstream Demands
Why it matters
Real upstreams authenticate in incompatible ways, and some hosted vendor servers require a human browser sign-in rather than a static token, which is exactly the case a scripted integration cannot cover.
How it works
Connections support bearer tokens, API keys, HTTP basic, OAuth 2.1 with either machine-to-machine credentials or browser sign-in with PKCE, and client-certificate mTLS. A browser sign-in connection shows a not-connected banner with a Connect button; authorizing opens the upstream’s own sign-in, and the card then names who authorized it and when. Tokens and secrets are encrypted at rest, access tokens refresh silently so scheduled work keeps running, and a certificate’s expiry surfaces as a badge before it bites.
Give a Third-Party Tool Your Warehouse Context
Why it matters
One source’s response carrying another’s context is the whole point, and it should apply to proxied third-party tools too. Hard-coding that per tool does not scale past the second one.
How it works
A rule attaches warehouse and catalog context to a proxied tool’s response without any code: a predicate that fires always or when the response contains a value, a source operation against DataHub or Trino, bindings that pull from the call’s arguments, the response, and the caller, and a merge strategy that decides where the context lands. A dry run pastes in a sample call and returns the merged response with no side effects. A rule that fails attaches a warning rather than failing the call it was enriching. Rules are managed from a drawer on the gateway connection and shown on the tool itself.
What the Platform Says It Is
Description sets the identity the platform reports to connected clients. It is the first thing an agent reads about what it has just connected to, and the sentence that decides whether it uses the platform well.
The First Thing an Agent Learns
Why it matters
An agent that does not know what a platform is for will use it like a generic database. A description that names the domain, the data, and the intended use changes the questions it asks.
How it works
The same split markdown editor as Agent Instructions, source beside live preview. What you write is surfaced to connected clients as the platform’s identity, and, like the instructions, every edit is recorded with its author and time.
Credentials for the Things That Are Not People
Keys mints credentials for programmatic callers: a scheduler, a pipeline, a script, anything that needs the platform without a human at a browser.
Scoped, Expiring, and Shown Exactly Once
Why it matters
A service credential with no scope and no expiry is a credential that outlives the project it was minted for and grants more than that project ever needed.
How it works
Each key is created with a name, an optional owner and description, its roles chosen from a browser, and an expiration preset from a day out to a year or never. The generated key appears once in a copy-now banner and never again. The table lists every key with its roles, owner, and expiry, dims expired ones with a badge, and revocation takes effect immediately.
Fail-Closed Access, Defined by Role
A persona maps the roles your identity provider already issues to exactly the tools and connections that role may reach. It is default-deny: what a persona does not allow is not merely refused, it is never shown to the agent at all.
What a Role Can Reach, and Nothing Else
Why it matters
Access defined as a pile of low-level permissions drifts from what the business actually meant, and anything not explicitly denied tends to leak. Roles should get what they need and nothing adjacent to it.
How it works
A persona carries allow and deny tool patterns, a connection allowlist, a priority, and the identity-provider roles it maps to. Because unauthorized tools are invisible rather than blocked, an agent never spends tokens reasoning about capabilities it cannot use, and access is refused before a request reaches the data layer. Context overrides tune behaviour per role with a description prefix and an agent-instruction suffix, so the same tool can be introduced differently to an analyst and to an engineer.
See What the Rule Resolves To Before You Save It
Why it matters
A pattern that looks right and resolves wrong is the whole risk of pattern-based access. Finding out after the fact means finding out from an incident.
How it works
The editor puts an identity panel beside a live permissions explorer that previews exactly which tools and connections the current allow and deny patterns resolve to, with a running allowed and denied count and a trace explaining which rule decided each one. Quick templates seed common policies for administrator, read-only, analyst, and engineer shapes, and a separate tab tunes the persona’s assistant behaviour.
The Library, From the Other Side
The administrative Prompts page manages every prompt at every scope, and it is where a personal prompt someone wrote becomes something their team, or the whole organization, is served.
Global, Persona, Personal, and System in One Table
Why it matters
Prompt quality drifts where nobody is looking. Seeing every scope in one sortable table is what makes a stale global prompt findable before somebody runs it.
How it works
A sortable table lists every prompt with a scope badge, a lifecycle badge, its owner, category, and tags, filtered by scope and searched across name and description. Editing exposes the lifecycle selector that moves a prompt from draft to approved to deprecated or superseded, stamping the approving admin; choosing superseded reveals a field for the replacement prompt’s name, so a retired prompt says what took its place.
Someone’s Prompt Becomes the Team’s
Why it matters
The prompts worth standardizing are the ones already being used, and their authors are rarely admins. Without a request path, good work stays personal.
How it works
A panel at the top of the page lists the personal prompts whose owners have asked for promotion, naming the owner, the scope requested, and the description; it is hidden entirely when nothing is pending. Approve applies the requested scope and marks the prompt approved, reject clears the request and leaves it personal, and a name that already exists at the target scope blocks approval as a conflict so the owner renames first. A prompt an admin creates at a shared scope lands approved with that admin stamped as approver, since the creator is the reviewer.
The Reference Library, Across Every Scope
The administrative Resources view is every uploaded file in one place, across every persona and scope, which is what makes curating the library possible rather than aspirational.
Find What Nothing Has Read
Why it matters
A reference library only decays in one direction. Material accumulates, nobody removes anything, and agents start pattern-matching against a template that was replaced a year ago.
How it works
Scope tabs cover all resources, global, and each persona, with text search and a category filter across them. The table adds a last-read column and a recently-read sort, so the library can be ordered by what is actually used, and a resource never read since it was uploaded over thirty days ago is flagged. An admin can open, edit, and delete any resource, including persona material they do not belong to, while listing and agent-facing reads stay scoped to membership.
Every Tool, Typed, Testable, and Attributed
Tools is a master-detail view of everything the platform exposes, grouped by the connection that provides it. A tool you cannot inspect is a tool you cannot govern, so each one opens onto its schema, its access rules, an execution surface, and its own usage.
The Schema and the Rule That Decided Access
Why it matters
Knowing that a role cannot call a tool is half an answer. The useful half is which rule decided it, because that is the part you can change.
How it works
The overview shows a tool’s description with an inline override editor, the connection it belongs to, its full JSON input schema, and per-persona access: which personas can call it and the exact pattern that resolved to that verdict. An adjacent activity view aggregates the tool’s own call volume, success rate, and average duration, with a deep link into the audit log filtered to it.
Run the Tool Yourself Instead of Asking an Agent To
Why it matters
Debugging a tool by asking an assistant to call it puts a language model between you and the answer. You want the raw call and the raw response.
How it works
Try It generates a form from the tool’s schema with type-appropriate inputs, a text area for a query, a number field for a limit, a dropdown for an enum, runs it against the live source, and renders the result as a formatted table with a raw toggle. A timestamped history keeps every test call with its duration and status, and any of them replays.
Check the Blast Radius Before You Commit
Why it matters
Turning a tool off platform-wide is the kind of change that is obvious in hindsight and surprising in the moment, because the person making it rarely knows every persona it touches.
How it works
Visibility toggles a tool’s membership in the platform-wide deny list and previews whether a given persona can still reach it, before the change is applied.
A Directory So Sharing Knows Your Colleagues
Users is a directory of people, not an authorization layer. It grants nothing on its own; it exists so the share picker can suggest a colleague by name instead of asking somebody to remember an address.
Suggest the Person Before They Have Signed In
Why it matters
Sharing fails on the small stuff. A mistyped address sends work to nobody, and a new hire who has not logged in yet cannot be picked at all.
How it works
Anyone who authenticates is recorded automatically with the name from their sign-in. An admin can pre-add someone by email so they are selectable for sharing before their first login, where they show as invited rather than active. Admin-entered names take precedence: a later sign-in fills blank fields but never overwrites a name someone set deliberately. The table lists name, email, status, and last seen, with search across it.
Next
Email Notifications
How a share, a comment, or an unworked review queue reaches a person who is not looking at the portal.