#help

1 messages · Page 1 of 1 (latest)

silver musk
#

is there a way to reset agents md files to default?

naive ibexBOT
#

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

stark jasperBOT
#

Yes. Those “bootstrap” workspace files (including AGENTS.md) are just files in your agent workspace, and OpenClaw can re-seed the defaults if they’re missing.

  1. Find your active workspace:
openclaw config get agents.defaults.workspace
  1. Backup + reset (safe way):
cd "$(openclaw config get agents.defaults.workspace)"
cp AGENTS.md "AGENTS.md.bak.$(date +%Y%m%d-%H%M%S)" 2>/dev/null || true
mv AGENTS.md AGENTS.md.old
openclaw gateway restart

On restart, OpenClaw should recreate missing bootstrap files unless you’ve set:

  • agents.defaults.skipBootstrap: true
silver musk
#

agent is being very unresponsive what md files should I reset to have them to default?

stark jasperBOT
#

If the agent got “weird/unresponsive” because the workspace instructions got mangled, the main one to reset is AGENTS.md (that’s the file that tells it how to behave every session).

If you want a full “back to stock” workspace bootstrap, these are the files to reset (move aside / delete, then restart so OpenClaw re-seeds them):

Reset these to defaults (recommended order):

  • AGENTS.md (most likely to cause unresponsiveness if edited)
  • SOUL.md
  • TOOLS.md
  • USER.md
  • IDENTITY.md
  • HEARTBEAT.md (only affects heartbeat runs)

Special case:

  • BOOTSTRAP.md — if this exists long after setup, move it aside. A leftover BOOTSTRAP.md has been known to keep agents in a perpetual “first run / bootstrapping” vibe.

Usually do NOT reset unless you want to wipe memory:

  • MEMORY.md / memory.md
#
  • memory/ folder

Easiest “nuke it from orbit (but keep a backup)” approach

  1. Find your workspace:
openclaw config get agents.defaults.workspace
  1. Make a fresh workspace and point OpenClaw at it:
openclaw config set agents.defaults.workspace "~/.openclaw/workspace-fresh"
openclaw gateway restart

That gives you a clean default set of workspace files. If it fixes the responsiveness, you can selectively copy back your old USER.md / MEMORY.md from the previous workspace.

If it’s still unresponsive after doing that, paste:

#
  • openclaw --version
  • openclaw gateway status
  • and the last bit of logs: openclaw logs --tail 200
silver musk
#

how to restart to re-seed

stark jasperBOT
#

To re-seed the workspace bootstrap files, you just need to restart the Gateway after you’ve moved/deleted the files you want reset.

If you’re running as a service (most installs)

openclaw gateway restart

(Optional) verify it came back:

openclaw gateway status

If you’re running it in the foreground (you started openclaw gateway in a terminal)

  • Stop it (Ctrl+C)
  • Start it again:
# 
openclaw gateway

If it doesn’t re-seed

Check you didn’t disable seeding:

openclaw config get agents.defaults.skipBootstrap

It should be unset/false. If it’s true:

openclaw config set agents.defaults.skipBootstrap false
openclaw gateway restart
silver musk
#

I rm soul and agents files restarted but files are missing now in workspace

stark jasperBOT
#

Yeah — if you rm’d them, they’ll stay missing until you recreate them (the Gateway won’t always magically regenerate them just because you restarted).

Two quick ways to get back to defaults:

Option A (manual, fastest): copy the stock templates back into your workspace

  1. Get your workspace path:
openclaw config get agents.defaults.workspace
  1. Recreate the files (replace /path/from/above):
WS="/path/from/above"
mkdir -p "$WS"

curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/docs/reference/templates/AGENTS.md -o "$WS/AGENTS.md"
# 
curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/docs/reference/templates/SOUL.md   -o "$WS/SOUL.md"
curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/docs/reference/templates/TOOLS.md  -o "$WS/TOOLS.md"

Then:

openclaw gateway restart

Option B (if you have a git install of the repo locally): cp from the repo

From the repo root:

cp docs/reference/templates/AGENTS.md ~/.openclaw/workspace/AGENTS.md
cp docs/reference/templates/SOUL.md   ~/.openclaw/workspace/SOUL.md
cp docs/reference/templates/TOOLS.md  ~/.openclaw/workspace/TOOLS.md
# 
openclaw gateway restart

If you’re looking at the workspace but the service is using a different one

Run:

openclaw gateway status
openclaw config file

If Config (cli) and Config (service) differ, you’re editing one setup while the service runs another (common cause of “why didn’t it re-seed where I expected?”).

silver musk
#

how to check installed skills

stark jasperBOT
#

Use the skills CLI:

openclaw skills list

If you specifically want “installed + ready to run” (eligible):

openclaw skills list --eligible

For details on one skill:

openclaw skills info <name>
#

And to debug what’s missing (binary/env/config):

openclaw skills check
silver musk
#

how to configure tavily mcp server Remote MCP Server
Connect directly to Tavily's remote MCP server instead of running it locally. This provides a seamless experience without requiring local installation or configuration.

Simply use the remote MCP server URL with your Tavily API key:

https://mcp.tavily.com/mcp/?tavilyApiKey=<your-api-key>
Get your Tavily API key from tavily.com.

Alternatively, you can pass your API key through an Authorization header if the MCP client supports this:

Authorization: Bearer <your-api-key>
Note: When using the remote MCP, you can specify default parameters for all requests by including a DEFAULT_PARAMETERS header containing a JSON object with your desired defaults. Example:

{"include_images":true, "search_depth": "basic", "max_results": 10}

stark jasperBOT
#

OpenClaw doesn’t have a “Tavily MCP” config knob directly — the clean way is to use the bundled mcporter skill/CLI as your MCP client, and add Tavily as an HTTP MCP server there.

0) Install / enable mcporter

  • In Dashboard → Skills: enable mcporter and click Install (or install manually: npm i -g mcporter)
  • Verify:
mcporter --version
openclaw skills list --eligible | rg mcporter

1) Configure Tavily as a remote MCP server in mcporter

I’d avoid putting the API key in the URL (it’ll end up in shell history/config). Prefer the Authorization header.

  1. Export your key (don’t paste it in Discord):
export TAVILY_API_KEY="..."
#
  1. Add the server to your home mcporter config (so it works everywhere):
mcporter config --config ~/.mcporter/mcporter.json add tavily https://mcp.tavily.com/mcp \
  --transport http \
  --header "Authorization: Bearer ${TAVILY_API_KEY}" \
  --header 'DEFAULT_PARAMETERS: {"include_images":true,"search_depth":"basic","max_results":10}'
  1. Sanity-check what tools Tavily exposes:
mcporter list tavily --schema

2) Use it

Once you see the tool names from --schema, call one, e.g.:

# 
mcporter call tavily.<toolName> query="openclaw mcp setup"

If you want OpenClaw to pick up the updated skill/tooling in an existing chat, start a new session (skills are snapshotted per session), or just restart the gateway.

If Authorization: Bearer … doesn’t work with Tavily’s endpoint, tell me what error you get from mcporter list tavily --schema and we’ll switch to the URL ...?tavilyApiKey=... method.

silver musk
#

mcporter list tavily --schema
Unknown MCP server 'tavily'.

#

tavily api key is in env file

stark jasperBOT
#

Unknown MCP server 'tavily' just means mcporter isn’t seeing a config entry named tavily (either it didn’t get written, or mcporter is reading a different config file than you think).

1) First, see what config mcporter is actually using

Run:

mcporter config list

That output usually includes a little summary of which config files it loaded / where entries came from.

Also check if you have this set (it overrides config resolution):

echo "$MCPORTER_CONFIG"

2) Quick fix: force mcporter to use your home config

If you intended to write to ~/.mcporter/mcporter.json, force it temporarily:

# 
export MCPORTER_CONFIG="$HOME/.mcporter/mcporter.json"
mcporter config list
mcporter list tavily --schema

3) Easiest way to add Tavily (no guessing about config add flags): ad-hoc URL + persist

This avoids header flag/version differences.

export TAVILY_API_KEY="..."   # don't paste in Discord

mcporter list --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  --name tavily \
  --schema \
  --persist "$HOME/.mcporter/mcporter.json"
silver musk
#

how do I test tavily?

stark jasperBOT
#

Fastest way: test Tavily ad‑hoc by URL first (no config needed), then persist it once it works.

1) Make sure your key is actually in the env

echo "$TAVILY_API_KEY"

2) See if the Tavily MCP endpoint responds + inspect tools

mcporter list --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  --name tavily \
  --schema

That should print the available tool names + their args.

3) Call one tool (replace <toolName> with what --schema showed)

silver musk
#

there is a lot of tool and schema

#

tavily is responding how to do a quick test

stark jasperBOT
#

If it’s responding, the quickest “smoke test” is: run one search tool call and make sure you get results back.

Quick test (no config, just the remote URL)

# assumes TAVILY_API_KEY is exported in your shell
mcporter call --output json \
  "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}.tavily-search" \
  --args '{"query":"openclaw","search_depth":"basic","max_results":3}'

You should see a JSON response with results/urls.

Quick extract test (optional)

mcporter call --output json \
  "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}.tavily-extract" \
# 
  --args '{"url":"https://docs.openclaw.ai/start/faq"}'

If you already persisted it as a named server (tavily)

mcporter call --output json "tavily.tavily-search" --args '{"query":"openclaw","max_results":3}'

If any of those error, paste the error text only (no key) and I’ll tell you what flag/arg name it’s expecting.

silver musk
#

assumes TAVILY_API_KEY is exported in your shell
mcporter call --output json
"https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}.tavily-search"
--args '{"query":"openclaw","search_depth":"basic","max_results":3}'
[mcporter] Missing tool name. Provide it via <server>.<tool> or --tool.
Error: Missing tool name. Provide it via <server>.<tool> or --tool.
at handleCall (file:///home/ubuntu/.npm-global/lib/node_modules/mcporter/dist/cli/call-command.js:67:19)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async runCli (file:///home/ubuntu/.npm-global/lib/node_modules/mcporter/dist/cli.js:143:13)
at async main (file:///home/ubuntu/.npm-global/lib/node_modules/mcporter/dist/cli.js:201:5)

stark jasperBOT
#

That error is because with --args ... mcporter wants the tool name separately (it didn’t parse the .tavily-search suffix as a tool).

Use the ad‑hoc form: --http-url <server> + <tool>:

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily-search \
  --args '{"query":"openclaw","search_depth":"basic","max_results":3}'

(And for extract:)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
# 
  tavily-extract \
  --args '{"url":"https://docs.openclaw.ai/start/faq"}'

If you want to double-check the exact tool names your endpoint exposes:

mcporter list --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" --schema
silver musk
stark jasperBOT
#

That means the remote Tavily MCP you’re hitting does NOT expose a tool literally named tavily-search (at least not under that exact name).

Next step is to grab the exact tool names from the schema and call one of those.

1) List the tools (this is the source of truth)

mcporter list --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" --schema

Look for the tool names it prints (often they’re something like search / extract / map / crawl, or sometimes underscore versions).

2) Quick try (common tool name is just search)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  search \
# 
  --args '{"query":"openclaw","search_depth":"basic","max_results":3}'

If that still errors, paste the tool list section from the --schema output (it won’t include your key) and I’ll tell you the exact command to run with the correct tool name.

silver musk
#

this is from tavily web page curl -X POST https://api.tavily.com/search
-H 'Content-Type: application/json'
-H 'Authorization: Bearer tvly-dev-*************************************************'
-d '{
"query": "latest ",
"include_answer": "advanced",
"search_depth": "advanced",
"max_results": 20
}'

stark jasperBOT
#

That curl ... https://api.tavily.com/search snippet is Tavily’s REST API, not the MCP server you’re talking to with mcporter.

For Tavily MCP, the equivalent is usually a tool named search (but confirm with --schema).

Do the MCP equivalent of your curl (via mcporter)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  search \
  --args '{"query":"latest","search_depth":"advanced","max_results":20,"include_answer":true}'

If include_answer (or any field) errors, run this and use whatever schema says for types/field names:

mcporter list --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" --schema
#

Also: be really careful posting Tavily keys in Discord — if any real characters leaked (even partially), rotate it.

silver musk
#

