#I'm on 2026.4.12, host install via systemd. I registered an external HTTP/SSE MCP server (Supabase e

13 messages · Page 1 of 1 (latest)

sinful minnow
#

I'm on 2026.4.12, host install via systemd. I registered an external HTTP/SSE MCP server (Supabase endpoint) using openclaw mcp set. The server shows in openclaw mcp list. But when I ask my agent to use the tools from that server, it doesn't have them available — it falls back to web search instead.
Question: Does mcp.servers via openclaw mcp set actually expose the registered server's tools to the embedded Pi agent during Discord/channel sessions? Or is that registry only for other runtimes (ACP/bundle)?
If not, what is the correct way to make an external HTTP/SSE MCP server's tools available to the embedded agent?

cold stratusBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

dreamy fableBOT
spark zenithBOT
#

Short answer: yes. openclaw mcp set is supposed to make that server available to the embedded Pi agent in normal Discord/channel sessions too, not just ACP/bundle.

A few important nuances:

  • openclaw mcp list only proves the config was saved.
  • It does not prove the embedded agent successfully connected to the remote MCP server and loaded listTools().
  • If that runtime connection fails, the tools simply never appear in the turn, so the agent falls back to web search or other tools.

So the correct path for an external MCP server is still:

  • save it under mcp.servers via openclaw mcp set (or config file)
  • then let the embedded Pi runtime consume it on the next turn

Two likely gotchas here:

  1. Transport mismatch
    Remote MCP defaults to sse. If your Supabase endpoint is actually streamable HTTP, set:
# 
   {"url":"https://...","transport":"streamable-http","headers":{"Authorization":"Bearer ..."}}
  1. Connection/auth failure at runtime
    Check:
    openclaw logs --follow
    then trigger a turn and look for lines like:
    • bundle-mcp: failed to start server ...
    • connection timeout
    • auth/header errors

Slightly confusingly, the log prefix is still bundle-mcp: even for top-level mcp.servers.

Also, the exposed tool names are prefixed like:

sinful minnow
#

Please use your open-brain tool to search for "ClawsHouse"

spark zenithBOT
#

I can’t directly invoke your registered MCP server from this support thread, only the tools available in this session.

I did a normal search for “ClawsHouse”, and I’m not seeing a real hit, just false matches like Clownhouse. So if your agent is doing the same kind of fallback, that strongly suggests the MCP tools are not actually loading into the turn.

A good deterministic test on your side is:

openclaw logs --follow

Then send the agent a prompt that should use that MCP tool and watch for either:

  • bundle-mcp: failed to start server ...
  • timeout/auth/transport errors
  • or a successful MCP tool registration/call

If you paste:

#
  • openclaw mcp show <name> --json
  • the relevant openclaw logs --follow lines from one test turn

…I can help narrow it down pretty fast.

sinful minnow
#

Follow-up: confirmed the registration is {"url":"https://..."} defaulting to SSE. Network is reachable from host (curl returns 406, not a timeout). But logs show bundle-mcp: failed to start server "open-brain" ... MCP server connection timed out after 30000ms during an agent turn. What would cause a timeout at the bundle-mcp level when the host can reach the URL directly?

spark zenithBOT
#

Yep, that pattern usually means protocol mismatch, not basic network reachability.

A plain curl getting 406 proves the host is there, but it does not prove OpenClaw can complete the MCP handshake (connect + initialize + listTools).

For Supabase, the big clue is this: their current MCP docs use Streamable HTTP, not legacy SSE. OpenClaw defaults a bare {"url":"https://..."} entry to sse.

So what is likely happening is:

  • OpenClaw tries to talk SSE
  • the Supabase endpoint expects streamable-http
  • the MCP session never fully establishes
  • the wrapper logs bundle-mcp: failed to start server ... timed out after 30000ms

So I’d try this first:

# 
openclaw mcp set open-brain '{"url":"https://...","transport":"streamable-http"}'

If auth is needed:

openclaw mcp set open-brain '{"url":"https://...","transport":"streamable-http","headers":{"Authorization":"Bearer ..."}}'

Why this fits your symptoms:

  • 406 from curl is common when the server expects different Accept headers / transport semantics
  • Supabase’s own MCP example uses WebStandardStreamableHTTPServerTransport
  • OpenClaw’s default for remote MCP is SSE unless you set transport

Good sanity check: