Native MCP Support

Since 1.1.0, the DVARA MCP Proxy speaks the Model Context Protocol (MCP) natively on both sides, alongside the original REST surface — and both run behind the same governance filter chain. An MCP client can point straight at DVARA and get policy enforcement, approval gates, PII scanning, and signed, chained audit on every tool call, transparently.

DVARA plays two roles, and they are governed identically:

• Northbound — DVARA as an MCP server. Your agents and IDEs connect to DVARA.
• Southbound — DVARA as an MCP client. DVARA connects to your upstream MCP servers.

DVARA as an MCP server (northbound)

DVARA exposes a single native MCP endpoint — POST/GET /mcp on the MCP Proxy (port 8070) — over Streamable HTTP. Point any MCP-compatible client at it: Claude Desktop, Cursor, an IDE, or an agent built with any MCP client library.

{
  "mcpServers": {
    "dvara": {
      "type": "streamableHttp",
      "url": "https://your-dvara-host:8070/mcp",
      "headers": { "Authorization": "Bearer gw_your_api_key" }
    }
  }
}

What the client sees is a standard MCP server. What you get is governance:

• Per-tenant auth. The Authorization: Bearer gw_… header is a DVARA API key, resolved to its tenant exactly as on the data plane. Every session is tenant-scoped.
• Aggregated, namespaced tool catalog. tools/list returns the governed catalog across all MCP servers registered to that tenant, namespaced as {serverId}__{toolName} so tools from different upstreams never collide. Each tool description is scanned for tool-poisoning before it is returned.
• Governed tool calls. tools/call runs through the full MCP filter chain — policy evaluation, argument-level tool policies, human approval gates enforced at execution, loop detection, PII scanning, prompt-injection scanning, and signed audit — before it reaches the upstream. See Agentic AI Governance for the controls.
• Origin validation. The endpoint validates the Origin header (a DNS-rebinding defense). Set the permitted origins with dvara.mcp-gateway.native.allowed-origins.

The endpoint advertises protocol revision 2025-06-18 and also accepts 2025-03-26. It is enabled by default; toggle it with dvara.mcp-gateway.native.enabled.

Virtual MCP servers — a curated toolset

New in 1.2.0. By default a tenant's /mcp endpoint exposes every tool across all its registered servers. A virtual MCP server is a named bundle that exposes only a curated, allow-listed subset of tools drawn from several member servers — one endpoint, one tool list, everything else invisible. It's the way to hand an agent exactly the tools it should have (e.g. a "support-agent toolkit" = GitHub issues-only + a read-only filesystem) without exposing the rest.

Create one via the Admin API (POST /v1/admin/mcp/virtual-servers) with its member_server_ids and a tool_allow_list of {serverId}__{tool} names (default-deny — only listed tools are exposed). A native client then selects it by name with a request header:

X-Dvara-Virtual-Server: support-agent-toolkit

With the header set, tools/list returns only the curated union and a tools/call to any non-allow-listed (or non-member) tool is rejected before it reaches an upstream. Every allowed call still runs the full governance chain on its owning member server — the virtual server curates which tools are visible; it doesn't bypass any policy, PII, approval, or audit control. Without the header, the endpoint behaves exactly as before (the full tenant aggregate). Virtual servers are tenant-scoped and cannot be nested.

DVARA as an MCP client (southbound)

When DVARA calls your upstream MCP servers, it dispatches per server on that server's configured transport. Register a server and set its transport from the Console or Portal or the admin API; DVARA tool-syncs the catalog natively and the result flows through the same governance pipeline.

Transport	What it is	Use it for
REST	DVARA's bespoke REST shape (POST <url>/tools/call, /tools/list)	The default for existing servers; custom REST tool servers
STREAMABLE_HTTP	Native MCP over Streamable HTTP (spec 2025-06-18)	Modern MCP servers — the recommended native default
SSE	Native MCP over the legacy HTTP+SSE transport (spec 2024-11-05)	Older MCP servers you don't control
STDIO	Native MCP over stdio (local subprocess)	Local subprocess servers — single-pod / sidecar deployments only
REST_BRIDGE	A plain REST/OpenAPI API, exposed as governed MCP tools	Bringing an existing REST service to agents without writing an MCP server (1.2.0+)

Native is opt-in per upstream — REST remains the default for already-registered servers, so upgrading to 1.1.0 changes nothing until you switch a server's transport.