function tavily_search(query: string, max_results?: number, search_depth?: "basic" | "advanced" | "fast" | "ultra-fast", topic?: string, time_range?: unknown): object;
// optional (9): include_images, include_image_descriptions, include_raw_content, include_domains, exclude_domains, ...
{
"type": "object",
"properties": {
"query": {
"description": "Search query",
"type": "string"
},
"max_results": {
"default": 5,
"description": "The maximum number of search results to return",
"type": "integer"
},
"search_depth": {
"default": "basic",
"description": "The depth of the search. 'basic' for generic results, 'advanced' for more thorough search, 'fast' for optimized low latency with high relevance, 'ultra-fast' for prioritizing latency above all else",
"enum": [

stark jasperBOT
#

Perfect — that schema snippet shows the tool name is tavily_search (underscore), not tavily-search / search.

So your quick test is:

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily_search \
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

(or without --args, same thing as key/values:)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
# 
  tavily_search query="openclaw" max_results=3 search_depth=basic

If you also see a tavily_extract tool in the schema output, it’ll be the same pattern:
... tavily_extract --args '{"url":"https://..."}'.

silver musk
stark jasperBOT
#

That response (Authentication required) almost always means the API key didn’t actually make it into the request.

Most common cause: TAVILY_API_KEY is not exported (it’s only sitting in a .env file), so your URL effectively becomes ...?tavilyApiKey=.

1) Verify the env var is actually set (don’t paste the key)

test -n "$TAVILY_API_KEY" && echo "TAVILY_API_KEY is set" || echo "TAVILY_API_KEY is MISSING"
echo "length: ${#TAVILY_API_KEY}"

2) If it’s in a .env, load it into your shell then retry

set -a
source .env
set +a
#

3) Retry the call

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily_search \
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

If TAVILY_API_KEY is definitely set (length looks right) and you still get “Authentication required”, then Tavily is rejecting the query-param auth in your case and we should switch to the Authorization header method (I’ll give you the exact mcporter config form for that next).

silver musk
#

test -n "$TAVILY_API_KEY" && echo "TAVILY_API_KEY is set" || echo "TAVILY_API_KEY is MISSING"
echo "length: ${#TAVILY_API_KEY}"
TAVILY_API_KEY is set
length: 3

stark jasperBOT
#

Yep — that explains the auth failure.

length: 3 means your TAVILY_API_KEY env var is basically not the real key (it’s likely literally ... or some redacted placeholder).

A real Tavily key usually starts with tvly- and is way longer than 3 chars.

Fix

  1. Check your .env actually contains the real key (not ...), e.g.:
TAVILY_API_KEY=tvly-xxxxxxxxxxxxxxxxxxxxxxxx

(Don’t paste it here.)

  1. Reload it into your shell:
set -a
# 
source .env
set +a
  1. Sanity check without revealing it:
python - <<'PY'
import os
k=os.environ.get("TAVILY_API_KEY","")
print("len:", len(k))
print("starts_with_tvly:", k.startswith("tvly-"))
PY

Once len looks like a real key (e.g. 30+), re-run the mcporter call and the tavily_search tool should authenticate.

silver musk
#

set -a
source .env
set +a
-bash: .env: No such file or directory

stark jasperBOT
#

You’re just not in the directory that contains that env file.

Two easy paths:

Option A (fastest / safest): set it in the shell without echoing it

read -s -p "TAVILY_API_KEY: " TAVILY_API_KEY
echo
export TAVILY_API_KEY
echo "len: ${#TAVILY_API_KEY}"

Then rerun your mcporter call ....

Option B: source the env file by full path

If you know where the file is, do:

# 
set -a
source /full/path/to/your.env
set +a

If you don’t know where it is, run this to locate it:

rg -n "TAVILY_API_KEY" ~ --hidden 2>/dev/null | head

(That will print the filename(s) containing it—no need to paste the key itself.)

silver musk
#

~/.openclaw/.env

stark jasperBOT
#

Cool — then load it into your current shell like this:

set -a
source ~/.openclaw/.env
set +a

echo "len: ${#TAVILY_API_KEY}"

Then retry the MCP call:

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily_search \
# 
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

If len still looks tiny, open ~/.openclaw/.env and confirm it contains the real Tavily key value (not ... / redacted).

silver musk
stark jasperBOT
#

Nice — auth is working now. That error is just because you called tavily_search without the required query argument.

Try one of these:

Key/value style (easy to type)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily_search \
  query="openclaw" max_results=3 search_depth=basic

JSON args style

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
# 
  tavily_search \
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

You should get a normal results payload back.

silver musk
#

now is working tell me how to ask the agent

stark jasperBOT
#

If Tavily works from mcporter, you can now just tell your OpenClaw agent to use the mcporter skill to run tavily_search.

Checklist so it actually works inside the agent:

  1. Make sure the Gateway can see the key (since you’re using the service):
  • Put the real key in ~/.openclaw/.env (that file is auto-loaded by OpenClaw)
  • Restart:
openclaw gateway restart
  1. Make sure the mcporter skill is eligible (mcporter binary installed):
openclaw skills list --eligible | rg mcporter
  1. Start a new chat session (skills are snapshotted per session):
#
  • in chat: /new

Then ask the agent something like:

“Use mcporter to call Tavily MCP (tavily_search) with: query=openclaw, search_depth=basic, max_results=3. Summarize the results and include the source URLs.”

If you want to be extra explicit, you can paste the exact command you already tested and say “run this via mcporter and summarize the JSON output”.

silver musk
#

The mcporter calls are timing out. Let me check if the TAVILY_API_KEY is set
and try a different approach:
The mcporter command couldn't
run because TAVILY_API_KEY is not set in the environment.

The subagent checked:

• .bashrc — not found
• .profile — not found
• .env — not found
• No tavily-search skill configured

To fix this, you'll need to set the TAVILY_API_KEY environment variable. You can do this by:

Bash


export TAVILY_API_KEY="your-api-key-here"

Or add it to your .bashrc/.env file. Once set, I can run the mcporter command again.

Do you have a Tavily API key? Or should I just use the web fetch method I used earlier (which worked fine)?
NO
_REPLY

stark jasperBOT
#

What your agent is telling you is basically: it ran mcporter in a context where TAVILY_API_KEY isn’t available.

Two key OpenClaw gotchas here:

  1. OpenClaw does load ~/.openclaw/.env into the Gateway environment (good).
  2. But if you have sandboxing enabled, tool execution happens inside the Docker sandbox, and the sandbox does not inherit the host env by default. So exec/mcporter won’t see TAVILY_API_KEY unless you pass it into the sandbox.

Fix option A (recommended while debugging): turn sandboxing off

openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart

Then /new and try asking the agent again.

Fix option B (keep sandboxing): inject the key into the sandbox env

Add TAVILY_API_KEY to:
agents.defaults.sandbox.docker.env

#

Example (you’ll need to put the real key value there; don’t paste it in Discord):

openclaw config set agents.defaults.sandbox.docker.env.TAVILY_API_KEY "tvly-..."
openclaw gateway restart

After either change, start a new session (/new) so the agent picks up the new environment and skill snapshot.

If you run openclaw config get agents.defaults.sandbox.mode I can tell you which path you’re currently on.

silver musk
#

openclaw config get agents.defaults.sandbox.mode

🦞 OpenClaw 2026.3.11 (29dc654) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Config path not found: agents.defaults.sandbox.mode dont have sandbox

stark jasperBOT
#

That Config path not found: agents.defaults.sandbox.mode message usually just means you haven’t set that key in your config yet, not that sandboxing “doesn’t exist”.

Two things to do:

1) Check whether you’re actually sandboxed

This is the source of truth:

openclaw sandbox explain

If it says sandbox is on for your Discord session, then your tools may be running inside Docker and won’t see host env vars unless you pass them via agents.defaults.sandbox.docker.env.

2) Fix the Tavily key for the agent (most likely missing because the Gateway hasn’t loaded it)

OpenClaw loads ~/.openclaw/.env only on gateway start, so after adding TAVILY_API_KEY there you must:

