#mcporter not found

24 messages · Page 1 of 1 (latest)

frozen hedge
#

I have enabled the built-in mcporter skill in onboarding. when i attempt to run the skill in a (non-sandboxed) agent, it fails saying the mcporter executable cannot be found, which makes me think mcporter is not in my $PATH. However, mcporter is in my $PATH. (in ~/.npm-global/bin/mcporter)

sharp pulsarBOT
#

Let me check the docs/source paths that actually exist and zero in on the mcporter wiring.

#

Yep, this sounds like gateway/service PATH drift, not your interactive shell PATH.

The mcporter skill declares requires.bins: ["mcporter"], and OpenClaw checks that against the gateway process PATH. So mcporter existing in ~/.npm-global/bin is not enough if the gateway/agent runtime does not see that dir.

A couple important bits:

  • Recent Linux builds explicitly add common user bin dirs, including ~/.npm-global/bin, to the service PATH.
  • So the first thing I need is:
openclaw --version
openclaw gateway status
openclaw doctor

If you're on an older build, I'd expect exactly this behavior.

#

What I'd try next:

  1. Update OpenClaw
  2. Run:
    openclaw doctor --repair
openclaw gateway restart
  3. Try the skill again

If it still fails after that, please paste:

  • openclaw --version
  • the output of openclaw gateway status
  • the exact error line from openclaw logs --follow

Docs:

frozen hedge
#

OpenClaw 2026.4.14 (323493f)

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-15.log
Command: /usr/bin/node /home/ocuser/.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

I also added OPENCLAW_LOAD_SHELL_ENV=1 to ~/.openclaw/.env and restarted the gateway, still no luck.

#

that said, in ~/.config/systemd/user/openclaw-gateway.service /home/ocuser/.npm-global/bin is included in the PATH env var.

frozen hedge
#

openclaw logs --follow doesn't show the error at all. i can see the tool attempts in the web UI, and all of them still say "tool not found."

sharp pulsarBOT
#

Ah, that changes the diagnosis.

If the Web UI says “tool not found” and the gateway logs never show a shell/exec failure, then this is probably not a PATH problem at all. I’m checking the skill docs to confirm the mcporter skill is prompt-only and expects the model to use exec, not a literal mcporter tool.

#

Yep, that’s a different failure class. If the UI says “tool not found” and the gateway logs never show an exec/spawn error, then the agent is not reaching the shell at all.

What that usually means here:

  • The mcporter skill is not a real tool
  • It’s a skill prompt that teaches the model to use the exec tool to run the mcporter CLI
  • So the model is probably trying to call a nonexistent tool named mcporter instead of calling exec

That also explains why PATH changes didn’t matter, and why logs stay quiet.

Two quick checks:

  1. Does that agent/session actually have exec available?
    If exec is missing, the skill can’t work.

  2. Try prompting it very explicitly, like:

    Use the exec tool, not a tool named mcporter. Run command -v mcporter && mcporter --version.

#

If it still tries to call a literal mcporter tool, then this is likely a model/tool-following issue, not a PATH issue.

If you want, paste:

  • the exact tool name it attempted in the UI
  • whether exec is listed for that session
  • which provider/model family that agent is using

If exec is present and it still reproducibly invents mcporter as a tool, I’d call that a legit bug / skill-prompt issue and file it here: https://github.com/openclaw/openclaw/issues

Docs:

frozen hedge
#

command -v mcporter && mcporter --version worked successfully. of note, it had me approve the tool call, but it did in fact work.

sharp pulsarBOT
#

Perfect, that proves it.

  • mcporter is on PATH
  • exec can run it
  • the approval prompt was expected for exec

So this is not a PATH/systemd problem after all. The real issue is that the agent/model is sometimes trying to call a nonexistent mcporter tool instead of using the real exec tool to run the mcporter binary.

Short version: the skill is loading, but the model is using it wrong.

Workarounds:

  • Prompt it explicitly with something like:

    Use the exec tool to run mcporter. Do not call a tool named mcporter.

  • If it still does mcporter as a fake tool call, that points to a model/tool-following issue or a bundled-skill prompt that needs to be more explicit.

frozen hedge
#

what should the agent config look like to allow this without confirmations?

sharp pulsarBOT
#

I’m checking the exact exec approval config keys so I don’t hand you made-up JSON5. The safest answer here is probably a narrow allowlist for mcporter, not turning confirmations off globally.

#

I’d use the narrow option, not full YOLO.

Recommended: allow only mcporter, no prompt

Agent config:

{
  agents: {
    list: [
      {
        id: "your-agent-id",
        tools: {
          exec: {
            host: "gateway",
            security: "allowlist",
# 
            ask: "off",
          },
        },
      },
    ],
  },
}

Then add the actual binary path to the gateway host approvals allowlist for that agent:

openclaw approvals allowlist add --agent your-agent-id "/home/ocuser/.npm-global/bin/mcporter"

If you’re targeting the gateway remotely, use --gateway.

#

If that agent is using a node host, use --node <id|name|ip> instead, and mcporter must exist on that node.

If you really want zero confirmations for any exec on that agent

Use:

{
  agents: {
    list: [
      {
        id: "your-agent-id",
        tools: {
          exec: {
            host: "gateway",
            security: "full",
# 
            ask: "off",
          },
        },
      },
    ],
  },
}

But one important gotcha: agent config alone does not override a stricter host approvals file.
If the host approvals are still stricter, you’ll still get prompts. For full no-prompt behavior on the local gateway host, align the host policy too:

openclaw exec-policy preset yolo
frozen hedge
#

sure gimme the commands. Agent ID is "mcptalker"

sharp pulsarBOT
#

Yep, here’s the recommended narrow setup for mcptalker.

First, find the array index for that agent in agents.list:

openclaw config get agents.list --json

Then replace <IDX> below with the index for the entry whose id is mcptalker:

openclaw config set agents.list[<IDX>].tools.exec.host gateway
openclaw config set agents.list[<IDX>].tools.exec.security allowlist
openclaw config set agents.list[<IDX>].tools.exec.ask off

Allow just the mcporter binary for that agent:

# 
openclaw approvals allowlist add --agent mcptalker "/home/ocuser/.npm-global/bin/mcporter"

Then restart:

openclaw gateway restart

If you’re running the CLI from a different machine than the gateway host, use:

openclaw approvals allowlist add --gateway --agent mcptalker "/home/ocuser/.npm-global/bin/mcporter"

One small gotcha: if it still prompts after this, your host approvals are probably stricter than the agent config. In that case, paste: