This note captures what was actually proven for the remote-connector reverse proxy, what is still blocked, and what the latest real-agent attempts showed.
Consentry now has a remote MCP reverse-proxy path mounted at:
/proxy/:slug
The intended flow is:
agent HTTP MCP client -> Consentry reverse proxy -> upstream remote MCP server
The reverse proxy runs the same policy / consent / intent pipeline used by the local stdio proxy, then forwards the request upstream.
The strongest confirmed path today is a real Notion-backed test:
real Notion token
-> local notion-mcp-server in HTTP mode
-> Consentry /proxy/notion-live
-> real MCP calls through the proxy
That path was tested for real and confirmed:
- upstream rejects missing bearer auth
- Consentry forwards the auth header to the upstream
tools/listis annotated and the Consentry safety-check tool is injected- a real Notion read succeeds through the proxy
- consent rows and decision events are recorded in Consentry
The real Notion MCP HTTP server returns some POST responses as text/event-stream, including tools/list.
Because of that, the proxy needed two compatibility fixes:
- parse SSE-framed
tools/listresponses so annotation and safety-tool injection still happen - normalize single-message SSE POST responses back to JSON for clients that advertise
Accept: application/json
Those fixes are now in the proxy and covered by the isolated integration test.
The reverse proxy itself is real-tested, but full end-to-end agent proof is still incomplete.
OpenClaw did not reach the proxy in the live test harness.
Current blocker:
- the local OpenClaw setup is using
openai/gpt-5.5 openclaw models statusreports missing OpenAI auth- with no working model auth, the agent fails before it can exercise MCP
PicoClaw did not produce confirmed proxy traffic in the current live harness.
Observed behavior:
- the process entered the agent turn and then hung until timeout
- no corresponding Consentry
decision_eventswere recorded
This means the current run did not prove that PicoClaw successfully initialized and used the proxied remote MCP server.
ZeroClaw still did not complete a real proxied agent run.
Observed behavior:
- ZeroClaw timed out waiting for MCP initialize from the proxied server
- its configured OpenRouter provider also returned
401 Unauthorized
So there are two unresolved questions on this surface:
- whether ZeroClaw's MCP client is fully compatible with this Streamable HTTP server shape
- whether the local ZeroClaw provider config is usable for a real agent turn
What we can honestly claim now:
- the remote proxy path itself works against a real hosted-service-backed MCP server
- auth-header pass-through was proven against a real server
- consent / policy / decision-event logging was proven on the remote proxy path
What we should not claim yet:
- that OpenClaw, PicoClaw, and ZeroClaw have all been proven end-to-end through this path
- Fix one agent model-auth surface first so the agent can complete a turn.
- Add an agent-specific MCP connectivity probe before involving the LLM loop.
- Re-run the live harness one agent at a time.
- Only after one claw client passes end-to-end, add a second real remote connector beyond Notion.
The local repo and config files do not currently expose Google or Figma as reusable local MCP server configs.
That means the cleanest next real connector is whichever remote MCP service already has:
- a local HTTP/SSE MCP server option, or
- a plainly configured local token-based MCP endpoint
Notion fit that shape well, which is why it was the first successful real proof.