openclaw gateway restart

Then in chat do /new and ask again.

#

If openclaw sandbox explain shows sandbox is enabled, tell me what it prints for mode and I’ll tell you whether to:

  • turn sandbox off, or
  • set agents.defaults.sandbox.docker.env.TAVILY_API_KEY so mcporter inside the container can see it.
silver musk
#

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /home/ubuntu/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage, line

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

  • tools.sandbox.tools.allow
  • tools.sandbox.tools.deny
  • agents.list[].tools.sandbox.tools.allow
  • agents.list[].tools.sandbox.tools.deny
  • tools.elevated.enabled

Docs: docs.openclaw.ai/sandbox

stark jasperBOT
#

Great — that output means you are not sandboxed:

  • runtime: direct
  • mode: off

So the earlier “can’t find .bashrc/.env” stuff from the agent is basically a red herring — what matters is: does the Gateway process have TAVILY_API_KEY in its environment when it runs mcporter?

Most common reasons it doesn’t:

  1. Gateway wasn’t restarted after you added the key to ~/.openclaw/.env
openclaw gateway restart
  1. The service is running under a different state dir/profile (so it’s reading a different .env)
    Run these and compare:
# 
openclaw gateway status
openclaw config file

If gateway status shows Config (cli) vs Config (service) mismatch → reinstall the service from the environment you want:

openclaw gateway install --force
openclaw gateway restart

Quick “don’t leak the key” verification

Ask your agent to run a length check (not echo):

python -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'

If it prints 0, the agent won’t be able to use Tavily yet; if it prints a normal length (30+), you’re good and any remaining issue is just the mcporter command/timeouts.

silver musk
#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-12.log
Command: /usr/bin/node /home/ubuntu/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled. (Run openclaw gateway install --force to remove embedded service token.)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 613798, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789

#

python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'
58

stark jasperBOT
#

That status output is super helpful — your Gateway is healthy (RPC probe: ok), but the important bit is this:

“Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled.”

Do this first (it fixes a bunch of “service env is weird / stale” problems):

openclaw gateway install --force
openclaw gateway restart

Then re-check:

openclaw gateway status
#

After that, for Tavily specifically:

  1. Make sure the key is in the gateway host fallback env file:
  • ~/.openclaw/.env should contain TAVILY_API_KEY=tvly-...
  1. Restart once more so the service picks it up:
openclaw gateway restart
  1. In chat, /new, then ask the agent to run the non-leaky check:
python -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'

If that prints 0 even after the reinstall + restart, run openclaw doctor (it’ll usually call out why env loading isn’t happening).

#

58 is perfect — that’s a real key and it’s loaded in that shell.

Now try it end-to-end the same way your agent will use it:

Quick local smoke test (should return results)

mcporter call --output json \
  --http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
  tavily_search \
  query="openclaw" max_results=3 search_depth=basic

Then ask your OpenClaw agent

In chat (start a fresh session with /new), send something like:

“Use the mcporter skill to run Tavily MCP tavily_search with query="openclaw", max_results=3, search_depth="basic". Summarize results + include URLs.”

#

If it still claims the env var is missing, have the agent run (via exec) a non-leaky check:

python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'
silver musk
#

58

#

the agent leaked the key in telegram

stark jasperBOT
#

Perfect — 58 means the agent runtime can see TAVILY_API_KEY now.

Next step: just have it run the actual Tavily MCP call. In chat:

  1. /new (so skills/env snapshot refreshes)
  2. Send:

“Use mcporter to call Tavily MCP tavily_search with query="openclaw", max_results=3, search_depth="basic". Summarize + include URLs.”

If it still fails, paste the exact mcporter error/output (no keys) and we’ll tune the command/timeout.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

silver musk
#

The subagent couldn't execute
the mcporter command — my toolset doesn't include shell/exec capabilities.

Issues encountered:

  1. No exec tool - Can't run mcporter CLI commands
  2. web_search is rate-limited (429 quota exceeded)
  3. Tavily API key - The dev key (tvly-dev-...) appears to be for the MCP server, not the direct REST API (got 401 when testing)

To run that command, you'd need to execute it directly in your terminal:

Bash


mcporter call --output json
--http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}"
tavily_search
--args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

Want me to help with something else, or do you have exec access configured that I could use?

stark jasperBOT
#

Rotate it immediately and assume it’s compromised.

1) Revoke/rotate the Tavily key

  • Go to Tavily dashboard (API keys) and revoke the leaked key.
  • Create a new key.

2) Update your OpenClaw host

Update wherever you stored it (sounds like ~/.openclaw/.env):

nano ~/.openclaw/.env   # or your editor
# update TAVILY_API_KEY=...
openclaw gateway restart

Also update any mcporter configs if you persisted the key anywhere (ideally you didn’t).

#

3) Delete the Telegram message

In Telegram, delete the message for everyone (if possible). If it was posted into a group/channel, treat it as fully leaked even if you delete it (clients may have cached it).

4) Prevent this happening again

  • Add a hard rule to your AGENTS.md like: never print env vars / tokens / API keys (no echo $FOO), only allow “length checks”.
  • When debugging, use:
    python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'
    not echo $TAVILY_API_KEY.

