Hermes Agent reads its MCP servers from a config file at startup, launches each one, performs the handshake, and hands the discovered tools to the agent (Hermes Agent MCP docs, retrieved 2026-07-10). Connecting it to NinjaTrader 8 is therefore a config entry plus a reload, not a port of your strategy into C#. This is the Hermes-specific path: where the registration lives, the stdio and HTTP forms, the nine tools it gains, and the guardrail engine that decides which of its orders reach the platform.
What sits between Hermes and NinjaTrader 8
Three things make the connection, and only the middle one is Hermes-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 Hermes 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 Hermes wiring; the same daemon also registers in Claude and OpenClaw, each with its own config entry.
Example decisions: ALLOW buy 2 MES, all rules pass. BLOCK buy 10 MES, size 10 exceeds max_contracts_per_order 2.
The order route: the agent proposes, the guardrail engine adjudicates, and only an allowed order reaches NinjaTrader 8. The block is shown as plainly as the allow.
Register the bridge in Hermes
Hermes keeps its MCP servers under mcp_servers in ~/.hermes/config.yaml and reads that section on startup (Hermes Agent MCP docs, retrieved 2026-07-10). For a local stdio server you give it a command and an args list; Hermes launches uvx pitbridge mcp as a subprocess and speaks MCP over its standard input and output.
mcp_servers:
pitbridge:
command: "uvx"
args: ["pitbridge", "mcp"]
# custom config path? add: ["pitbridge", "mcp", "--config", "/path/to/config.toml"]The stdio server under mcp_servers. Hermes launches the command and discovers its tools at startup. Source: Hermes Agent MCP docs, retrieved 2026-07-10.
If you would rather run the daemon as a standing process, or already have it up for the REST surface, point Hermes at the HTTP endpoint instead. A remote MCP server in Hermes is a url entry under the same mcp_servers key.
$ uvx pitbridge run # daemon up on 127.0.0.1:8873 # REST at /v1/*, WebSocket at /v1/ws, MCP over HTTP at /mcp
mcp_servers: pitbridge: url: "http://127.0.0.1:8873/mcp"
The same bridge as a remote HTTP server. Streamable HTTP MCP has been served next to stdio since 0.2.0. On a localhost bind the agent token is optional; to require auth, set agent_token in the daemon config and add a matching Authorization Bearer entry under a headers map on this server, which Hermes supports for HTTP servers. Source: Hermes Agent MCP docs, retrieved 2026-07-10.
The two transports reach the same nine tools and the same guardrail pipeline, so the choice is operational, not functional.
| Property | stdio (command + args) | http (url) |
|---|---|---|
| how Hermes reaches it | launches uvx pitbridge mcp as a subprocess | connects to http://127.0.0.1:8873/mcp |
| lifecycle | started and stopped with the agent | a standing daemon you run yourself |
| also gives you REST and WebSocket | no, MCP only | yes, /v1/* and /v1/ws on the same daemon |
| when to pick it | simplest, one agent, nothing else needs the daemon | sharing the daemon, or driving it from scripts too |
stdio (command + args)
- how Hermes reaches it
- launches uvx pitbridge mcp as a subprocess
- lifecycle
- started and stopped with the agent
- also gives you REST and WebSocket
- no, MCP only
- when to pick it
- simplest, one agent, nothing else needs the daemon
http (url)
- how Hermes reaches it
- connects to http://127.0.0.1:8873/mcp
- lifecycle
- a standing daemon you run yourself
- also gives you REST and WebSocket
- yes, /v1/* and /v1/ws on the same daemon
- when to pick it
- sharing the daemon, or driving it from scripts too
After editing the file, you do not need to restart the session. Reload the servers in place and Hermes refreshes the tool list.
/reload-mcp # reloads MCP servers from config and refreshes the available tools # then ask the agent: read get_account_state before anything else
Reloading after a config change. Source: Hermes Agent MCP docs, retrieved 2026-07-10.
The nine tools Hermes discovers
At startup, or after a reload, Hermes discovers exactly nine tools. Five are reads that never change anything: get_accounts, get_positions, get_orders, get_account_state, and get_guardrail_status. Four are order actions: place_order, cancel_order, close_position, and flatten_account, and every place_order still passes the guardrail engine. What each returns, and the place_order fields (account, instrument, side, qty), are covered in what a trading MCP server does.
What is not in that list matters as much as what is. There is 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, so a bad tool call or a prompt injection cannot raise its own ceiling. The capability to weaken a limit is simply absent from Hermes’s tool surface.
The guardrail engine between Hermes 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 whose tail includes the wrong size or the wrong side. Writing the limit into Hermes’s system prompt configures behavior, it does not guarantee it. On the run where the model does not comply, a prompt limit does nothing, because the prompt was never the thing standing between the order and the account.
So the enforcement lives below the caller. Every order Hermes proposes, over stdio or HTTP, arrives at the daemon and passes a deterministic guardrail engine before it can leave your machine. The check is deterministic and runs out of process: the same order and the same config always produce the same decision, and the model is never in the adjudication. Why a told limit is advice and an enforced one is a control is the subject of risk controls an LLM cannot override, and the guardrails page lists every rule and its reason code.
See a block, on purpose
The moment that proves the setup is a refused order. With a per-order cap configured, ask Hermes 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
Example Hermes tool calls against the local daemon. Real tool names and reason code. Fills are synthetic simulation fills, not live results. The block returns as a structured result the agent can read and explain.
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 Hermes to the whole pipeline, exercise every reason code, on a Mac with a fake AddOn before any real money is in scope.
Connecting Hermes 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 Hermes 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.