# PitBridge, full context for agents and developers > PitBridge is a local-first Model Context Protocol (MCP) bridge that lets an AI agent trade a NinjaTrader 8 futures account behind a deterministic guardrail engine. Every order the agent proposes passes through hard risk limits that live in code, not in prompts, before it can reach the platform. Orders, keys, and positions never route through a PitBridge server. The core is open source under Apache-2.0. A fresh install runs in paper mode only; unlocking live execution is an operator step at the command line, and the paid tier gates the live provider and advanced rule packs. This file is the long-form companion to /llms.txt. It exists so an agent can answer questions about PitBridge, install it, and configure it without guessing. Every claim here is meant to match the source repository and the site. Where a fact is a plan rather than shipped behaviour, it is labeled. ## One-line positioning PitBridge is the local-first, guardrailed MCP bridge that lets your AI agent trade on NinjaTrader 8, on your own machine, behind hard limits it cannot prompt its way past, and for free until you go live. ## The wedge (how PitBridge differs from the field) 1. Local-first, no cloud in the order path. CrossTrade's MCP, TradersPost, and PickMyTrade all place their cloud between the agent and the order. PitBridge keeps the whole order route on machines you own. Open-source alternatives exist but are hobby-grade (0 to a few dozen GitHub stars, no guardrails). 2. Guardrails as a deterministic engine, not a prompt. On the agent path, CrossTrade's MCP safety is largely OAuth scopes plus instructions to the model ("check your daily loss"), which the model can talk around. PitBridge's guardrails run in code outside the model. The kill-line: their MCP safety is prompt instructions, ours is a deterministic engine outside the model. 3. Pricing wedge. CrossTrade gates its MCP behind a $99 per month cloud plan (crosstrade.io/pricing, verified 2026-07-09). PitBridge's MCP is free and local. You pay when you go live. ## Audience Primary: vibecoders and agent-builders using OpenClaw, Hermes, Claude Code, or Cursor who want to let an agent trade safely. Secondary: prop-firm and futures traders who already automate. The trader is the payer; the agent-builder is the reach. ## What PitBridge is NOT - Not a broker or exchange. It routes orders you or your agent create to your existing NinjaTrader account. It holds no funds and executes nothing itself. - Not signals, strategies, or alpha. It ships no trading logic. It will not tell you what, when, or how much to trade. - Not financial or investment advice. It is trading infrastructure. - Not a guarantee of prop-firm compliance. You configure the limits that match your firm's rules. You remain responsible for staying within your firm's terms. - Not a cloud order relay. Orders, keys, and positions never touch a PitBridge server. - Not autonomous. Enabling live execution is an operator-only ritual at the command line. The agent cannot arm live trading and cannot lift a kill switch. ## Architecture The entire order path is local. PitBridge's own cloud (marketing site, docs, software updates) is never in it. Components: - A local-first daemon (Python 3.12) that speaks MCP over stdio and, since 0.2.0, MCP over streamable HTTP at http://127.0.0.1:8873/mcp, plus a REST API and a WebSocket event feed. Runs on macOS, Linux, or Windows. - A deterministic guardrail engine: pure, synchronous checks that every order must pass before it can reach the broker. The engine is import-pure (no I/O) and returns Allow, Block, or RequireConfirm with a stable set of reason codes. - A thin NinjaTrader 8 AddOn (C#) that connects out to the daemon and places orders through the official NinjaTrader.Cbi Account API. The AddOn is deliberately dumb; all safety lives in the daemon. The NT8 box never listens; the AddOn dials out. - An append-only, hash-chained audit log (JSONL) that records every request, decision, and outcome and can prove the chain is intact. Order pipeline (fixed, not bypassable): schema validation, permission check (read-only / paper / live), guardrail check, optional human confirmation, submit, ack and reconcile, append-only audit. Only the pipeline may submit an order; this is enforced structurally, checked by an AST test that fails if any module outside the pipeline calls the order-submit path. Paired mode: the daemon can run on your Mac while NinjaTrader runs on your Windows box, connected over your own local network. One machine or two, orders move only between machines you own. The AddOn connects outbound to the daemon at ws://:8873/v1/addon using a pairing token. ## Install PitBridge is a Python package distributed for uv and pipx. Run any command straight from PyPI with uvx, or put the CLI on your PATH: uvx pitbridge doctor or uv tool install pitbridge A fresh install starts in paper mode with all guardrails on and live execution locked. There is no agent tool to unlock live. Zero-config demo sandbox: run the MCP server with no config at all and it boots a safe paper demo sandbox (a fake account, all guardrails on, live locked). It has no broker link and cannot place a real order, so it never crashes for lack of setup, and an agent can immediately call get_accounts and get_guardrail_status before anything is configured: uvx pitbridge mcp Scaffold a real config, then edit it (set your NinjaTrader account name and guardrail values under ~/.pitbridge/config.toml): uvx pitbridge init # writes ~/.pitbridge/config.toml; --force to overwrite Start the MCP server over stdio (this is what an MCP client attaches to; it reads ~/.pitbridge/config.toml): pitbridge mcp Run the daemon's REST, WebSocket, and MCP-over-HTTP surface (streamable HTTP at /mcp) against a config file: pitbridge run --config ./config.toml Verify the setup with the read-only self-check. pitbridge doctor prints a PASS, WARN, or FAIL line per section (config, accounts, guardrails, deny-list, kill switch, live gate, and version) and is the go-to troubleshooting command: pitbridge doctor Other CLI commands: pitbridge status (config, kill file, link and halt state), pitbridge token new (mint an agent_token for the bearer-authenticated REST and /mcp surface), pitbridge confirm (approve a held order; the daemon re-runs the full guardrail chain at confirm time), pitbridge audit why (explain any decision), pitbridge audit verify (prove the audit chain is intact and catch edits), pitbridge arm-live (refuses cleanly with a non-zero exit in the open-source core; there is no live provider without the paid plugin). ## Connecting each agent runtime PitBridge is an MCP server, so any MCP client can attach. Common setups: - Claude Code: add the local MCP server with one command (the stdio transport, running `pitbridge mcp`). - Claude Desktop: install the .mcpb bundle; guardrail settings surface in the native settings UI. - OpenClaw: use the pitbridge-trading skill, a thin wrapper over the MCP tools with the security story up front. - Hermes and other generic MCP-over-HTTP clients: since 0.2.0, point them at http://127.0.0.1:8873/mcp for MCP over streamable HTTP. A stdio MCP server and the localhost REST API also work. - Cursor: add pitbridge to mcp.json (stdio). - Your own script: use the localhost REST API (/v1/*) and the WebSocket event feed. Full copy-paste config blocks per framework live at https://pitbridge.com/docs/quickstart/ (plain markdown: https://pitbridge.com/docs/quickstart.md). ## The nine v0 MCP tools Reads: get_accounts, get_positions, get_orders, get_account_state, get_guardrail_status. Writes: place_order, cancel_order, close_position, flatten_account. Every mutating tool is routed through the pipeline. A guardrail Block returns a structured result (blocked=true plus a reason code and detail), never a raised exception, so the agent session survives a refusal. There is deliberately no tool to mutate config or thresholds, un-kill, or arm live. This is proven by a no-bypass and prompt-injection acceptance test: a guardrail-hitting place_order is blocked and never sent, no tool can weaken a limit, no tool can un-kill or arm live across a whole session, and a flatten then place sequence cannot slip past an engaged kill or a sticky day-halt. ## The twelve deterministic guardrails (v0) All are default-on and enforced in the daemon, outside the model. Example config values below are illustrative, not defaults. 1. kill_switch. One command halts all order flow. Un-kill is CLI-only; there is no REST route and no agent tool. Example: BLOCK sell 1 RTY. kill_switch is armed. 2. daily_loss_halt. When the configured daily loss is reached (realized plus unrealized, ET day rollover), new orders are refused for the rest of the day. Example: BLOCK buy 1 ES. daily loss 512 >= limit 500. 3. profit_lock. Locks in the day once a configured profit target is reached. 4. max_contracts_per_order. Caps contracts per single order. Example: BLOCK buy 5 MNQ. limit is 2. 5. max_position. Caps net position per instrument and account, counting the account's own in-flight (working / pending) orders so two concurrent orders cannot sum past the cap by racing. An over-cap long cannot flip to an equally over-cap short in one order. 6. instruments (allowlist). The agent trades only the instruments you list. Example: BLOCK buy 1 6E. not in allowlist. 7. trading_window. Orders are accepted only inside the window you define, with a holiday and early-close calendar. Example: BLOCK buy 1 CL at 03:12. window is 09:30-16:00. 8. cooldown_after_order_s. Enforces a cooldown after a loss or an order. 9. max_orders (rate limit). Caps orders per minute, hour, and day so a looping agent cannot spray the book. Example: BLOCK order 7 in 60s. limit is 6. 10. duplicate_order_protection. Refuses the same account, instrument, side, and quantity within a short window. 11. human_confirm. Live accounts can require explicit confirmation (off, first_order, every_live_order, or size_increase). Example: WARN live order held. confirm to send. 12. link_down_block. If the AddOn link is not fresh, orders are blocked with LINK_DOWN until the first post-connect account_state arrives. The same guard also blocks new entries with STALE_ACCOUNT_STATE when an account's account_state (unrealized P&L) feed goes stale past account_state_staleness_s (a [daemon] key, default 60 s, floor 5 s) while heartbeats keep the link up, so daily_loss_halt and profit_lock fail closed instead of running on frozen numbers; de-risking (close / flatten) stays allowed. Representative reason codes: KILL_SWITCH, DAILY_LOSS_HALT, MAX_CONTRACTS_PER_ORDER, MAX_POSITION, INSTRUMENT_NOT_ALLOWED, OUTSIDE_TRADING_WINDOW, ORDER_RATE_LIMIT, LINK_DOWN, STALE_ACCOUNT_STATE, PERMISSION_READ_ONLY, INVALID_QTY, UNKNOWN_ACCOUNT. ## Safety model, short form - Default-deny live. A fresh install is paper only. arm-live refuses in the open-source core. - Guardrails outside the model. Limits live in a config file the agent cannot edit; there is no tool to weaken them. - Fail closed. If the daemon is down or the AddOn link is stale, no orders pass; if an account's account_state (P&L) feed goes stale, new entries are blocked with STALE_ACCOUNT_STATE while de-risking stays allowed. - Tamper-evident. The audit log is append-only and hash-chained; pitbridge audit verify catches edits or gaps. - Reduce-only de-risking. Close and flatten are strictly reduce-only in the AddOn's C# order router. - Authenticated agent surface. Since 0.2.0 a bearer agent_token guards the REST API and the /mcp endpoint: optional on a localhost bind, required before any non-localhost bind will start. Full write-up: https://pitbridge.com/docs/security-model/ ## Pricing - Free (open core): $0. Paper and read-only, one account, the full guardrail set, hash-chained audit. This is the top of the funnel. - Pro: $49 per month list. Founder price $39 per month, locked for life, first 100 accounts. Adds live-execution unlock, prop-firm rule packs, fan-out to about five accounts, and audit export. - Desk: planned, for 10+ accounts, multi-seat, and priority support. Not available yet. Live-unlock is the gate: you pay when real money is at stake. The live provider and rule packs are closed components, not just a license flag. ## Honest status (as of 2026-07-31) The daemon and AddOn are built and tested against a fake AddOn and harness, and the full chain has run against a real NinjaTrader 8 install on a demo account: pairing, a filled market order, a reduce-only close, guardrail refusals, and the kill switch, verified end to end. Daemon 0.2.0 adds MCP over streamable HTTP at /mcp alongside stdio, plus a bearer agent_token guard on the REST and /mcp surface (optional on a localhost bind, required on any non-localhost bind). Daemon 0.2.1 hardens the guardrails: the position cap is in-flight-aware (concurrent orders cannot sum past max_position), and a new STALE_ACCOUNT_STATE guard blocks new entries when an account's P&L feed goes stale while de-risking stays allowed. Daemon 0.2.2 adopts broker positions as the source of truth on reconnect and persists the day ledger across a restart, so the daily loss halt keeps enforcing after a crash. Test counts, guardrail counts, and tool counts above are drawn from the repository. The package is published on PyPI (uvx pitbridge resolves and runs) and listed in the official MCP registry as com.pitbridge/pitbridge. The public GitHub repository is being finalized; verify availability before relying on it. Live execution status, updated 2026-07-31: live order routing has been in production on a single funded futures account since 30 July 2026. It is gated, and the gate is the honest part of the story. Live routes only when a LiveExecutionProvider plugin is installed, its licence entitles live, and an operator has completed the arm ritual at the command line; every other path fails safe to not armed, and the outcome is written to the hash chained audit log with the operator acknowledgement. The open core on its own cannot arm live: a one contract smoke test on that funded account was refused with LIVE_NOT_ARMED until the paid component was installed and the ritual completed, which means the product refused its own author. On the first order through the complete stack the confirm gate parked it for supervised approval, the fill on that order came back in 0.52 seconds, the protective stop was attested WORKING against the REST orderbook, and the flatten was clean. Autonomous cycles have run through the same guardrail engine since. This is one account over a short period. It is not a track record, no trading outcome is promised, and futures trading carries a substantial risk of loss. ## Knowledge base (generated from the article collection at build time) Each article below is a full page at its URL. The tldr and FAQ pairs are the article's own summary and frequently asked questions, verbatim. ### How to connect Claude to NinjaTrader 8 safely URL: https://pitbridge.com/learn/articles/connect-claude-to-ninjatrader-8-safely/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-05. Connecting Claude to NinjaTrader 8 safely means putting a local bridge between them. Claude proposes orders as tool calls, and a guardrail engine on your machine decides which ones reach NT8. Q: Do I need to write code to connect Claude to NinjaTrader 8? A: No. Claude Desktop and Claude Code connect to an MCP server with a small config block. You point the client at the local PitBridge daemon and the tools appear in the session. Q: Is my NinjaTrader account or API key exposed to a cloud service? A: No. The bridge runs on your machine. The MCP server, the guardrail engine and your credentials stay in the local daemon, and no order is relayed through a PitBridge server. Q: Do I need a paid Claude plan to do this? A: Claude Code needs a paid Claude plan such as Pro, Max, Team or Enterprise. The MCP config block itself is the same on Claude Desktop. PitBridge does not sell or resell any Claude subscription; you bring your own client. Q: Can I use a funded or prop-firm account? A: Start on a simulation account such as Sim101. For a funded account you must check the firm's automation policy yourself, because rules change and vary by firm: some prohibit agent or automated order entry, some permit it with conditions. Firms like Apex or Topstep are only examples to verify, not endorsements. Verify with the firm before you connect anything live. Q: Can I do the same thing with ChatGPT or Claude Code? A: Yes. Any MCP-capable client can connect the same way. The bridge does not care which model is on the other end, because the guardrail engine checks every order regardless of the client. Q: Why don't the tools appear after I edit the config? A: Fully quit and reopen the client so it re-reads the config. Check that the JSON is valid. If the server still fails to start, use an absolute path to uv in the command, because the client launches with a minimal PATH. Q: Does this work on a Mac without NinjaTrader installed? A: Yes for exercising the safety kernel. On a Mac you run the daemon against a bundled fake AddOn that gives synthetic fills, so you can see guardrails, the kill switch and the audit log work. Real order routing into NinjaTrader 8 is Windows plus the M4 AddOn. Q: Which account should I start on? A: Start on a NinjaTrader simulation account such as Sim101, in read-only or paper mode. Move an agent to a live account only after you have watched how it behaves and set your limits. ### Local-first trading automation: why it matters URL: https://pitbridge.com/learn/articles/local-first-trading-automation-why-it-matters/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-05. Local-first means the order route, the guardrail engine and your keys stay on your machine, with no cloud in the path. This is what that buys you for security, latency, and failure behavior. Q: What does local-first actually mean here? A: The MCP server, the guardrail engine and your keys run in a daemon on your own machine. Your agent talks to localhost, orders reach NinjaTrader through a local AddOn, and no order is relayed through a PitBridge server. Q: Is it safe to give an AI agent access to my trading account? A: The agent holds no broker credentials and can only reach a local, guardrailed surface. Risk limits are enforced in code, not in the prompt, so a manipulated prompt cannot widen a limit or release the kill switch. That reduces the blast radius. It does not make any account unhackable. Q: Can a prompt-injection attack make the agent place a rogue order? A: It can try. What it cannot do is widen your limits or release the kill switch, because no tool exists for either, and any order it emits still passes the deterministic guardrail engine and cannot exceed the caps you set. Q: Where are my API keys and broker credentials stored? A: In the daemon on your own machine. They never enter the agent's context and never reach a PitBridge server, so there is no hosted vault of trading credentials to breach. Q: Is there any cloud component at all? A: Any cloud element is for optional telemetry only, drawn off the order route. It never carries an order. The path from agent to platform stays on your machine, which is the property that matters for a trading account. Q: What is the difference between local-first and a VPS or cloud webhook setup? A: A VPS or a webhook relay still puts a machine you rent, or a service you do not control, between your agent and your account. Local-first keeps the order route on hardware you own, with the checks and the keys in the same place. Q: Does the bridge queue my orders if it reconnects? A: No. It fails closed and never replays buffered orders. If the link is down every order hard-rejects with reason_code LINK_DOWN, and until an AddOn connects and sends its first account-state snapshot, orders stay blocked. Q: What happens if the bridge goes down? A: No orders pass. The system fails closed. That is the intended behavior: a bridge that is not running should stop trading, not queue orders somewhere and replay them later. Q: Can I run it on a Mac? A: Yes. The daemon is cross-platform, so it runs on macOS or Windows. In paired mode you can run the daemon on your Mac and reach a NinjaTrader instance on a Windows box on your own network. ### How to connect an AI agent to NinjaTrader 8 URL: https://pitbridge.com/learn/articles/connect-ai-agent-to-ninjatrader-8/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-10. Connecting an AI agent to NinjaTrader 8 comes down to where the order logic runs and what checks it. This walks the three approaches, why an external MCP agent is the flexible one, and the real uvx quickstart with a guardrail that blocks any order past your limits. Q: How do I connect an AI agent to NinjaTrader 8? A: Run a local bridge that both speaks to your agent and speaks to NinjaTrader 8. With PitBridge you run uvx pitbridge mcp, register it in your MCP client such as Claude Code, and the agent gets nine tools. Every order it proposes passes a guardrail engine on your machine before it reaches the platform. Q: Does NinjaTrader 8 have a Python API? A: No. NinjaTrader 8 automates through NinjaScript, its C# environment, and ships no official Python API. To drive it from Python or an AI agent you need a bridge outside the platform. The PitBridge daemon is Python and exposes a localhost REST route and an MCP server, so a Python script or an agent can propose orders that route through the guardrails into NinjaTrader 8. Q: Is it safe to let an AI place orders? A: Only if a control the model cannot reach sits between it and the account. A system prompt telling the model to respect a limit is advice it can ignore or be tricked past. PitBridge runs the limits as a deterministic engine in a separate process, and the agent has no tool to weaken a limit, release the kill switch, or arm live. It can propose an order; the daemon decides. Start on a simulation account and watch it before anything funded. Q: Does my data leave my machine? A: No. The daemon, the guardrail engine, and your credentials run on your own machine, and no order is relayed through a PitBridge server. In paired mode the daemon runs on your Mac and the AddOn runs next to NinjaTrader 8 on your Windows box over your own network. PitBridge's own cloud is never in the order path. Q: Does it work with prop accounts? A: PitBridge enforces the limits you configure on any account you point it at, but it does not know or bypass any prop firm's automation policy. Some firms prohibit agent or automated order entry, some permit it with conditions, and rules change. You are responsible for reading your firm's written rules and mapping them into your config. Verify with the firm before you connect anything to a funded account. Q: Do I need NinjaTrader installed to try it? A: No. With no config at all, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and all guardrails on, so an agent can read state and see the tools. To exercise the full order flow on a Mac you run the daemon against a bundled fake AddOn that gives synthetic fills. Real routing into NinjaTrader 8 is Windows plus the C# AddOn. Q: How is this different from CrossTrade? A: CrossTrade offers a hosted MCP server on its Elite plan, where agent instructions route through CrossTrade's cloud to reach the platform. PitBridge is local-first: the MCP server, the checks, and your keys stay on your machine, and the MCP is free. The comparison page lays out the sourced differences, including what CrossTrade does that PitBridge does not. ### Is there a NinjaTrader 8 Python API? URL: https://pitbridge.com/learn/articles/ninjatrader-8-python-api/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-10. There is no official NinjaTrader 8 Python API. The platform automates in C# through NinjaScript, and everything else is a bridge: the ATI file or DLL route, a third-party cloud REST relay, or a local daemon your Python code drives. This walks the real options, their tradeoffs, and where a local-first Python daemon that speaks REST and MCP fits. Q: Does NinjaTrader 8 have a Python API? A: No. NinjaTrader 8 automates through NinjaScript, its in-platform C# environment, and ships no official Python API or SDK. To drive it from Python you go around the platform with a bridge: the built-in Automated Trading Interface (files or a .NET DLL), a third-party cloud REST relay, or a local daemon that exposes a localhost API your Python code calls. Q: Can I control NinjaTrader from Python? A: Yes, indirectly. Python cannot run inside NinjaTrader, but it can drive it through a bridge. The simplest official route is writing Order Instruction Files that the ATI reads. A richer route is a bridge that gives you REST or MCP. With PitBridge the daemon is Python, so your Python script POSTs an order to http://127.0.0.1:8873/v1/place_order on localhost and a C# AddOn does the NinjaTrader side. Q: What is the NinjaTrader ATI? A: The Automated Trading Interface is NinjaTrader's official way in from an outside program. It has a file interface that reads semicolon-delimited Order Instruction Files named oif*.txt from an incoming folder, and a DLL interface, NTDirect.dll, shipped as NinjaTrader.Client.dll. Both run only on the Windows box where NinjaTrader runs, and both submit orders without any risk checks of their own. Source: ninjatrader.com ATI help guide, retrieved 2026-07-10. Q: How does PitBridge let Python place an order? A: Run uvx pitbridge run and the daemon serves a localhost REST API at /v1/*, a WebSocket event feed, and MCP over HTTP at http://127.0.0.1:8873/mcp. Your Python posts a JSON order to /v1/place_order, it passes the same deterministic guardrail engine as an agent's tool call, and only an allowed order continues to NinjaTrader 8. A blocked order returns a structured reason code, not an exception. Q: Do I need Windows and the C# AddOn to try it? A: Not to try it. With no config, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and every guardrail on, so a script or agent can read state and exercise the tools. Real routing into NinjaTrader 8 is the Windows piece: the C# AddOn runs next to NinjaTrader and connects out to the daemon. The daemon itself runs on macOS, Linux, or Windows. Q: Is it safe to place orders this way, and does it go live? A: Every order through the daemon passes a deterministic guardrail engine that refuses anything past the limits you configure, and no order routes through a PitBridge server. The open core is paper and simulation only: arm-live refuses there because live execution ships as a separate closed component, and no agent or script has a tool to change that. Live execution has been in production on a funded futures account since 30 July 2026, behind an operator-run arm step. Futures trading carries substantial risk of loss. This is not financial advice. ### How to connect OpenClaw to NinjaTrader 8 URL: https://pitbridge.com/learn/articles/connect-openclaw-to-ninjatrader-8/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-10. OpenClaw registers MCP servers in its own config, so pointing it at NinjaTrader 8 is a config entry, not a rewrite. This walks the exact OpenClaw registration for the local PitBridge bridge, over stdio or HTTP, the nine tools it exposes, and the guardrail engine that checks every order before it can reach the platform. Q: How do I connect OpenClaw to NinjaTrader 8? A: Register a local MCP bridge in OpenClaw and point it at NinjaTrader 8. With PitBridge you run openclaw mcp add pitbridge with the command uvx pitbridge mcp, or add the same entry under mcp.servers in your OpenClaw config, and the agent gains nine tools. Every order it proposes passes a deterministic guardrail engine on your machine before it can reach the platform. Q: Does OpenClaw support stdio and HTTP MCP servers? A: Yes. OpenClaw registers stdio servers for local commands and remote servers over streamable-http or SSE. PitBridge exposes both: stdio via uvx pitbridge mcp, and MCP over HTTP at http://127.0.0.1:8873/mcp when you run uvx pitbridge run. Both reach the same nine tools and the same guardrail pipeline. Source: OpenClaw MCP docs, retrieved 2026-07-10. Q: Where does OpenClaw store the MCP server config? A: Under mcp.servers in the OpenClaw config file, at ~/.openclaw/openclaw.json. A stdio entry is a command and an args array; a remote entry is a url with a transport of streamable-http or sse. The openclaw mcp add command writes the entry for you. Source: OpenClaw configuration reference, retrieved 2026-07-10. Q: Can OpenClaw place a live order through PitBridge? A: Not in the open core. PitBridge's open core runs in paper and simulation only: arm-live refuses there because live execution ships separately as a closed component, and there is no MCP tool to change that. Live execution has been in production on a funded futures account since 30 July 2026, behind an operator-run arm step. Start on a NinjaTrader simulation account and watch the agent before anything funded. Futures trading carries substantial risk of loss. This is not financial advice. Q: Do I need Windows and the C# AddOn to try it with OpenClaw? A: Not to try it. With no config, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and every guardrail on, so OpenClaw can read state and exercise the tools. Real routing into NinjaTrader 8 is the Windows piece: the C# AddOn runs next to NinjaTrader and connects out to the daemon. The daemon itself runs on macOS, Linux, or Windows. Q: Can the OpenClaw agent weaken a guardrail or arm live trading? A: No. The agent surface is exactly nine tools: five reads and four order actions. None of them can release the kill switch, arm live trading, or change a limit. Those controls live on an operator-only CLI the model never touches, so a bad tool call or a prompt injection cannot raise its own ceiling. ### How to connect Hermes to NinjaTrader 8 URL: https://pitbridge.com/learn/articles/connect-hermes-to-ninjatrader-8/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-10. Hermes reads its MCP servers from a config file at startup, so pointing it at NinjaTrader 8 is a config entry plus a reload, not a rewrite. This walks the exact Hermes registration for the local PitBridge bridge, over stdio or HTTP, the nine tools it gains, and the guardrail engine that decides which of its orders reach the platform. Q: How do I connect Hermes to NinjaTrader 8? A: Add a local MCP bridge to your Hermes config and point it at NinjaTrader 8. With PitBridge you add an entry under mcp_servers in ~/.hermes/config.yaml, either a stdio command running uvx pitbridge mcp or a url pointing at http://127.0.0.1:8873/mcp, then run /reload-mcp. The agent gains nine tools, and every order it proposes passes a deterministic guardrail engine on your machine before it can reach the platform. Q: Where do I register the MCP server in Hermes? A: Under the mcp_servers section of ~/.hermes/config.yaml. Hermes reads that section on startup, launches each configured server, performs the MCP handshake, and discovers the tools. A stdio server is a command with args; a remote server is a url. Source: Hermes Agent MCP docs, retrieved 2026-07-10. Q: Does Hermes support HTTP MCP servers? A: Yes. Hermes supports stdio servers that run as local subprocesses and HTTP servers that connect to a remote endpoint over the network. PitBridge serves both: stdio via uvx pitbridge mcp, and MCP over streamable HTTP at http://127.0.0.1:8873/mcp when you run uvx pitbridge run. Source: Hermes Agent MCP docs, retrieved 2026-07-10. Q: How do I reload Hermes after editing the MCP config? A: Run /reload-mcp in the session. It re-reads the mcp_servers section and refreshes the available tool list without a full restart. Source: Hermes Agent MCP docs, retrieved 2026-07-10. After reloading, ask the agent to read the account state before you let it propose anything. Q: Can Hermes arm live trading or lift a guardrail through PitBridge? A: No. The agent surface is exactly nine tools: five reads and four order actions. None of them can arm live trading, release the kill switch, or change a limit. The open core is paper and simulation only: arm-live refuses there because live execution ships separately as a closed component, released only from an operator-only CLI. Live execution has been in production on a funded futures account since 30 July 2026, behind an operator-run arm step. Futures trading carries substantial risk of loss. This is not financial advice. Q: Do I need NinjaTrader installed to try it with Hermes? A: No. With no config, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and every guardrail on, so Hermes can read state and exercise the tools. Real routing into NinjaTrader 8 is the Windows piece: the C# AddOn runs next to NinjaTrader and connects out to the daemon. The daemon itself runs on macOS, Linux, or Windows. ### How to connect Cursor to NinjaTrader 8 URL: https://pitbridge.com/learn/articles/connect-cursor-to-ninjatrader-8/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-10. Cursor registers MCP servers in a small JSON file, so pointing the IDE at NinjaTrader 8 is a config entry in your trading project, not a rewrite. This walks the exact registration for the local PitBridge bridge, over stdio or HTTP, and the dev loop it opens: build your agent and its scripts in Cursor while a guardrail engine keeps every order they propose inside your limits, on paper. Q: How do I connect Cursor to NinjaTrader 8? A: Add a local MCP bridge to Cursor's MCP config and point it at NinjaTrader 8. With PitBridge you add an entry named pitbridge under mcpServers in .cursor/mcp.json (project) or ~/.cursor/mcp.json (global) that runs uvx pitbridge mcp, or a url entry pointing at http://127.0.0.1:8873/mcp. The agent in the IDE gains nine tools, and every order it proposes passes a deterministic guardrail engine on your machine before it can reach the platform. Q: Where does Cursor store MCP server config? A: In mcp.json under an mcpServers key. Cursor reads .cursor/mcp.json in your project for project-specific servers and ~/.cursor/mcp.json in your home directory for servers available everywhere. Servers can also be installed and managed from the Customize page in the editor. Source: Cursor MCP docs, retrieved 2026-07-10. Q: Does Cursor support HTTP MCP servers or only stdio? A: Both. Cursor supports stdio servers it launches as local processes, and remote servers over SSE or streamable HTTP configured with a url. PitBridge serves both forms: stdio via uvx pitbridge mcp, and MCP over streamable HTTP at http://127.0.0.1:8873/mcp when you run uvx pitbridge run. Source: Cursor MCP docs, retrieved 2026-07-10. Q: Can the Cursor agent place a live order through PitBridge? A: Not in the open core. PitBridge's open core runs in paper and simulation only: arm-live refuses there because live execution ships separately as a closed component, and there is no MCP tool to change that. Live execution has been in production on a funded futures account since 30 July 2026, behind an operator-run arm step. Start on a NinjaTrader simulation account and watch the agent before anything funded. Futures trading carries substantial risk of loss. This is not financial advice. Q: Do I need NinjaTrader installed to develop against the bridge in Cursor? A: No. With no config, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and every guardrail on, so the agent in your editor can read state and exercise the tools while you build. Real routing into NinjaTrader 8 is the Windows piece: the C# AddOn runs next to NinjaTrader and connects out to the daemon. The daemon itself runs on macOS, Linux, or Windows. Q: Can a prompt injection in my codebase make the agent exceed my limits? A: It can try, and the design assumes it will. An IDE agent reads your files as a matter of course, and any file can carry adversarial text. Whatever the model is talked into proposing, the order still lands in a deterministic engine outside the model, and the agent's nine tools include nothing that can release the kill switch, arm live trading, or change a limit. The blast radius of a hijacked session is a proposal, not an execution. ### How to automate NinjaTrader 8 without writing NinjaScript URL: https://pitbridge.com/learn/articles/automate-ninjatrader-without-ninjascript/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-12. NinjaTrader 8 automates in C#, and most automation guides quietly assume you write it. You do not have to. This is the honest map for traders who do not code: the platform's own Strategy Builder, bought or commissioned strategies, trade copiers, webhook relays, and the newest option, an AI agent you instruct in plain language behind a deterministic guardrail engine. What each one demands of you, and the one responsibility none of them remove. Q: Can I automate NinjaTrader 8 without knowing how to code? A: Yes, through several routes. Inside the platform, the Strategy Builder generates NinjaScript strategies from a point and click interface, and the NinjaTrader Ecosystem sells prebuilt automated strategies. Outside it, trade copiers mirror fills across accounts, webhook services relay chart alerts into the platform, and an AI agent bridge like PitBridge takes plain language instructions behind a deterministic guardrail engine. Each option trades convenience against control, and none of them removes your responsibility for the risk rules. Q: Is there a no-code way to build my own NinjaTrader 8 strategy? A: Yes. NinjaTrader 8 ships the Strategy Builder, a point and click tool that generates NinjaScript based strategies for automated systems trading without you writing code. Source: NinjaTrader help guide, retrieved 2026-07-12. It is the right first stop for a mechanical rule built from standard indicators. What it produces is still a fixed strategy: it follows its conditions, it does not reason about context. Q: Can an AI agent automate NinjaTrader 8 from plain English instructions? A: Yes, through a local bridge. You describe the job in plain language to an agent such as Claude, the agent reads account state and proposes orders through nine typed tools, and every order passes a deterministic guardrail engine on your machine before NinjaTrader sees it. How faithfully an agent follows a standing instruction is a property of the model and runtime you choose; what the bridge controls is that no proposed order can exceed the limits you configured. Q: Do webhook services automate NinjaTrader 8 without coding? A: Partly. A webhook relay turns a chart alert into an order in your platform, so you write alert conditions instead of C#. The alert logic is still your strategy, and with a hosted relay the vendor's cloud sits in the path of every order. CrossTrade is the established suite of this kind for NinjaTrader 8. PitBridge takes a different shape: no webhooks, no cloud relay, an agent as the caller and a local guardrail engine as the checkpoint. Q: Is no-code trading automation safe? A: No automation is safe by default. Every option executes whatever it was configured with, faster and more consistently than you would by hand, which amplifies good rules and bad ones alike. A guardrail layer reduces specific failure classes by refusing orders past your limits, but it does not make a strategy good and it does not prevent losses. Futures trading carries substantial risk of loss. This is not financial advice. Q: Do I need Windows or NinjaTrader installed to try PitBridge? A: Not to try it. With no config, uvx pitbridge mcp boots a safe paper demo sandbox with a fake account and every guardrail on, so an agent can read state and exercise the tools. Real routing into NinjaTrader 8 is the Windows piece: the C# AddOn runs next to NinjaTrader and connects out to the daemon, while the daemon itself runs on macOS, Linux, or Windows. This build is paper and simulation only, and live execution stays locked behind an operator-only step. ### NinjaTrader 8 ATI: the Automated Trading Interface explained URL: https://pitbridge.com/learn/articles/ninjatrader-8-ati-automated-trading-interface/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-13. The NinjaTrader 8 Automated Trading Interface is the platform's supported way in from an outside program: a folder that reads semicolon-delimited OIF text files, and NTDirect.dll for compiled callers. This is the reference on how both work, the OIF filename and incoming-folder gotchas, what the ATI deliberately does not do (no risk checks, Windows-local, and for the file route no order acknowledgements back), and why an in-platform NinjaScript AddOn on the Cbi object model is a different tool for AI-driven automation. Q: What is the NinjaTrader 8 ATI? A: The Automated Trading Interface is NinjaTrader's supported way to drive order execution from an outside program. NinjaTrader's own help guide describes it as efficient protocols to communicate trading signals from various external sources to NinjaTrader for the automation of order execution, and states plainly that it is ONLY used for processing trade signals from external applications and is NOT a full blown brokerage or market data API. It comes in two forms: a file interface that reads Order Instruction Files, and a DLL interface. Source: ninjatrader.com ATI help guide, retrieved 2026-07-13. Q: What is an OIF or Order Instruction File? A: An OIF is a plain text file that the ATI file interface reads to place or manage an order. You write it into the incoming folder under My Documents in your NinjaTrader directory, named oif followed by anything and ending in .txt (for example oif1.txt), with fields separated by semicolons. NinjaTrader processes the file the instant it is written to disk. Supported instructions include PLACE, CHANGE, CANCEL, CLOSEPOSITION, REVERSEPOSITION and FLATTENEVERYTHING. Source: ninjatrader.com OIF help guide, retrieved 2026-07-13. Q: Why is my OIF file being ignored? A: The two most common causes are the filename and the folder. The file has to match the oif*.txt pattern, so a name that does not start with oif is silently skipped, and it must land in the incoming folder inside your NinjaTrader documents directory. NinjaTrader also recommends incrementing to unique names such as oif1.txt, oif2.txt to avoid file locking, and writing or moving files into the folder rather than copying them, which can cause locking problems. Source: ninjatrader.com OIF help guide, retrieved 2026-07-13. Q: What is NTDirect.dll? A: NTDirect.dll is the assembly that holds the ATI DLL interface functions, shipped in the NinjaTrader 8 bin directory and also referred to as NinjaTrader.Client.dll. It is a .NET managed DLL, so a caller invokes functions such as Command to submit, cancel or change orders, and query functions such as OrderStatus, Filled, MarketPosition and AvgFillPrice for feedback. Because it is managed .NET rather than a plain C library, calling it from a non-.NET language means bridging the CLR. Source: ninjatrader.com DLL interface help guide, retrieved 2026-07-13. Q: Does the NinjaTrader ATI check orders for risk? A: No. The ATI submits what it is given. There is no position cap, daily loss halt, or rate limit between the OIF or the DLL call and the account, so whatever writes the file or calls the function is fully trusted. If a bug sends a quantity of 100 instead of 1, the ATI forwards it. That missing checkpoint is exactly what a guardrail layer is for, and it is why an unattended AI agent driving the raw ATI is a poor idea. Q: Can I run an AI trading agent through the ATI? A: You can, but the ATI is a blunt tool for it. The file route is fire and forget: writing an OIF gets no structured acknowledgement back to the writer, so an agent cannot cleanly read whether its order filled from the file it wrote. The DLL route exposes status query functions but is Windows-local managed .NET. Neither offers any risk check. An agent with order access fails in specific ways that a raw ATI does nothing to catch, which is why PitBridge puts a deterministic engine in the path instead. Q: How is PitBridge different from driving the ATI directly? A: PitBridge does not use ATI files at all. Its NinjaTrader piece is a NinjaScript AddOn that runs inside NinjaTrader 8 on the Cbi object model, working with real Account, Order and Execution objects, so it gets genuine order acknowledgements and fills rather than fire-and-forget file drops. In front of that sits a deterministic guardrail engine that refuses any order past the limits you configure, before the platform ever sees it. The open core is paper and simulation only, live is gated behind a separate paid component, and no order routes through a PitBridge server. ### Rithmic automated trading: the futures infrastructure explained URL: https://pitbridge.com/learn/articles/rithmic-automated-futures-trading/ Cluster: NinjaTrader and AI agents. Updated: 2026-07-13. Rithmic is trade-execution and market-data infrastructure that sits under many futures brokers and prop firms rather than a platform you trade in directly. This explains what it is, the R|Trader Pro and R|API+ ecosystem, why firms like Bulenox and Apex route through it, and what it means to automate on a Rithmic-backed account: data-feed access, API cost, and platform routing such as NinjaTrader connecting to Rithmic. Automating on a Rithmic-backed prop account still means your firm's automation rules apply. Q: What is Rithmic? A: Rithmic is a futures trade-execution and market-data infrastructure provider, not a broker or a retail platform you sign up with directly. Its homepage describes it as trading infrastructure for futures, and its core is the R|Trade Execution Platform, which routes orders to exchanges and delivers normalized market data. Many brokers, FCMs and prop firms connect their accounts through Rithmic, and you reach it through a platform such as R|Trader Pro or NinjaTrader. Source: rithmic.com, retrieved 2026-07-13. Q: Is there a Rithmic API for automated trading? A: Yes. Rithmic publishes R|API+, described as a collection of software libraries and interface definitions that developers incorporate into their own software to gain access to the R|Trade Execution Platform, giving a normalized view of market data and of order and execution reports across supported exchanges. A higher-tier R|Diamond API adds ultra-low-latency and high-frequency capability. Access is typically arranged through your broker or firm; confirm availability and any fee with them. Source: rithmic.com programmatic trading interfaces, retrieved 2026-07-13. Q: What is R|Trader Pro? A: R|Trader Pro is Rithmic's own trading application: R|Trader with charts and a real-time interface to and from Microsoft Excel. It streams studies into spreadsheets and can send configured trades back into the R|Trade Execution Platform, automatically or with a click. It is one way to trade a Rithmic-backed account directly, alongside third-party platforms like NinjaTrader that connect to the same infrastructure. Source: rithmic.com, retrieved 2026-07-13. Q: Why do so many prop firms use Rithmic? A: Rithmic provides the execution and data connectivity a firm needs without the firm building it, so a prop firm can offer real-time futures data and order routing by connecting accounts through Rithmic. Bulenox documents connecting via Rithmic, and Apex Trader Funding publishes an official connection guide for NinjaTrader using Rithmic. Which firms use it, and on what terms, is the firm's own detail to confirm. Sources: bulenox.com and support.apextraderfunding.com, retrieved 2026-07-13. Q: Can I automate trading on a Rithmic-backed prop account? A: Technically, yes, usually by pointing an automated platform such as NinjaTrader at the firm's Rithmic connection, or by using R|API+ where your broker permits it. But technical possibility is not permission. Automating on a prop account is governed by that firm's written automation rules, which vary by firm and change, and Rithmic being the plumbing underneath does not alter them. Verify your firm's policy before you automate anything. Q: Does using Rithmic mean prop firm automation rules do not apply? A: No. Rithmic is infrastructure; it does not grant or override a prop firm's rules. If your firm restricts automated or agent-driven order entry, that restriction applies whether or not the account runs on Rithmic. The automation policy comes from the firm, not the data feed. Read the firm's rules and get anything ambiguous confirmed in writing. Q: Does PitBridge connect to Rithmic directly? A: No. PitBridge connects to NinjaTrader 8 through a local NinjaScript AddOn, and NinjaTrader is what connects to Rithmic. PitBridge enforces the numeric limits you configure locally before an order reaches the platform; it does not touch the Rithmic connection and does not bypass any firm rule. The open core is paper and simulation only, live is gated behind a separate paid component, and no order routes through a PitBridge server. ### AI trading guardrails: risk controls an LLM cannot override URL: https://pitbridge.com/learn/articles/ai-trading-guardrails-llm-cannot-override/ Cluster: Guardrails and safety. Updated: 2026-07-10. Telling a model to respect a limit is advice it can ignore. A guardrail that runs out of process and checks every order before it reaches the platform is a control. This is the whole safety kernel: twelve controls, one frozen pipeline, and a tool surface with no path to weaken itself. Q: What are AI trading guardrails? A: They are runtime controls that check every order an agent tries to place, running in a separate process from the model. Unlike instructions in a system prompt, they are not advice the model can talk itself past. They adjudicate the order deterministically and return allow or block before anything reaches the account. Q: Can I not just tell the model its limits in the system prompt? A: You can, and you should give it context. But a system prompt is advisory. A model can still generate an out-of-bounds tool call through a mistake, a misread, or an adversarial input. A prompt is guidance, not enforcement. Q: What makes a guardrail one the model cannot override? A: It runs in a separate process, outside the model's context, and it adjudicates every order deterministically. The model can only propose a tool call. It has no path to change or skip the check that runs after, and its tool surface has no function to weaken a limit. Q: Can an agent turn its own guardrails off? A: No. The agent has exactly nine tools, and none of them release the kill switch, arm live trading, or change a limit. The configuration and the kill and arm controls live on an operator-only CLI the model never touches. The operator can change a limit; the order-placing agent cannot. Q: Do guardrails prevent losses? A: No. Guardrails enforce the limits you configure, such as a maximum position or a daily loss halt. They do not predict the market and they do not promise a result. Markets can still move against an order that was fully within your limits. Q: What is a kill switch in automated trading? A: It is a preset halt on new entries that you can trigger at any time. In PitBridge it is file-backed, so a person can engage it even if the daemon is wedged, and it can only be released from the CLI. De-risking such as cancel, close, and flatten stays allowed while it is engaged, so you can always get flat. Q: How does a daily loss halt work? A: When the day's profit and loss, realized plus unrealized, reaches the floor you configured, new entries are blocked with DAILY_LOSS_HALT. With sticky day-halt on, the account stays shut until the ET session rollover even if the number later recovers. De-risking stays allowed. Q: Are these the same as SEC pre-trade risk controls? A: They are the same class of preset size and instrument check that broker market-access systems have long run before an order reaches an exchange. That is conceptual lineage, not a compliance claim. PitBridge is software you configure, and it makes no representation about any regulation. Q: What happens when a guardrail blocks an order? A: The order is not sent. The agent gets a structured result with blocked set true, a typed reason_code, and a detail string, never a raised exception, so it can read the reason and explain it. The whole decision is written to the audit log. ### What an AI trading kill switch must actually guarantee URL: https://pitbridge.com/learn/articles/ai-trading-kill-switch/ Cluster: Guardrails and safety. Updated: 2026-07-10. Any wrapper can print halted. A kill switch counts only if it is enforced outside the model, blocks every new order the moment it engages, keeps de-risking possible, survives a restart, and releases only by a human act that leaves a trail. This piece goes deep on that one control and how PitBridge builds it. Q: What is a kill switch in AI trading? A: A preset halt on new orders that a person can trigger at any time, enforced outside the AI agent. In PitBridge it is file-backed: engaging it blocks every new entry with the KILL_SWITCH reason code while cancel, close, and flatten stay available, and only a human at the CLI can release it. It stops new orders; it does not promise anything about market outcomes. Q: Why must a trading kill switch run outside the model? A: Because a stop the model enforces on itself is advice, not a control. A language model can be talked out of an instruction or simply fail to follow it, and a halt flag inside the agent's own process stops working the moment that process misbehaves, which is exactly when you need it. PitBridge evaluates the kill switch first, in a deterministic engine in a separate process, so the refusal does not depend on the model's cooperation. Q: Can an AI agent release the kill switch? A: Not through PitBridge's agent surface. The nine MCP tools include no release, and the REST API can engage the kill but deliberately has no route to release it. Release is pitbridge unkill on the operator CLI. The agent can see the engaged state through get_guardrail_status; it has no function to change it. Q: Can I still close positions while the kill switch is engaged? A: Yes. De-risking is deliberately carved out: cancel_order, close_position, and flatten_account still work under an engaged kill, and close and flatten are reduce-only verbs, so they can only take exposure toward zero. The carve-out still honors the account mode and the daemon deny-list, and every de-risk action is written to the audit log. Q: Does the kill switch survive a daemon restart? A: Yes. Engaged means the kill file exists under the PitBridge home directory, so a restart changes nothing and the switch stays engaged until a person releases it. Since 0.2.2 the day ledger survives a restart too: day P&L, the sticky halt latch, and booked execution ids are restored on startup for the current trading date, so a mid-session restart does not forget the day's losses. Q: Does a kill switch prevent losses? A: No. It stops new orders from the moment it is engaged; it is not a promise about market outcomes. An open position keeps moving with the market until it is closed, which is why de-risking stays available under the kill. Guardrails enforce the limits you configure and do not predict anything. Futures trading carries substantial risk of loss. This is not financial advice. ### AI trading bot failure modes, and the control that catches each URL: https://pitbridge.com/learn/articles/ai-trading-bot-failure-modes/ Cluster: Guardrails and safety. Updated: 2026-07-12. Most writing about AI trading risk stays abstract. This is the concrete catalog: the specific ways an agent with order access goes wrong, from a duplicate submit on retry to a position book that quietly diverged from the broker, and for each failure the deterministic control that catches it, as actually built in PitBridge's executor, guardrail chain, and reconciler. These controls reduce named failure classes. They do not make trading safe, and they do not make it profitable. Q: What are the main failure modes of an AI trading bot? A: The recurring classes are: an order with the wrong size, side, or instrument; duplicate orders from a retry after a timeout; decisions made on stale account data; runaway order loops; a context hijacked by prompt injection in text the agent reads; and a position view that diverged from the broker after a disconnect or restart. Each one is mechanical, reproducible, and addressable with a specific control outside the model. Q: How do trading bots end up placing duplicate orders? A: Almost always through retry-on-timeout. The bot submits, hears nothing inside its timeout, assumes failure, and submits again, but the first order was alive at the broker all along. PitBridge layers two defenses: a DUPLICATE_ORDER guardrail that blocks a repeat of the same instrument, side, and quantity inside a configured window, and an idempotency layer where every order carries a daemon-generated client_order_id, duplicate ids are refused, and duplicate broker events are no-ops. Q: What is an idempotent client order id? A: A unique id the daemon generates per order intent, in PitBridge a UUID that becomes the NinjaTrader Order.Name, used as the single idempotency key for the order's whole lifecycle. The executor refuses to submit the same id twice, applies duplicate status events as no-ops, deduplicates fills by execution id, and never resurrects an order that reached a terminal state from a late or repeated frame. Q: Can prompt injection make an AI trading agent place bad orders? A: It can steer what the agent proposes. A trading agent reads text as part of the job, headlines, news summaries, research notes, and any of it can carry adversarial instructions the model cannot reliably separate from yours. The control is structural, not prompt hygiene: every proposed order is adjudicated by a deterministic engine outside the model, and the tool surface contains nothing that can change a limit, release the kill switch, or arm live trading. A hijacked session can propose; it cannot exceed. Q: How does a trading bot lose track of its position? A: By building its position view from the event stream and then missing events: a dropped connection loses fills, a restart loses in-memory state, and the bot then acts on a position that no longer exists. PitBridge treats the broker as the source of truth: on every reconnect it requests a snapshot, adopts the broker's positions over its own book, writes any divergence to the audit log as a position_mismatch entry, and marks in-flight orders the broker does not know about as CANCELLED rather than guessing or resubmitting. Q: Do these controls make AI trading safe or profitable? A: No, and it is important to say so plainly. Each control reduces one named failure class: duplicates, stale-data decisions, runaway loops, oversized orders, silent position drift. None of them evaluates whether a trade is wise, none predicts the market, and an order that passes every check can still lose money. Futures trading carries substantial risk of loss. This is not financial advice. ### Which futures prop firms allow automated trading? URL: https://pitbridge.com/learn/articles/which-futures-prop-firms-allow-automated-trading/ Cluster: Prop firm automation. Updated: 2026-07-05. There is no fixed list of firms that allow automation, because each firm sets its own rules and revises them. This is how to place your setup on the spectrum, the rule dimensions that decide whether it survives, what to verify in writing, and how software fits without making any promise about a given firm. Q: Is there a definitive list of prop firms that allow automated trading? A: No, and be wary of any page that presents one as settled fact. Firms set their own rules, distinguish evaluation from funded accounts, and change terms over time. The only reliable source is the firm's current written rules. Q: Does an AI agent count as automated trading to a prop firm? A: That depends entirely on the firm's definitions, which vary. Some firms treat any non-manual order as automation, some carve out semi-automated or assisted workflows. Most rulebooks predate agent workflows and do not name them at all, so ask support in writing how they classify an agent that proposes but does not auto-execute. Q: Can I run the same bot on multiple prop firm accounts? A: It depends on the firm, and copying your own accounts is often treated differently from copying someone else's. Multi-account caps and rules about holding a full-size and a micro contract on the same instrument can interact here. Verify the account-count cap and the copying rule per firm before you replicate anything. Q: Do prop firms allow TradingView or webhook automation? A: It depends on the firm and which platforms are in scope. Some route automation only through specific platforms, so a webhook that fits one firm may be outside another firm's named platform list. Verify which platforms the automation policy names before you wire anything up. Q: Can prop firms tell if I use a bot? A: Often yes. Log review flags machine-like patterns such as identical timestamps, zero-variance sizing, and sub-human entry speed. This matters even where automation is permitted, because a permitted bot still has to respect the consistency, news, and risk rules. Q: Is semi-automated trading allowed if the bot uses fully-automated logic underneath? A: The line is the firm's own definition, and it varies. Some firms require the trader to actively monitor and manually adjust, not just approve a queue. Get the definition of assisted or semi-automated in writing before you assume your setup qualifies. Q: Does automation change the rules between evaluation and funded accounts? A: It can. Some firms apply different automation language once you pass, so a policy that held during evaluation may not hold on the funded account. Re-verify the rule after you pass rather than assuming it carried over. Q: Are VPS or high-frequency strategies allowed for automated trading? A: Some firms restrict running your automation on a VPS, and some ban latency-arbitrage or high-frequency patterns outright. These are commonly-overlooked clauses. Verify VPS and high-frequency use explicitly, in the firm's own words. Q: Can software make me follow a prop firm's rules? A: Software can enforce limits you configure, such as a maximum position or a daily loss cap, and keep an audit log. It cannot know a firm's rules for you or promise any outcome with that firm. You map the rules you have verified into settings. Q: How often do these rules change? A: Often enough that a rule you read six months ago may be stale. Treat every automation policy as a living document and re-check it before you rely on it, especially after a firm updates its platform or account types. ### Prop firm automation rules for AI agents and trading bots URL: https://pitbridge.com/learn/articles/prop-firm-automation-rules/ Cluster: Prop firm automation. Updated: 2026-07-10. Whether you can run a trading bot or an AI agent on a prop firm account is a question only your firm's written rules can answer, and firms disagree with each other and change over time. This is about staying inside those rules, not around them: how to find and read the policy, why the evaluation phase is where automation trips most, and how a guardrailed bridge helps you enforce the limits you are allowed to trade within. Q: Can I run a trading bot or AI agent on a prop firm challenge? A: It depends entirely on that firm's written rules, and firms disagree. Some prohibit automated or agent-driven order entry, some permit it with conditions, and the terms change. The rules can also differ between the evaluation and a funded account. Read the firm's current policy, get anything ambiguous confirmed in writing, and treat that as your record. PitBridge does not know or bypass any firm's automation policy; you are responsible for staying inside it. Q: Where do I find my prop firm's automation rules? A: In the rulebook, the terms of service, and the FAQ, not the marketing page. Read the definitions section, because that is where automated, algorithmic, and copy trading get defined, and the definition decides whether your setup is in scope. Where the wording is silent or vague, email support with a specific question and keep the dated reply. Q: Do the rules differ between the challenge and a funded account? A: They can. Some firms apply different automation language once you pass, so a policy that held during the evaluation may not hold on the funded account. Re-verify the rule after you pass rather than assuming it carried over, and re-check after any platform or account change. Q: Does PitBridge make me compliant or help me pass the challenge? A: No. No firm certifies PitBridge, running it does not make your trading acceptable to any firm, and it makes no promise that you will pass an evaluation or keep an account. It enforces the numeric limits you enter. Whether those match your firm's current rules, and whether your firm allows automation at all, are yours to confirm. Q: Can a guardrail bypass a prop firm's rule? A: No, and that is the point. A guardrail is a limit, not a workaround. PitBridge cannot read, know, or evade a firm's automation policy. What it can do is refuse orders that break the numeric limits you configured from rules you verified, so your automation stays inside a boundary you set. Q: Which prop rules can software actually enforce? A: The ones that reduce to a check at order time: a daily loss limit, a maximum position or per-order size, an instrument allowlist, session hours, and order rate. Rules that depend on end-of-day balance history, consistency across days, or the firm's own dashboards live with the firm, not in the bridge. Q: Is automated trading against prop firm rules? A: Not inherently, and not universally. It is a per-firm question. Treat any blanket yes or no you read online as unreliable and go to your firm's own current rules. This piece is about trading within whatever those rules permit, never about getting around them. ### What a trading MCP server does URL: https://pitbridge.com/learn/articles/what-is-a-trading-mcp-server/ Cluster: MCP and AI agent infrastructure. Updated: 2026-07-05. A trading MCP server turns account actions into typed tools an AI agent can call. This is the protocol under the tools, the nine v0 tools, the two transports, the guardrail reason codes, the security model, and a worked example you can run on a Mac. Q: Is a trading MCP server the same as a trading bot? A: No. An MCP server is a set of typed tools plus a transport. It does not decide when to trade. An agent connected to it decides, and in PitBridge every place_order still passes the guardrail engine before it reaches the platform. Q: Do I need to write code to use one? A: Not for a standard client. An MCP client like Claude Desktop or Claude Code connects with a small config block. Custom code can also call a server directly; PitBridge serves MCP over stdio today, with streamable HTTP on the roadmap, and offers a localhost REST API meanwhile. Q: Where do the guardrails run? A: In PitBridge the MCP server, the guardrail engine and your keys sit in the same local daemon. The order route never leaves your machine, so the checks cannot be skipped by a network hop. Q: Can I give an agent read-only access? A: Yes. Tool permissions and account modes let you expose read tools like get_positions while withholding place_order, or point the whole session at a paper account first. Q: Can the agent disable the guardrails or raise a limit? A: No. There is no tool for it. Config values, the kill switch and the arm-live step are operator-only on the CLI, off the agent surface entirely, so a compromised or misled agent cannot widen its own authority. Q: What is the difference between the stdio and HTTP transport? A: It is about who launches the server and how the client reaches it. Over stdio the client launches the server as a local subprocess; over streamable HTTP the client connects to a local port. The tools are the same either way. PitBridge serves stdio today; streamable HTTP is on its roadmap. Q: Does the agent get live market data through these tools? A: No. The v0 surface exposes no market-data tool. The agent brings its own data, and the server is only the account action surface. Its job is reading account state and proposing orders, not quoting the market. ### MCP vs webhooks for trading automation URL: https://pitbridge.com/learn/articles/mcp-vs-webhooks-for-trading-automation/ Cluster: MCP and AI agent infrastructure. Updated: 2026-07-05. A webhook fires a fixed order when an event happens. MCP lets an agent read live state and decide what to do next. This is how they differ, where each one wins, how each fails, and why the guardrails belong in the same place either way. Q: Are webhooks worse than MCP for trading? A: No. A webhook is a good fit for a fixed rule where one event should fire one order. MCP fits an agent that reasons over live state. They solve different shapes of problem, so the right choice depends on what is driving the account. Q: Which is faster, a webhook or an MCP agent? A: A webhook is faster and its latency is fixed: one event, one HTTP call, no model in the path. An MCP agent reads state and decides, so it adds a reasoning step. For a purely mechanical trigger, that speed gap is a real reason to keep the webhook. Q: What happens if a webhook fires the same order twice? A: At-least-once delivery means a timed-out retry can re-send an order. The defense is a deterministic duplicate check between the receiver and the platform. The PitBridge duplicate-protection guardrail rejects a repeat of the same account, instrument, side and quantity inside its window with a DUPLICATE_ORDER code. Q: Can I keep my existing webhook alerts and add an agent later? A: Yes. The two can coexist. Many traders keep simple alert-driven webhooks for fixed triggers and use an MCP agent for the parts that need judgment over current positions and risk. Q: Is an MCP agent just a trading bot with extra steps? A: No. The agent proposes orders as tool calls, a separate guardrail engine on your machine decides which reach the platform, and the agent has no tool to disable a limit, release the kill switch, or arm live. It is a bridge with a checkpoint, not an autonomous system. Q: Where should risk checks run with a webhook? A: In whatever receives the webhook. A raw webhook carries a payload straight to an order route, so if there is no deterministic check between the receiver and the platform, there is no enforced limit. Q: Does PitBridge accept webhooks? A: PitBridge leads with an MCP server for agent-driven automation and also exposes a local REST place_order route, so a receiver you run can call the same pipeline. Whichever transport drives an order, the design goal is the same: a deterministic guardrail check on your machine before the order reaches the platform. ### Read-only, paper and live modes for an AI trading agent URL: https://pitbridge.com/learn/articles/read-only-paper-live-modes-trading-agents/ Cluster: MCP and AI agent infrastructure. Updated: 2026-07-20. A trading agent should not touch a real account on day one. PitBridge runs each account in one of three permission modes, read-only, paper or live, and a fresh install is paper only. Promoting to live is an operator step at the command line that the agent cannot take itself. Q: What mode does a fresh install start in? A: Paper. A new install runs in paper mode with every guardrail on and live execution locked. It can exercise the full safety kernel against a simulation account, but it cannot place a real order until an operator arms live at the command line. Q: Can the agent switch itself from paper to live? A: No. There is no MCP tool, REST call or config setting the agent can reach that promotes a mode. Arming live is a separate operator ritual at the command line, and in the open-source core it refuses because there is no live provider to arm. Q: What is the difference between read-only and paper mode? A: Read-only never mutates a broker at all, so it blocks even close and flatten, because those change a real position. Paper mode places orders freely against a simulation account, so an agent can trade a full session with no real money at risk. Q: Does read-only still let me see positions and P&L? A: Yes. Read-only permits every read tool: accounts, positions, orders, account state and guardrail status. It only refuses order-placing and position-changing tools, so an agent can watch and explain without touching anything. Q: How do I check which mode an account is in? A: Run pitbridge doctor. It prints a PASS, WARN or FAIL line per section, including each account's mode and the live gate, so you can confirm at a glance that live is locked before you connect an agent. Q: Is paper mode safe on a machine with a funded account configured? A: The mode is per account. A paper account cannot place a real order regardless of what else is configured, because the permission check runs before the order can reach the broker. Still, keep an agent on a simulation account until you have watched how it behaves. Q: What happens to an order the mode blocks? A: It is refused with a structured result and a reason code, and the refusal is written to the append-only audit log. The agent session survives the refusal, so a blocked order does not crash the run. ### CrossTrade MCP alternative: local-first vs a cloud bridge URL: https://pitbridge.com/learn/articles/crosstrade-mcp-alternative/ Cluster: Comparisons. Updated: 2026-07-10. CrossTrade puts a hosted MCP server in the cloud on its $99 Elite plan. PitBridge keeps the MCP server and the order path on your machine, for free, with a deterministic guardrail engine outside the model. Here is the honest, sourced comparison, including what CrossTrade does better. Q: What is the best CrossTrade MCP alternative? A: It depends on what you are optimizing for. If you want the order path and your keys on your own machine, hard limits enforced outside the model, and an MCP that costs nothing until you go live, a local-first bridge like PitBridge is the alternative. If you want a broad hosted suite with NinjaScript authoring, TradingView webhooks, and Tradovate, CrossTrade is built for that and a local-first bridge is not. Q: How much does CrossTrade's MCP server cost? A: As of 2026-07-09, CrossTrade's MCP server is on the Elite plan at $99 per month or $949 per year. The Standard plan is $29 and Pro is $49, neither of which includes MCP. Source: crosstrade.io/pricing. Pricing changes, so verify current details before deciding. PitBridge's MCP is free in the open core; you pay only to unlock live execution. Q: Is it safe to let an AI place orders? A: Only with a control the model cannot reach between it and the account. Safety instructions written into an agent's prompt are advice the model can be argued past. PitBridge runs the limits as a deterministic engine in a separate process, and no agent tool can weaken a limit, release the kill switch, or arm live. That separation is tested against prompt injection, not just asserted. Start on a simulation account regardless of which bridge you use. Q: Does my data leave my machine? A: With PitBridge, no. The daemon, the guardrail engine, and your credentials run on your own machine, and no order is relayed through a PitBridge server. With CrossTrade's MCP, agent instructions route through CrossTrade's cloud at app.crosstrade.io to reach the add-on in NinjaTrader 8, so the control path passes through their servers while execution lands locally. Source: crosstrade.io/mcp-trading, verified 2026-07-09. Q: Does it work with prop accounts? A: PitBridge enforces the limits you configure on any account you point it at, but it does not know or bypass any prop firm's automation policy. Some firms prohibit agent or automated order entry, some permit it with conditions, and the rules change. You are responsible for reading your firm's written rules and mapping them into your config. Verify with the firm before connecting anything to a funded account, whichever bridge you choose. Q: Does PitBridge replace CrossTrade? A: Not exactly. They aim at different jobs. CrossTrade is a broad hosted automation suite: webhooks, a trade copier, an account manager, NinjaScript authoring, and a hosted MCP. PitBridge is a narrow local-first layer whose whole purpose is guardrails the order pipeline cannot skip. Some traders could reasonably run both. ## Links - Home: https://pitbridge.com/ - Quickstart: https://pitbridge.com/docs/quickstart/ (markdown: /docs/quickstart.md) - Pricing: https://pitbridge.com/pricing/ (markdown: /pricing.md) - NinjaTrader 8 MCP bridge: https://pitbridge.com/product/ninjatrader-8-ai-agent-bridge/ - Guardrails: https://pitbridge.com/product/guardrails/ (markdown: /product/guardrails.md) - Local-first bridge: https://pitbridge.com/product/local-first-trading-bridge/ - Security model: https://pitbridge.com/docs/security-model/ (markdown: /docs/security-model.md) - Trading AI guardrails: https://pitbridge.com/safety/trading-ai-guardrails/ - Prop firm compliance: https://pitbridge.com/safety/prop-firm-compliance/ - MCP for futures trading: https://pitbridge.com/learn/mcp-for-futures-trading/ - Compare vs CrossTrade: https://pitbridge.com/compare/pitbridge-vs-crosstrade/ (markdown: /compare/pitbridge-vs-crosstrade.md) - Open source: https://pitbridge.com/open-source/ - Changelog: https://pitbridge.com/changelog/ - Waitlist: https://pitbridge.com/waitlist/ - Source: https://github.com/ToolstackVault/pitbridge ## Legal PitBridge is trading infrastructure, not financial advice. Futures trading involves substantial risk of loss and is not suitable for every investor. Order examples on the site are hypothetical and use example configuration values. NinjaTrader is a registered trademark of NinjaTrader Group, LLC; PitBridge is an independent project and is not affiliated with, endorsed by, or sponsored by NinjaTrader Group, LLC.