If you tell me whether the leak was in a Telegram DM vs group, I can tell you how paranoid to be (DM still rotate; group = rotate + assume used).

silver musk
#

focus on solving this The subagent couldn't execute
the mcporter command — my toolset doesn't include shell/exec capabilities.

Issues encountered:

  1. No exec tool - Can't run mcporter CLI commands
  2. web_search is rate-limited (429 quota exceeded)
  3. Tavily API key - The dev key (tvly-dev-...) appears to be for the MCP server, not the direct REST API (got 401 when testing)

To run that command, you'd need to execute it directly in your terminal:

Bash


mcporter call --output json
--http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}"
tavily_search
--args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

Want me to help with something else, or do you have exec access configured that I could use?

#

already revoked the key

stark jasperBOT
#

That message is coming from a spawned sub-agent, and sub-agents can have a different (more restricted) tool allowlist than your main agent.

You’ve got two options:

Option A (simplest): tell it not to use a sub-agent

In your chat prompt, be explicit:

“Don’t spawn a subagent. Run the mcporter command directly using exec and summarize the results.”

Option B: allow exec for sub-agents (config)

Enable runtime tools for subagents:

openclaw config set tools.subagents.tools.allow '["group:runtime"]' --strict-json
openclaw gateway restart
#

Then /new and retry.

If you want me to be precise about what you currently have set, paste these outputs:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.subagents.tools.allow
silver musk
#

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.subagents.tools.allow

🦞 OpenClaw 2026.3.11 (29dc654) — If you can describe it, I can probably automate it—or at least make it funnier.

coding

🦞 OpenClaw 2026.3.11 (29dc654) — Type the command with confidence—nature will provide the stack trace if needed.

Config path not found: tools.allow

🦞 OpenClaw 2026.3.11 (29dc654) — No $999 stand required.

Config path not found: tools.subagents.tools.allow

stark jasperBOT
#

Your problem is #1: the spawned sub-agent has no exec tool, so it can’t run mcporter. Fix that, and the Tavily MCP flow works (and you can ignore web_search 429 entirely).

Step 1) Give sub-agents exec (and process) via tool policy

Run:

openclaw config set tools.subagents.tools.allow '["group:runtime"]' --strict-json
openclaw gateway restart

(group:runtime = exec + process per the config reference.)

Step 2) Verify the sub-agent can actually exec

Ask your bot to run something dead simple:

“Don’t answer in prose. Run mcporter --version via exec and paste stdout.”

#

If that works, then your original Tavily call will work from the agent too.

If it STILL says “no exec tool”

Then your global tool profile is probably restricting tools so hard that even adding subagent allow doesn’t help. Check:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny

If tools.profile is minimal or messaging, switch to coding:

openclaw config set tools.profile coding
openclaw gateway restart
#

After that, retry the agent prompt.

(And yeah: the tvly-dev-... key is fine for the MCP server; the REST 401 is a separate issue—don’t chase it until exec works.)

silver musk
#

I don't have an exec tool available
in my current toolset. The subagent also failed to run it.

Could you run mcporter --version in your terminal and paste the output here? Alternatively, if there's a different way you'd like me to check the version, let me know.
The subagent ran the command but the actual version output wasn't captured in the result. Could
you run mcporter --version in your terminal and share what it outputs? Or if you have direct access, let me know what version you're running.

#

— Your personal assistant, minus the passive-aggressive calendar reminders.

coding

🦞 OpenClaw 2026.3.11 (29dc654) — Finally, a use for that always-on Mac Mini under your desk.

Config path not found: tools.allow

🦞 OpenClaw 2026.3.11 (29dc654) — Automation with claws: minimal fuss, maximal pinch.

stark jasperBOT
#

Good — that was the right move.

Next steps (so you’re back to a working setup and it doesn’t happen again):

1) Generate a new key + update everywhere

  • Create a new Tavily key
  • Replace it in ~/.openclaw/.env (and anywhere else you saved it, like mcporter config)

Then restart so the Gateway picks it up:

openclaw gateway restart

2) Delete the leaked Telegram message (if you haven’t)

Even revoked, it’s still best practice to delete it.

3) Prevent future leaks

#

Add a hard rule to your AGENTS.md like:

  • Never print env vars / tokens / API keys
  • Never run echo $TAVILY_API_KEY or paste commands that expand secrets
  • Only do “length checks” when debugging

4) (Optional but recommended) Switch to OAuth for Tavily MCP

If you use OAuth, there’s no long-lived API key to leak in chat. Tavily’s remote MCP supports it; mcporter can usually do:

mcporter auth https://mcp.tavily.com/mcp/

When you’ve got the new key in place, we can go back to the original “subagent has no exec tool” fix and get the agent running Tavily searches reliably.

#

Good, this confirms your main agent is on the coding tool profile:

  • tools.profile = coding
  • tools.allow is unset (fine)
  • tools.subagents.tools.allow is unset (this is the missing piece)

In OpenClaw, spawned sub-agents can have their own tool policy, and by default they often don’t get exec unless you explicitly allow it.

Fix: allow exec for sub-agents

