Skip to main content
These products work with Consensus but with a limitation on one of the auth modes, or with docs that are still settling. In every case the shared-API-key path is the reliable one.
Use the plugin’s passthrough-listener mode with a Gateway Service pointing at https://mcp.consensus.app and a route on /mcp:
The MCP plugin doesn’t inject an upstream credential itself. Add the bearer with Kong’s Request Transformer plugin: config.add.headersAuthorization:Bearer ak_live_.... Kong has no upstream OAuth broker; its OAuth plugins are inbound only. Requires Kong Gateway 3.12+ and an upstream on MCP 2025-06-18 or later.
Add Consensus as an MCP target with a backend auth key:
Set statefulMode: stateless if you don’t want the gateway to synthesize sessions. backendAuth.passthrough forwards a caller’s own Consensus token; there is no built-in authorization-code broker.
Zuplo’s gateway is stateless, POST-only Streamable HTTP with no SSE, which mirrors Consensus exactly. Point the McpProxyHandler at the server:
For a shared key, add the set-headers-inbound policy with Authorization = Bearer ak_live_.... For per-user OAuth, the mcp-token-exchange-inbound policy’s clientRegistration: auto uses Client ID Metadata Documents rather than RFC 7591 Dynamic Client Registration; use mode: manual with a confidential client from Consensus, or test auto first.
Docker’s MCP Toolkit catalog doesn’t document adding a remote server by URL. Docker Agent (cagent) does:
Omit headers to use Dynamic Client Registration OAuth instead. Treat this as workstation tooling rather than an enterprise gateway.
Add a remote server with type: streamable-http (inferred from the /mcp suffix) and a static header:
Boomi’s docs are mid-migration from Lunar; the remote-server page isn’t republished yet, and its documented static OAuth covers client-credentials and device flows only. Use the bearer path.
Running one of these and hitting a snag? Contact sales and we’ll help verify the setup.