Turning a REST API into governed MCP tools (REST_BRIDGE)

New in 1.2.0. You don't need to write an MCP server to put an existing REST API in front of your agents. Register the API with its OpenAPI spec and set transport: REST_BRIDGE; DVARA synthesizes one MCP tool per operation (tools/list) and maps each tools/call to the corresponding HTTP request — all through the same governance chain (policy, PII, approval gates, tamper-evident audit) as any other MCP tool.

• Register the base URL + the OpenAPI document (stored inline) via the admin API (transport: REST_BRIDGE, openapi_spec). The spec must parse and expose at least one operation, and the base URL is SSRF-validated at registration.
• Tool synthesis: each operation becomes a tool — operationId → tool name (falling back to {method}_{path}); path/query params + JSON request body → the tool's input schema. Operations that need deferred features are skipped with a logged reason (you'll see "N of M operations exposed"). Change the stored spec and the tool set re-synthesizes automatically.
• Auth: API key / bearer token, resolved through DVARA's credential model and injected into the configured header.
• Responses: the upstream JSON body is returned as MCP text; a non-2xx status becomes a clear MCP error.
• Governance is identical — a REST-bridged tools/call lands the same tenant-scoped mcp_tool_calls + audit records as a native MCP call.

Delegated (on-behalf-of) auth

New in 1.2.0. By default DVARA authenticates to an upstream with the server's own stored credential (STORED — one credential for all callers). For a per-user SaaS MCP server (e.g. each user's own GitHub), set the server's auth mode to DELEGATED: DVARA then forwards the caller's own token to the upstream, so the upstream enforces that end user's permissions.

• How the caller supplies it: send the user's upstream token in the X-Dvara-Delegated-Authorization header (distinct from Authorization, which carries the DVARA API key). A DELEGATED server called without it is rejected with 401 MCP_DELEGATED_TOKEN_REQUIRED.
• Never stored, never logged: the delegated token is used only to authenticate the one upstream call. It never lands in mcp_tool_calls, audit records, or logs — the audit trail records auth_mode: delegated and a fingerprint (sha256: hex prefix), not the token.
• Works on every transport (native, REST, REST_BRIDGE) — the token is forwarded exactly where the stored credential would have gone.
• v1 is token passthrough — DVARA forwards the caller's bearer as-is. A full RFC 8693 token-exchange grant (minting a scoped upstream token from the caller's) is a planned follow-up.

v1 scope: simple GET / POST (and basic PUT / DELETE) with path/query params and a JSON body; API-key / bearer auth. Deferred to follow-ups: OAuth / flow-based auth, pagination, file / multipart uploads, and deeply-nested oneOf / allOf schemas.

Governance applies the same way

Native MCP is a transport change, not a governance change. Whether a tool call arrives over REST or native MCP, it passes through the identical filter chain and produces the same forensic-grade records. The governance surfaces are unchanged:

• Agentic AI Governance — tool-call visibility, session tracking, loop detection, kill switch, and approval gates.
• The DVARA Flightdeck — agent sessions and MCP activity, and the tenant-facing MCP servers, activity, and approvals views.

Current limitations

• No server-initiated tools/list_changed push. The northbound transport is stateless per tenant (so the endpoint scales horizontally across pods), which means DVARA does not push tool-set-change notifications. A changed tool set surfaces on the client's next tools/list; DVARA keeps its catalog fresh as upstream registrations change.
• Northbound is Streamable HTTP only, by design. It is the one network-native transport that carries per-tenant auth and scales across pods; stdio carries no network auth boundary and the legacy HTTP+SSE transport is deprecated. Clients that only speak stdio or SSE reach DVARA through a local bridge such as mcp-remote — the shim lives on the client side, so nothing is excluded.

Configuration reference

Property	Default	Purpose
dvara.mcp-gateway.native.enabled	true	Enables the native /mcp server endpoint
dvara.mcp-gateway.native.allowed-origins	(empty)	Comma-separated list of permitted Origin values for DNS-rebinding defense

Per-upstream transport is set on each registered MCP server (the transport field), not globally.

Where to go next

• Agentic AI Governance — the controls every tool call runs through.
• Multi-Tenancy — how Bearer-token tenant resolution scopes each MCP session.
• Platform Architecture — where the MCP Proxy sits as a governed data plane.