Run:

openclaw config set tools.subagents.tools.allow '["group:runtime"]' --strict-json
openclaw gateway restart

Then start a new chat session (/new) and retry the same request that previously spawned the subagent.

#

If you want the subagent to also be able to web_fetch (optional)

(doesn’t fix Tavily, but useful generally)

openclaw config set tools.subagents.tools.allow '["group:runtime","group:web"]' --strict-json
openclaw gateway restart

After this, the “subagent has no exec tool” error should go away and it can run mcporter itself.

#

If your config says tools.profile = coding, then exec should exist (coding includes group:runtime = exec + process). So when the agent says “I don’t have an exec tool”, it usually means something is overriding tool availability (most commonly tools.byProvider, tools.deny, or per‑agent tool overrides).

Do this in order:

1) Make sub-agents explicitly allowed to use exec

Even if the main agent can, subagents may be restricted by default:

openclaw config set tools.subagents.tools.allow '["group:runtime"]' --strict-json
openclaw gateway restart

Then /new and retry.

2) Check for overrides that remove exec

Run and paste outputs:

# 
openclaw config get tools.deny
openclaw config get tools.byProvider
openclaw config get agents.list
  • If tools.deny includes exec/group:runtime → remove that deny.
  • If tools.byProvider has an entry for your current model/provider setting a minimal profile → that will drop exec even though global profile is coding.
  • If your agent entry under agents.list[] has a restrictive tools block, that can also drop exec.

3) (Quick workaround) tell the agent not to spawn subagents

While you’re fixing config, you can still get work done by prompting:

“Do not spawn a subagent. Use exec directly to run mcporter.”

If you paste those 3 config outputs, I’ll tell you exactly which line is killing exec and the minimal openclaw config set/unset … to restore it.

silver musk
#

Making 'I'll automate that later' happen now.

Config path not found: tools.deny

🦞 OpenClaw 2026.3.11 (29dc654) — If it works, it's automation; if it breaks, it's a "learning opportunity."

Config path not found: tools.byProvider

🦞 OpenClaw 2026.3.11 (29dc654) — If it works, it's automation; if it breaks, it's a "learning opportunity."

[
{
"id": "main",
"subagents": {
"allowAgents": [
"trader",
"code"
]
},
"tools": {
"profile": "full",
"deny": [
"group:runtime"
]
}
},
{
"id": "trader",
"name": "trader",
"workspace": "/home/ubuntu/.openclaw/agents/trader",
"agentDir": "/home/ubuntu/.openclaw/agents/trader/agent"
},
{
"id": "code",
"name": "code",
"workspace": "/home/ubuntu/.openclaw/workspace-code",
"agentDir": "/home/ubuntu/.openclaw/agents/code/agent",
"tools": {
"profile": "coding",
"alsoAllow": [
"browser"
],
"exec": {
"host": "gateway",
"security": "allowlist",
"ask": "off"
}
}
}
]

stark jasperBOT
#

Got it — so far we only know:

  • tools.profile = coding âś… (should include exec)
  • tools.allow is unset âś… (fine)

Next we need to check the two places that commonly remove exec even when profile is coding:

1) Is exec explicitly denied?

Run:

openclaw config get tools.deny

2) Is there a provider/model override forcing a minimal tool profile?

Run:

# 
openclaw config get tools.byProvider

3) Are there per-agent tool overrides?

Run:

openclaw config get agents.list

And separately, if you want spawned subagents to have exec, set it explicitly (since tools.subagents.tools.allow is currently unset on your config):

openclaw config set tools.subagents.tools.allow '["group:runtime"]' --strict-json
openclaw gateway restart
openclaw config get tools.subagents.tools.allow
#

Paste the outputs of tools.deny / tools.byProvider / agents.list and we can point to the exact line that’s stripping exec.

#

Found the smoking gun in your agents.list output:

Your main agent has this:

tools: {
  profile: "full",
  deny: ["group:runtime"]
}

group:runtime is exactly exec + process, so you’ve explicitly disabled shell/exec for the main agent. That’s why both the agent and the subagent keep saying “no exec tool”.

Fix (recommended): put main back on the normal coding tool profile

This gives you exec again without going “full tools”:

# 
openclaw config set agents.list[0].tools.profile coding
openclaw config unset agents.list[0].tools.deny
openclaw gateway restart

(Alternative if you really want to keep profile: "full": just set the deny list to empty:
openclaw config set agents.list[0].tools.deny '[]' --strict-json.)

Verify

After restart, /new, then ask the agent to run:

  • mcporter --version
  • then your Tavily MCP call

That should eliminate the “no exec tool” problem entirely.

silver musk
#

