On 2026.4.12, I registered an external MCP server via openclaw mcp set with transport: streamable-ht | Friends of the Crustacean 🦞🤝 | Page 1

arctic zealot Apr 14, 2026, 1:11 AM

#

On 2026.4.12, I registered an external MCP server via openclaw mcp set with transport: streamable-http. It shows in openclaw mcp list. But when the agent runs a turn, there are zero bundle-mcp log lines — the server is never attempted. The agent has no awareness of the tools. What is required to make mcp.servers entries actually available as tools during embedded Pi agent turns on a standard Discord channel session?

royal sinewBOT Apr 14, 2026, 1:11 AM

#

remote mauveBOT Apr 14, 2026, 1:11 AM

#

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

royal sinewBOT Apr 14, 2026, 1:11 AM

#

wise novaBOT Apr 14, 2026, 1:14 AM

#

I’m checking the docs and code path so I can give you the real requirement, not a guess.

#

First, can you paste openclaw --version? This bit is version-sensitive.

I checked the current docs/code path. For a normal Discord session using the embedded Pi runner, mcp.servers should become tools automatically. There is no separate “enable MCP for Pi” switch.

What has to be true:

the session is actually using embedded Pi, not a CLI/ACP backend
the selected model still has tools enabled (compat.supportsTools must not be false)
the running gateway has the updated config snapshot (default reload should pick it up, but if reload is off or failed, openclaw gateway restart)
the server entry is valid (url, optional transport: "streamable-http", headers, etc.)

Two gotchas:

openclaw mcp set only stores config, it does not validate or connect by itself
successful MCP load is mostly silent, so zero bundle-mcp log lines does not prove it was skipped. Those logs are mostly warnings/failures/sanitization

When it does load, the tools are materialized per run as:

#

<serverName>__<toolName>

One more caveat, I would not trust the current “effective tools” style views for this. These MCP tools are added dynamically at run time.

So if you’re on embedded Pi, using a tool-capable model, and the gateway has reloaded config, then mcp.servers should be enough. If 2026.4.12 still never attempts the server, that smells like a regression.

If you want, paste these and I’ll narrow it down fast:

openclaw --version
openclaw mcp show <name> --json
openclaw config get gateway.reload.mode
openclaw logs --follow

#

Docs: https://docs.openclaw.ai/cli/mcp https://docs.openclaw.ai/gateway

arctic zealot Apr 14, 2026, 1:20 AM

#

Version: 2026.4.12 (1c0672b)
openclaw mcp show open-brain --json:
{
"url": "https://...supabase.co/functions/v1/open-brain-mcp?key=***",
"transport": "streamable-http"
}
openclaw config get gateway.reload.mode: Config path not found (not set, using default)
When the agent runs a turn, zero bundle-mcp log lines appear. The agent does web search instead of using OB tools. Model is openrouter/auto via OpenRouter.

wise novaBOT Apr 14, 2026, 1:22 AM

#

I’ve got enough context now, let me check the OpenRouter side before I point you at the wrong thing.

#

Thanks, that helps. I don’t think you’re missing a hidden enable flag.

On 2026.4.12, mcp.servers with transport: "streamable-http" is already in the embedded Pi path. So for a normal Discord session on embedded Pi, your saved entry should be eligible automatically.

A few important clarifications:

Zero bundle-mcp lines is not proof of failure. Successful MCP startup is mostly silent right now. Those log lines are mainly warnings, failures, stderr passthrough, or name-sanitization messages.
Your gateway.reload.mode result just means the key is unset, so you’re on the default, which is hybrid per docs.
openrouter/auto is a bad control case for tool debugging. Even if the MCP tools are present, the routed model may still decide to use web_search.

So the two things I’d focus on are:

Is the running gateway using the same config file/profile the CLI edited?
This is the big one when mcp show sees the server but the runtime behaves like it does not.

Run:

#

   openclaw gateway status --json
   openclaw status --all

gateway status is the one that should show which config the service likely used.

Test with a concrete model, not openrouter/auto.
auto adds routing ambiguity, which makes “is MCP present?” much harder to answer cleanly.

What I would do next:

openclaw gateway status --json
openclaw status --all
openclaw logs --follow

#

Then do one turn with:

a concrete model instead of openrouter/auto
a prompt that explicitly says to use the Open Brain MCP tools and not web search

If that still produces no MCP use on 2026.4.12, I’d start treating it as a likely regression.

Docs: https://docs.openclaw.ai/cli/mcp https://docs.openclaw.ai/gateway https://docs.openclaw.ai/providers/openrouter

If you paste the gateway status --json output, I can help check whether this is a config-path mismatch or an actual MCP/runtime bug.

arctic zealot Apr 14, 2026, 1:24 AM

#

gateway status --json shows CLI and daemon config paths match: both ~/.openclaw/openclaw.json. RPC ok. status --all shows agent main with 1 session, active 14m ago, 1 bootstrapping. Model is openrouter/auto. No config path mismatch found. What should I try next for the concrete model test?

wise novaBOT Apr 14, 2026, 1:24 AM

#

Good, that rules out the config-path mismatch.

For the concrete model test, I’d do this in the same thread/session:

Run /model list
Pick any concrete non-auto model from your existing configured set
Switch the session with /model <provider/model>

I’d start with this order:

Option A, best first test: stay on OpenRouter, but switch from openrouter/auto to a specific openrouter/<vendor>/<model>
Option B, stronger isolation: if you also have another provider configured, switch to a direct provider model instead of a router path

Then tail logs:

#

openclaw logs --follow

And send a very explicit probe prompt in the thread, something like:

Do not use web_search.
If any tool name starts with "open-brain__", call one of those tools first.
If no such tool is available, reply exactly: NO_OPEN_BRAIN_MCP_TOOLS

Why this helps:

it removes openrouter/auto routing ambiguity
it makes tool choice binary instead of “maybe I’ll web search instead”
if MCP tools are present, the model should now strongly prefer them

#

A couple of notes:

I would not mix the 1 bootstrapping session into this test yet, unless this exact session is the one stuck bootstrapping
if the concrete-model test still shows no open-brain__* use, then I’d be leaning toward a real 2026.4.12 MCP/runtime bug

If you want current “good tool-using model” picks, ask in #models and check:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you paste what /model list shows for your configured options, I can help you choose the cleanest A/B test without guessing.

arctic zealot Apr 14, 2026, 1:30 AM

#

Solved. The explicit prompt forcing tool use worked. open-brain__search_thoughts is available and returning real results. openrouter/auto was choosing web_search instead. Thanks for the diagnostic path.

wise novaBOT Apr 14, 2026, 1:30 AM

#

Nice, glad we pinned it down 🎉

So the short version was:

mcp.servers was loading correctly
the tools were exposed as open-brain__*
openrouter/auto was just preferring web_search over the MCP tool

That’s a really useful datapoint.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person.

#On 2026.4.12, I registered an external MCP server via openclaw mcp set with transport: streamable-ht