Get Started

Authentication & Access

How your AI client authorizes with NinjaTrader and what it's allowed to do.
View as Markdown

Beta, pre-release. The NinjaTrader MCP server and its trading skills are in beta and aren’t yet generally available. The beta runs on Demo only, which trades simulated money. Live access opens later. Server hostnames, the tool set, the skills, and the onboarding flow may change before launch.

The NinjaTrader MCP server authorizes clients with OAuth 2.1. Your AI client never handles your password. You sign in to NinjaTrader in your browser and approve the connection, and the client receives a token it sends on every request. This is the same delegated-authentication model the Trade API uses for OAuth, adapted to the MCP discovery flow so compatible clients can connect with no manual configuration.

How authorization works

When your client first connects to the MCP server URL, it runs the standard MCP OAuth flow:

  1. Discovery. The client requests the server’s protected-resource metadata, defined by RFC 9728, and learns which NinjaTrader authorization server to use and which scope to request.
  2. Authorize. The client opens the NinjaTrader sign-in page in your browser. You log in and approve the connection.
  3. Token. NinjaTrader returns an access token bound to the MCP server. The client stores it and sends it as a Bearer token on every MCP request.
  4. Session. The server establishes a session for the connection and your agent can begin calling tools.

You don’t configure any of these endpoints yourself. A compliant MCP client handles discovery and the token exchange automatically once you provide the server URL. You must complete authorization in a desktop browser.

EnvironmentAuthorization server
Demohttps://demo.tradovateapi.com

The MCP server serves discovery at /.well-known/oauth-protected-resource and at the path-scoped /.well-known/oauth-protected-resource/mcp. The connection scope is mcp:connect. The server enforces fine-grained authorization per tool against your account’s permissions, described below.

Permissions and scopes

Connecting establishes that the client is you. What the connection may then do is what you approve on the consent screen: the Actions the agent can take and the Read access it can use—the same permission model used across the platform. Each tool declares the access it needs, and the server checks it on every call:

PermissionScopeUsed by
Trade: place, modify, and cancel orders and order strategiesOrders:FullAccessplace_order, modify_order, cancel_order, close_position
Manage Alerts: create, modify, and delete price alertsAlerts:FullAccesscreate_alert, list_alerts, dismiss_alert
Manage Risk Settings: modify risk parameters, position limits, and auto-liquidation settingsRisks:FullAccessupdate_risk_settings
View Profile: profile, devices, subscriptions, and propertiesUsers:Readuser_profile
View Fees: fee schedules, plans, and cost estimatesFees:ReadNo tool requires it today
Market Data: quotes, depth of market, charts, and historyPrices:Readmarket_snapshot, market_history, dom_snapshot, pulse, economic_calendar, earnings_calendar
View Orders: order history, fills, open orders, and order strategiesOrders:Readmy_portfolio, order_history, fill_history, order_details, estimate_order, orders resource
View Account: balances, margins, cash activity, and statementsAccounting:Readcash_history, daily_balance_history, performance_summary, timeline_report, timeline_details, account-list resource
View Positions: open positions, position history, and fill pairsPositions:Readmy_portfolio, position_history, close_position, positions resource
View Contracts: search and view instruments and product detailsContractLibrary:Readsearch_contracts, product-catalog and kalshi-events resources
View Alerts: price alerts configured on your accountAlerts:ReadCovered by Manage Alerts today
View Risk Settings: risk parameters, position limits, and auto-liquidation settingsRisks:Readrisk_settings

Some tools need two permissions: close_position needs both Trade and View Positions, and my_portfolio needs both View Positions and View Orders. Each manage permission includes its matching view access, so Trade satisfies View Orders, Manage Alerts satisfies View Alerts, and Manage Risk Settings satisfies View Risk Settings.

If your account lacks the access a tool requires, the server denies that tool’s call and hides the tool from your agent’s tool list. The rest of the connection keeps working. A small number of tools, such as describe and the service-status resource, require no special access.

Risk limits

The consent screen’s third group, Risk limits, doesn’t grant access—it caps how much trading the access you granted can do. All four limits are optional and off by default. The server stores them with this connection and checks them on every opening order the agent sends. Closing or flattening a position is always allowed. Limits count in whole contracts, and the server measures them against your entire account, so positions and working orders you create outside the agent consume the same budget.

LimitWhat it caps
Max total exposureYour worst-case open position across all products: the net position in each contract plus working orders on its heavier side, summed across contracts.
Max traded volumeContracts traded per exchange session. Buys, sells, and working orders all count, so a filled two-lot round trip uses four. The counter resets when each contract’s trading session rolls to the next trade date.
Per-product limitsThe same two caps, scoped to a single product.
Per-contract limitsThe same two caps, scoped to a single contract.

Per-product and per-contract limits double as an allowlist. As soon as you list any product or contract, the connection can open positions only in what you listed. The server rejects orders for anything else, even when you set no numeric cap.

When an order would exceed a limit, estimate_order reports it as not feasible, and place_order fails with an error that names the limit and the current value, so your agent sees exactly which cap it hit. Risk limits stack with your account-level risk settings: every check must pass, the most restrictive limit wins, and a connection limit can never loosen anything set on the account.

Your agent can’t read these limits ahead of time. The risk_settings tool returns account-level risk settings only, and no tool returns the connection’s risk limits. The rejection message is how the agent learns them. To review or change the configured values, open your authorized-apps settings.

Sessions

The server ties each session to your connection and keeps it alive while your agent is active. Sessions expire after about an hour of inactivity, after which your agent’s calls stop succeeding. If that happens, reconnect through your client to start a new session. See Troubleshooting.

Changing or revoking access

You stay in control after you approve the connection. From your authorized-apps settings you can:

  • Revoke the connection. Every request fails immediately, including token refresh.
  • Edit risk limits. Changes apply on the agent’s next tool call, with no re-approval needed.
  • Edit permissions. Changes apply when the client next refreshes its access token.

Security notes

  • Your agent authenticates as you. Treat a connected agent like a signed-in session: only connect clients you trust, and disconnect the server when you’re done.
  • Start on Demo. Authorize the Demo server first so any mistakes happen against simulated money.
  • Keep risk limits in place. Account-level risk settings, such as daily loss limits, auto-liquidation, and trailing drawdown, apply to orders placed through the MCP server just as they do elsewhere.
  • Cap the connection. Optional risk limits on the consent screen bound how much this agent can trade, independent of your account-level settings.
  • Live and Demo are separate. A token for one environment can’t access the other. See Environments.