mcporter --versionwas denied — need approval to run it. Want me to request/allow mcporter --version`?

stark jasperBOT
#

That’s exec approvals kicking in.

On Linux/systemd you usually don’t have a popup UI to approve, so anything in exec.security: "allowlist" that isn’t already allowlisted gets denied.

Fix = allowlist the mcporter binary for your agent.

1) Find the mcporter path

command -v mcporter

2) Add it to the exec allowlist (for the main agent)

openclaw approvals allowlist add --agent main "$(command -v mcporter)"

(If you want it usable by any agent, use --agent "*".)

#

3) Retry in chat

Now mcporter --version (and your mcporter call ...) should run without the approval denial.

If you want to sanity-check your current approvals config:

openclaw approvals get
silver musk
#

now mcporter is working

stark jasperBOT
#

Nice — that means you’re through the whole chain:

  • tool policy fixed (main agent no longer denies group:runtime)
  • exec approvals fixed (mcporter binary allowlisted)
  • Tavily MCP tool name is tavily_search (underscore)
  • key should live in ~/.openclaw/.env + restart gateway after changes

Two quick “don’t get burned again” tips:

  • Add a hard rule to your AGENTS.md: never print env vars / API keys (no echo $TAVILY_API_KEY, only length checks).
  • Consider switching Tavily MCP to OAuth later so there’s no API key to leak.

If this solved your original issue, please right‑click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

silver musk
#

run this via mcporter and summarize json : mcporter call --output json \
--http-url "https://mcp.tavily.com/mcp/?tavilyApiKey=${TAVILY_API_KEY}" \
tavily_search \
--args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'
Error: Authentication required — no TAVILY_API_KEY available or it's invalid.

stark jasperBOT
#

That error is happening because the exec tool isn’t guaranteed to run your command through a shell, so the literal string ${TAVILY_API_KEY} can end up getting passed to mcporter unchanged. Tavily then sees an invalid/empty key → “Authentication required”.

Also, since you revoked the old key, if you haven’t put the new one into ~/.openclaw/.env + restarted, it’ll fail too.

Best fix: don’t put the key in the URL at all (avoid leaks + avoid shell expansion)

Configure Tavily once in mcporter using an Authorization header that mcporter expands itself:

mcporter config --config ~/.mcporter/mcporter.json add tavily https://mcp.tavily.com/mcp/ \
  --transport http \
  --header "Authorization: Bearer ${TAVILY_API_KEY}"

Then your agent can run this (no secrets in the command line):

# 
mcporter call --output json tavily.tavily_search \
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

Make sure the new key is actually loaded by OpenClaw

  1. Put the new key in ~/.openclaw/.env (TAVILY_API_KEY=...)
  2. Restart:
openclaw gateway restart

After that, ask the agent to run the tavily.tavily_search version (not the tavilyApiKey=${...} URL form) and summarize the returned JSON.

silver musk
#

mcporter config --config ~/.mcporter/mcporter.json add tavily https://mcp.tavily.com/mcp/
--transport http
--header "Authorization: Bearer ${TAVILY_API_KEY}"
[mcporter] --header requires KEY=value.

stark jasperBOT
#

Yep — mcporter wants headers as KEY=value (not KEY: value).

Use this:

mcporter config --config ~/.mcporter/mcporter.json add tavily https://mcp.tavily.com/mcp/ \
  --transport http \
  --header 'Authorization=Bearer ${TAVILY_API_KEY}'

Important detail: use single quotes so your shell does not expand ${TAVILY_API_KEY} and accidentally write the raw key into the config file. mcporter will substitute it at runtime.

(Optional defaults header, same format):

mcporter config --config ~/.mcporter/mcporter.json add tavily https://mcp.tavily.com/mcp/ \
  --transport http \
# 
  --header 'Authorization=Bearer ${TAVILY_API_KEY}' \
  --header 'DEFAULT_PARAMETERS={"include_images":true,"search_depth":"basic","max_results":10}'

Then test (no key in URL):

mcporter call --output json tavily.tavily_search --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'
silver musk
#

mcporter call --output json tavily.tavily_search --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'
{
"error": "Search failed",
"status": 401,
"detail": {
"detail": {
"error": "Unauthorized: missing or invalid API key."
}
}
}

stark jasperBOT
#

That 401 means Tavily still isn’t receiving a valid key — in this setup it’s almost always because TAVILY_API_KEY in your current shell is empty or still the revoked key.

Remember: mcporter is now reading the key from your environment at runtime, not from the URL.

1) Reload the key into this terminal (from your OpenClaw env file)

set -a
source ~/.openclaw/.env
set +a

python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'

Make sure that length looks like a real key (30+).

2) Retry

# 
mcporter call --output json tavily.tavily_search \
  --args '{"query":"openclaw","max_results":3,"search_depth":"basic"}'

If it still 401s

Run:

mcporter config get tavily

and check that the header is present as Authorization=Bearer ${TAVILY_API_KEY} (no typo like Authorization=Bearer${...}).

Also: after rotating keys, don’t forget to update ~/.openclaw/.env and openclaw gateway restart so the agent sees the new key too.

silver musk
#

working on vps

stark jasperBOT
#

Ah — if OpenClaw/mcporter is running on the VPS, then your laptop’s env doesn’t matter at all. The key + mcporter config must exist on the VPS host (the machine running the Gateway / exec).

On the VPS:

  1. Confirm the key is present there:
python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'
  1. If it’s only in ~/.openclaw/.env, load it for your current SSH shell (for manual testing):
set -a
source ~/.openclaw/.env
set +a
python3 -c 'import os; print(len(os.getenv("TAVILY_API_KEY","")))'