OpenClaw connects to Graft over streamable HTTP with a static bearer header, reads Graft’s tool annotations, and picks up tool-list changes at the start of its next turn. It has no MCP elicitation, so every approval reaches you as a link into the console.

Configuration

OpenClaw’s outbound MCP servers live under mcp.servers in the Gateway’s config, ~/.openclaw/openclaw.json by default, with the transport named outright. Put the agent’s token in the Gateway host’s ~/.openclaw/.env so the config file holds no secret:
Then add Graft under mcp.servers, keeping the environment reference literal:
Or from the CLI: openclaw mcp add graft --url https://app.getgraft.ai/mcp --transport streamable-http, then set the header in the file. For self-hosted Graft the URL is your deployment’s origin plus /mcp. Restart the Gateway that owns your conversations so it loads the token (a token exported in an unrelated terminal never reaches a running Gateway); openclaw mcp reload refreshes a running runtime after a config-only change, and on versions that have it openclaw mcp doctor graft --probe checks the connection. Graft’s tools are available once they appear in a new agent turn — saving the config alone is not proof.
OpenClaw’s own schema, not the generic mcpServers block other clients take: mcp.servers, and transport said outright. The console’s agent page shows this block under OpenClaw.

Approvals

OpenClaw does not advertise elicitation, so Graft never asks in place. When a call needs your answer, the call returns awaiting_approval with a URL, the agent relays it, and you answer on the small page it opens — the one ask under Graft’s mark, which closes itself once you have answered; the same action stays under Pending actions in the console as the record. The call waits a short while for you first; if you answer within it, the call proceeds without the agent having to try again. Otherwise the agent calls again once you say it is done, and the answer is there. The same holds for a new connection and a re-entered credential: a link, the console, then the agent calls again. See Answering in the console.

Tool names and the 64-character limit

OpenClaw exposes a server’s tools to its model as <server>__<tool>, so Graft’s httpbin__get-uuid becomes graft__httpbin__get-uuid. OpenClaw truncates that combined name at 64 characters, while Graft allows 128 for its own. A vendor slug and a tool name that together run long will be cut in OpenClaw’s list, and a note from a meta-tool that names the tool will name the untruncated form. Keep vendor slugs and tool names short, and if a name has been cut, run_tool { vendor, name, input } still runs it by its real halves.

Tool-list changes

OpenClaw registers Graft’s tools/list_changed notification and re-lists at the start of the next turn rather than at once. A tool published mid-turn is therefore called with run_tool in that turn and appears first-class from the next one.

Try it