Plexara
MCP Gateway
One envelope
Connect an MCP server once, govern it like everything else
An admin adds an MCP server in the portal by its address, picks how it signs in, and saves. Plexara reads the server's tool catalog and registers every tool under a name that carries the connection, so a vendor's get_contact becomes crm__get_contact, sitting beside your warehouse queries and catalog lookups in the same tool list.
From your assistant's side nothing new appears to configure. It discovers proxied tools the way it discovers native ones, calls them through the same connection, and every call passes the same persona check and lands in the same audit log. The vendor server never learns who your individual users are; it sees one service identity per connection, while per-person attribution stays in your audit trail.
Before a connection is saved, a test dials the server and reports the tools it would add. After a vendor ships new tools, one refresh re-reads the catalog. The connections screen shows each server's reachability continuously.
One endpoint
Your assistant connects to Plexara; Plexara connects to the rest
Named tools
Every proxied tool carries its connection name, like crm__get_contact
Same persona rules
Allow and deny proxied tools with the same patterns as native ones
Same audit log
Every proxied call recorded with who, what, and how long
Credentials
The connection signs in, not every user
Each connection authenticates to its upstream server with one service credential, managed by your admins in the portal. Users never handle vendor secrets, and vendor secrets never travel through an AI conversation. Four sign-in modes cover the servers in the wild:
No credential
For servers that are open inside your network or public by design. The connection is still persona-gated and audited on the Plexara side.
Bearer token
A token the admin pastes once. It is stored encrypted, sent only server-side, and never appears in a prompt, a session, or a client.
API key
Same handling as a bearer token, delivered in the header the vendor expects. Editing a connection later never requires re-entering the secret.
OAuth 2.1
For machine-to-machine grants, tokens are fetched and refreshed automatically. For services that require a browser sign-in, the admin clicks Connect, signs in once, and refresh tokens keep the connection alive after that, including for scheduled prompts that run overnight.
Salesforce's hosted MCP server is the worked example: it requires the browser sign-in flow. An admin connects it once from the portal, and from then on its tools are available to any persona that allows them.
Cross-enrichment
Vendor answers, joined to your warehouse
A vendor tool answers with vendor data, and vendor data alone rarely settles a business question. The gateway can attach context from your own sources to a proxied tool's response: a warehouse lookup keyed by a value in the answer, or catalog context for an entity it names. Admins define these as rules in the portal, per tool, with no code involved.
The original response is never altered; the added context arrives alongside it, so the assistant sees both. A rule that fails attaches a warning instead of breaking the call, and a dry-run in the rule editor shows exactly what a rule would fetch and merge before it goes live.
enrichment rule · connection crm
- When
- crm__get_contact returns a response containing an email address
- Fetch
- lifetime value and last order date for that email, from your warehouse
- Merge
- the result lands beside the vendor answer as warehouse_signals
Operations
Built for imperfect upstreams
A third-party server will eventually be slow, stale, or down, and none of that should take your assistant with it. Persona rules decide who can call what, with the connection prefix making a whole vendor easy to scope:
The upstream
The gateway
Where you see it
The upstream
A server is unreachable when connected
The gateway
The rest of the platform is unaffected. The connection registers no tools until the server is back and refreshed.
Where you see it
A reachability badge on the connections screen, and a recorded warning.
The upstream
A server fails mid-call
The gateway
The error your assistant receives names the connection, so it can route around the outage or say what is down.
Where you see it
The failed call in the audit log, with the same detail as a success.
The upstream
A vendor changes its tool catalog
The gateway
One refresh re-reads the catalog and updates the tool list. A test before saving shows what a connection would add.
Where you see it
The updated tool roster under the connection, each tool inspectable.
The upstream
A server speaks an older MCP revision
The gateway
Plexara negotiates with each side separately and translates between them, so an aging server stays usable from the newest clients.
Where you see it
Nothing. The difference never reaches your assistant.
How this differs
Plexara vs MCP Gateways
A standalone gateway governs traffic. See what changes when the platform behind the endpoint also owns your data, context, and memory.