Hi maintainers,
Opening an issue first to gauge appetite before any code work, in the same shape as #12423.
Question
Would maintainers accept a third-party integration entry for Vaara (Apache 2.0, https://github.com/vaaraio/vaara) used as a transparent runtime governance proxy in front of any stdio MCP server a Continue.dev user configures?
The intended contribution:
- A docs page in the third-party integrations area covering the three-step setup recipe.
- A small worked example pointing at an existing MCP server (Vaara already ships demos for GitHub MCP and SAP MCP).
- No core Continue.dev changes. The proxy is invoked as the user's configured MCP
command, sitting between Continue.dev and the upstream server.
What Vaara does at the MCP layer
The proxy emits a hash-chained audit record per tools/call, resources/read, and prompts/get, with optional Ed25519-signed OVERT 1.0 envelopes for the same set. Operator allowlist and denylist flags filter tools, resources, and prompts at the perimeter. Streaming notifications/progress and notifications/message are correlated to the originating tool call and audited. Initialization handshake forwards unchanged.
Concrete usage shape:
python -m vaara.integrations.mcp_proxy \
--upstream <user's mcp command> \
--db ./mcp_audit.db
Point Continue.dev's MCP client at the proxy instead of the upstream, no other changes.
Why this might fit
Issue #12068 (APEX RGPD), #12172 (granular tool approval policy), #12248 (subagent permissions and policy bypass), and #11468 (TLS verification and OAuth) suggest Continue.dev users are asking for governance and audit surfaces at the MCP edge. A drop-in proxy hands that surface to deployers without core changes.
Credentials
- Vaara is acknowledged in the industry contributors of IMDA's Model AI Governance Framework for Agentic AI v1.5 (Singapore, 20 May 2026) alongside Google, IBM, Microsoft, AWS, OCBC, Tencent.
- AMD developer testimonial, May 2026.
- OpenSSF Best Practices Project 12612.
What I would draft if you say yes
- A docs page following the integration pattern for third-party MCP layers.
- A short demo recipe with one upstream MCP server users will recognise.
- A test fixture proving the proxy preserves upstream tool semantics while writing the audit chain.
If you say no
Fine. No PR will follow. I will not bump or repost.
Henri Sirkkavaara
[email protected]
https://github.com/vaaraio/vaara
Hi maintainers,
Opening an issue first to gauge appetite before any code work, in the same shape as #12423.
Question
Would maintainers accept a third-party integration entry for Vaara (Apache 2.0, https://github.com/vaaraio/vaara) used as a transparent runtime governance proxy in front of any stdio MCP server a Continue.dev user configures?
The intended contribution:
command, sitting between Continue.dev and the upstream server.What Vaara does at the MCP layer
The proxy emits a hash-chained audit record per
tools/call,resources/read, andprompts/get, with optional Ed25519-signed OVERT 1.0 envelopes for the same set. Operator allowlist and denylist flags filter tools, resources, and prompts at the perimeter. Streamingnotifications/progressandnotifications/messageare correlated to the originating tool call and audited. Initialization handshake forwards unchanged.Concrete usage shape:
Point Continue.dev's MCP client at the proxy instead of the upstream, no other changes.
Why this might fit
Issue #12068 (APEX RGPD), #12172 (granular tool approval policy), #12248 (subagent permissions and policy bypass), and #11468 (TLS verification and OAuth) suggest Continue.dev users are asking for governance and audit surfaces at the MCP edge. A drop-in proxy hands that surface to deployers without core changes.
Credentials
What I would draft if you say yes
If you say no
Fine. No PR will follow. I will not bump or repost.
Henri Sirkkavaara
[email protected]
https://github.com/vaaraio/vaara