Connect Pixelixe to OpenClaw

On this page

Before you start Why this is different Setup steps Local and remote modes First test Optional skill layer Troubleshooting References

Other platforms

ChatGPT Claude n8n Make Zapier

Before you start

OpenClaw is not documented like ChatGPT, Claude, or Make. Its public docs center on a self-hosted Gateway, a Control UI, a skills system, and an ACP bridge that other ACP-capable clients can talk to.

  • The main runtime is the OpenClaw Gateway, which listens on port 18789 by default.
  • openclaw acp is the official ACP bridge. It speaks ACP over stdio and forwards requests to the Gateway over WebSocket.
  • The public docs clearly document Gateway setup, remote access, ACP bridge usage, and skills. They do not currently provide a copy-paste third-party remote MCP example comparable to the ChatGPT or Claude UI guides.
Key official limitation from OpenClaw
The openclaw acp docs explicitly say that per-session mcpServers are unsupported in ACP bridge mode. If you want Pixelixe available to OpenClaw, configure it at the OpenClaw gateway or agent layer instead of trying to inject it from an ACP client session.

Why this guide is different

  • ChatGPT, Claude, and Make document end-user connector or MCP setup surfaces directly in their UI flows.
  • OpenClaw's official docs instead document: install and onboarding, the Gateway and Control UI, the ACP bridge, and the skills system.
  • OpenClaw's ACP docs explicitly reject per-session mcpServers, so a Pixelixe setup for OpenClaw should not be described as “paste this server URL into the ACP client session.”

That is why this page focuses on the documented OpenClaw runtime model first, then on how to make Pixelixe usable in that model.

Setup steps

  1. Install OpenClaw.
curl -fsSL https://openclaw.ai/install.sh | bash
  1. Run the official onboarding flow so OpenClaw configures the Gateway and provider auth.
openclaw onboard --install-daemon
  1. Verify that the Gateway is alive, then open the Control UI.
openclaw gateway status
openclaw dashboard
  1. If you want an ACP-capable editor or client to drive OpenClaw, point that client at openclaw acp. For a remote Gateway, the official docs show either persistent config or direct flags.
openclaw config set gateway.remote.url wss://gateway-host:18789
openclaw config set gateway.remote.token <gateway-token>

# or run directly without writing config
openclaw acp --url wss://gateway-host:18789 --token-file ~/.openclaw/gateway.token
  1. Do not try to pass Pixelixe through ACP session payloads. The documented ACP bridge rejects per-session mcpServers.
  2. Make Pixelixe available where your OpenClaw install defines long-lived agent tooling, then use the normal Pixelixe MCP endpoint https://studio.pixelixe.com/api/mcp/v1.
  3. Start a fresh OpenClaw session before testing so the session picks up the current tool surface.
Documented vs inferred
The install, Gateway, remote access, ACP bridge, and skills behavior above are documented directly by OpenClaw. The exact place where you register a third-party MCP server depends on how your OpenClaw deployment defines long-lived tools for the agent runtime. Because the public docs do not currently publish a dedicated “add this remote MCP server” example, this page deliberately avoids inventing a fake connector screen that does not exist in the docs.

Local and remote modes

OpenClaw's official docs distinguish the Gateway host from the client that talks to it. That matters for Pixelixe because the Gateway host is the trust boundary and the place where long-lived config and secrets live.

  • Local Gateway: OpenClaw runs on the same machine you are using. The fastest path is openclaw onboard --install-daemon, then openclaw dashboard and openclaw acp locally.
  • Remote Gateway over SSH: OpenClaw docs recommend keeping the Gateway loopback-only and reaching it through SSH or a tailnet. If you use a remote host, connect the ACP bridge or the app to that Gateway rather than moving secrets into chat prompts.
  • Remote Gateway direct ws/wss: OpenClaw also documents direct remote Gateway URLs with token auth. If you use that mode, keep Gateway auth enabled and avoid exposing an unauthenticated public endpoint.
# Built-in ACP debug client
openclaw acp client

# Debug against a remote Gateway
openclaw acp client --server-args --url wss://gateway-host:18789 --token-file ~/.openclaw/gateway.token

First test

Start with a read-only Pixelixe request so you confirm the OpenClaw runtime can discover Pixelixe tools before trying image generation.

Use the Pixelixe connector only. First call pixelixe_get_tool_docs for pixelixe_search_documents, then search my saved documents and summarize the results in plain language.

That validates the tool surface and response formatting without consuming generation credits yet.

Optional skill layer

OpenClaw officially documents a skills system and ClawHub registry. If you want the agent to use Pixelixe more reliably, keep the Pixelixe usage guidance in a workspace or managed skill after the MCP side is configured.

  • Workspace skills live under <workspace>/skills.
  • Managed/shared skills live under ~/.openclaw/skills.
  • ClawHub is the documented registry for installing and updating skills.
  • OpenClaw also documents a secure per-skill secret surface in ~/.openclaw/openclaw.json via skills.entries.<skillKey>.apiKey and skills.entries.<skillKey>.env, which keeps secrets out of prompts.
{
  "skills": {
    "entries": {
      "pixelixe-helper": {
        "enabled": true,
        "apiKey": "YOUR_PIXELIXE_API_KEY",
        "env": {
          "PIXELIXE_API_KEY": "YOUR_PIXELIXE_API_KEY"
        }
      }
    }
  }
}

That secret pattern is documented by OpenClaw for skills. It is useful when you keep Pixelixe usage instructions or helper scripts in a skill, even though the Pixelixe MCP endpoint itself remains the main integration surface.

Troubleshooting

  • If you are testing through openclaw acp, remember that per-session mcpServers are officially unsupported in bridge mode. Move the Pixelixe configuration to the Gateway or agent layer.
  • If a fresh OpenClaw session still does not see Pixelixe tools, restart the Gateway after changing its config or MCP-related setup.
  • If Pixelixe was added but the agent still does not reach for it naturally, put the Pixelixe guidance into a documented OpenClaw skill rather than repeating it manually in every chat.
  • If you only need to sanity-check the bridge itself, OpenClaw documents openclaw acp client as a built-in debug path.

Official references used for this page