How to connect OpenClaw to NinjaTrader 8

OpenClaw is an MCP client: it keeps a registry of MCP servers in its own config and hands their tools to the agent at runtime. That makes connecting it to NinjaTrader 8 a registration problem, not a porting problem. You do not rewrite your logic in C#, and you do not give the model a raw line to a futures account. You point OpenClaw at a local bridge that speaks MCP on one side and NinjaTrader on the other, and you put a deterministic check in between. This is the OpenClaw-specific setup: the exact registration, the tools it exposes, and the guardrail that adjudicates every order.

What sits between OpenClaw and NinjaTrader 8

Three things make the connection, and only the middle one is OpenClaw-specific. NinjaTrader 8 runs as usual, with its own accounts and data. The PitBridge daemon runs locally and is the one process that both speaks MCP to OpenClaw and carries orders into NinjaTrader through a small C# AddOn. Between them sits a guardrail engine that checks every order. The daemon, the AddOn, the guardrail engine, and why the whole order path stays on your machine are the shared subject of how to connect an AI agent to NinjaTrader 8. This piece assumes that background and stays on the OpenClaw wiring; if your agent runs in Hermes or Cursor instead, the same daemon serves those too and only the registration step differs.

Register the bridge in OpenClaw

OpenClaw manages MCP servers under mcp.servers in its config and exposes CLI commands to add them (OpenClaw MCP docs, retrieved 2026-07-10). You can register PitBridge either way. Over stdio, OpenClaw launches the bridge as a subprocess and talks to it over its standard input and output. The CLI writes the entry for you.

$ openclaw mcp add pitbridge --command uvx --arg pitbridge --arg mcp
# writes an entry under mcp.servers.pitbridge in ~/.openclaw/openclaw.json
# custom config path? pass it to the daemon: --arg --config --arg /path/to/config.toml

openclaw mcp add is the newer convenience subcommand; on a build that does not have it yet, openclaw mcp set pitbridge takes the same server as a JSON object, and the hand-written config below works on any OpenClaw version. That entry is a command and an args array under a name of your choosing, which also helps when you keep config in version control.

{
"mcp": {
  "servers": {
    "pitbridge": {
      "command": "uvx",
      "args": ["pitbridge", "mcp"]
    }
  }
}
}

If you would rather run the daemon once and share it across sessions, OpenClaw also speaks MCP over HTTP. Start the daemon, then register the local endpoint as a remote server with the streamable-http transport.

$ uvx pitbridge run
# daemon up on 127.0.0.1:8873
# REST at /v1/*, WebSocket at /v1/ws, MCP over HTTP at /mcp

$ openclaw mcp add pitbridge \
  --url http://127.0.0.1:8873/mcp \
  --transport streamable-http

Before you trust either form, prove it starts. OpenClaw ships a probe that connects to each configured server and reports the tools it found, so a broken command or a stale path fails loudly rather than at the first order.

$ openclaw mcp doctor --probe
# connects to each server and lists its tools
# expect: pitbridge -> 9 tools (5 read, 4 action)

The nine tools OpenClaw gets

Once registered, the agent sees exactly nine tools: five that read state and four that act. The reads never change anything. The four actions place, cancel, close, and flatten, and every place_order still passes the guardrail engine. What each tool returns, and the place_order fields (account, instrument, side, qty), are laid out in what a trading MCP server does.

There is deliberately no tool to release the kill switch, arm live trading, or change a threshold. Those live on an operator-only CLI the model never touches. The strongest safeguard here is an absence: OpenClaw cannot raise its own ceiling, because the capability to do so is simply not in its tool surface.

The guardrail engine between the agent and the account

An agent with a place_order tool is a language model with order access, and a language model produces a distribution of outputs. Most of the time it does the sensible thing. The tail of that distribution includes the wrong size, the wrong instrument, or the wrong side, reached through a plain mistake or an input crafted to talk it past its instructions. Writing the limit into OpenClaw’s system prompt configures behavior, it does not guarantee it. On the run where the model does not comply, a prompt limit does nothing.

So the enforcement lives below the caller. Every order OpenClaw proposes, over stdio or HTTP, arrives at the daemon and passes a deterministic guardrail engine before it can leave your machine: the same order and the same config always produce the same decision, and the model is never in the adjudication. A blocked order comes back as a structured result with a reason code, not an exception that kills the session. Why a prompt is advice and an out-of-process check is a control is the whole subject of risk controls an LLM cannot override, and the guardrails page lists exactly what the engine refuses.

See a block, on purpose

The moment that proves the setup is a refused order. With a per-order cap configured, ask OpenClaw to read the account, buy two contracts, then buy ten. The first fills in paper; the second breaks the cap, and the engine refuses it before NinjaTrader sees anything.

get_account_state                                              -> link_up: true, day_pnl: 0.0
place_order account=sim instrument="MES 09-26" side=BUY qty=2  -> SUBMITTED, then FILLED filled_qty=2
place_order account=sim instrument="MES 09-26" side=BUY qty=10 -> BLOCKED reason_code=MAX_CONTRACTS_PER_ORDER

A refused order is the system doing its job, not an error to hide. The whole decision, allow or block, is written to an append-only, hash-chained audit log, so pitbridge audit why <order_id> explains any single order after the fact and pitbridge audit verify proves the log has not been edited.

Honest status: paper by default, live gated

Everything above runs against a paper or simulation account. In the open core mode = "live" is intentionally out of reach: arm-live refuses, because live execution ships separately as a paid, closed component, and there is no MCP tool or REST route to change that. Live execution has been in production on a funded futures account since 30 July 2026, behind an operator-run arm step. The upside for a developer is that you can wire OpenClaw to the whole pipeline, exercise every reason code, on a Mac with a fake AddOn before any real money is in scope.

Connecting OpenClaw to NinjaTrader 8 the safe way is not about trusting a well-behaved model. It is about making it impossible for the model to leave the limits you set. The NinjaTrader 8 MCP bridge is the front door, the quickstart has the per-runtime setup, and the guardrails page lists exactly what the engine refuses. If a local, guardrailed bridge from OpenClaw to NinjaTrader is what you want, tell us your platform on the waitlist. PitBridge is trading infrastructure, not financial advice: it enforces the limits you configure and does not promise any trading outcome. Futures trading carries a substantial risk of loss.

Read the pillar: NinjaTrader 8 MCP bridge