Plexara
One surface, two doors
Plexara exposes one governed surface: assets, collections, knowledge, memory, prompts, personas, audit, and tool execution. There are two ways to reach it. An MCP server speaks to AI agents in the protocol they already understand, and a REST API speaks to ordinary services over HTTP.
They are not two different products with a sync problem between them. They are two entrances to the same room. Every call through either door resolves the same identity, writes to the same audit log, and is filtered by the same personas. There is no surface that only one of them can reach and no governance that only one of them enforces.
That symmetry is the point. A team can start with an agent over MCP, add a backend integration over REST later, and never reconcile two security models, because there is only one.
Two doors, one room
MCP server
for agents
REST API
for services
One governed surface
one identity · one audit log · one persona model
Which door to use
Choose REST when a service needs a stable, versioned contract: a backend job, a scheduled integration, anything with no agent in the loop. The REST API ships an OpenAPI specification, so a typed client can be generated for whatever language the service is written in using standard tooling.
Choose MCP when an AI agent needs the same operations through a protocol it already speaks. The server exposes tools, resources, and prompts that the client negotiates at connect time, and it works with any MCP-compatible client SDK, in TypeScript, Python, or the other open-source libraries.
The decision is about ergonomics, not capability. Neither door is a subset of the other. They expose the same operations because they are backed by the same surface.
Which door to use
Service-to-service
Reach for REST
- A backend service calling a stable, versioned contract
- Clients generated from an OpenAPI specification
- Scheduled jobs and integrations with no agent in the loop
- You want HTTP semantics and a typed SDK
Agent-facing
Reach for MCP
- An AI agent needs the same operations through a protocol it knows
- Tools, resources, and prompts negotiated at connect time
- Any MCP-compatible client SDK, in TypeScript or Python
- You want the model to discover and call capabilities
Three ways to authenticate, one persona resolution
OIDC with required JWT claims is the primary path: your identity provider asserts who the caller is, and Plexara trusts that assertion. OAuth 2.1 with PKCE is supported for new client types, bringing the code-interception protection that PKCE was designed for. API key management is available for service accounts that cannot run an interactive flow.
What every method has in common is what happens after authentication. Your identity provider establishes who the caller is. Plexara resolves that identity to a persona, and the persona decides what the caller can see and do. Authentication and authorization are kept distinct on purpose, the same way enterprise systems are met where they are without weakening isolation.
Three ways in, one resolution
OIDC with JWT claims
The primary path. Your identity provider asserts who the caller is.
OAuth 2.1 with PKCE
For new client types, with the code-interception protection PKCE provides.
API keys
For service accounts that cannot run an interactive auth flow.
Extending the surface
A custom tool can be registered through the Portal or the management API. Once registered, it appears in the agent tool list like any other Plexara tool, with persona-scoped visibility and the same audit and authorization treatment. It is part of the governed surface, not a bypass around it.
This matters because adding capability is the easy part and governing it is the hard part. A custom tool that escaped the persona model or the audit log would reopen exactly the gap the platform exists to close. Keeping extensions inside the same rules is what lets the surface grow without the governance fraying.
It is also why more tools do not automatically mean a more capable agent. Capability scales with context and governance, not with connector count, so a custom tool earns its place by being scoped and described well, not merely by existing.
Extending without forking
Register
A custom tool is added through the Portal or the management API.
Scope
It is given persona-scoped visibility, like every other tool.
Govern
It carries the same audit and authorization treatment.
Pick the protocol, keep the governance
For a developer, the choice between REST and MCP is a choice of convenience. A backend service wants a typed HTTP client. An agent wants a protocol it can negotiate. Plexara serves both from one place.
What does not change with the door is everything that matters for trust. The identity is resolved the same way, the persona filters the same way, and the audit log records the same way. The surface is governed once, and reached however suits the work.
Further Reading
Model Context Protocol Specification (2025-06-18)
Anthropic and Model Context Protocol contributors · 2025
An open protocol, originally introduced by Anthropic, that standardizes how client applications connect to servers exposing tools, resources, and prompts over JSON-RPC, including client and server capability negotiation.
Proof Key for Code Exchange by OAuth Public Clients (RFC 7636)
N. Sakimura (Ed.), J. Bradley, N. Agarwal (IETF) · 2015
The IETF standard defining PKCE, which mitigates authorization-code interception by having the client present a code verifier when it redeems the code. PKCE is mandatory in OAuth 2.1 and underpins secure authorization-code flows for SDK and CLI clients.
OpenAPI Specification
OpenAPI Initiative (The Linux Foundation) · 2025
A standard, language-agnostic interface description for HTTP APIs that lets humans and machines understand a service without access to its source code. OpenAPI documents are the basis from which typed REST client SDKs are generated.