Skip to content

Latest commit

 

History

History
118 lines (72 loc) · 3.88 KB

File metadata and controls

118 lines (72 loc) · 3.88 KB

Remote Proxy Real-Test Status

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.

What was built

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.

What was proven for real

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/list is 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

Important transport finding

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/list responses 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.

What is still not proven

The reverse proxy itself is real-tested, but full end-to-end agent proof is still incomplete.

OpenClaw

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 status reports missing OpenAI auth
  • with no working model auth, the agent fails before it can exercise MCP

PicoClaw

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_events were recorded

This means the current run did not prove that PicoClaw successfully initialized and used the proxied remote MCP server.

ZeroClaw

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

Current conclusion

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

Recommended next verification order

  1. Fix one agent model-auth surface first so the agent can complete a turn.
  2. Add an agent-specific MCP connectivity probe before involving the LLM loop.
  3. Re-run the live harness one agent at a time.
  4. Only after one claw client passes end-to-end, add a second real remote connector beyond Notion.

Candidate second real connector

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.