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.

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

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.

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.