What can you do with this server?

The tastytrade-mcp server connects an AI agent to the Tastytrade brokerage platform, enabling market scanning, options analysis, account management, and optional live trading. Read-Only Tools (Always Available) * get_connection_status — Check connectivity, verify credentials, and confirm active environment (sandbox vs. production) * get_market_overview — Scan symbols for IV rank/percentile, IV, beta, liquidity, earnings dates, and last trade price * get_option_chain — Retrieve full option chains (expirations, strikes, symbols) for equities or futures; supports live Greeks (delta, gamma, theta, IV) * get_strategies — Build delta-based iron condor candidates with live credit estimates, probability of profit, and four legs * get_account_info — View balances, buying power, and deployment metrics * get_positions — List open positions with quantities and P&L * list_accounts — List all accounts available to the authenticated session * get_working_orders — View live/unfilled working orders for an account * get_watchlists — Retrieve private watchlists (all or by name) Live Trading Tools (Only when ENABLE_LIVE_TRADING=true) * execute_trade — Place option orders (with dry-run validation and buying power checks) * adjust_order — Modify existing working orders * close_position — Close an open position * manage_watchlist — Create, update, or delete watchlists Safety Features: Live trading requires explicit opt-in (ENABLE_LIVE_TRADING=true) and dry_run=false; includes pre-flight validation, buying power buffer, account-wide deployment cap, and secure credential storage via OS keyring.

How do I use tastytrade-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tastytrade-mcp Show me my account summary and open positions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tastytrade-mcp

by joncovington

Overview Schema Source Related Servers Discussions Admin

Python

Remote

tastytrade-mcp

An MCP server that lets an autonomous AI agent (Claude, etc.) connect to Tastytrade — scan markets, build option strategies, inspect accounts/positions/orders, and (optionally) place and manage trades.

OAuth2 authentication via the official tastytrade Python SDK (session tokens auto-refresh; refresh tokens are long-lived).
Credentials stored in the OS keyring (Windows Credential Manager / DPAPI, macOS Keychain, Linux Secret Service) — never in files, never in env vars, never logged.
Live trading is gated behind ENABLE_LIVE_TRADING — disabled by default so an agent cannot place real orders without an explicit opt-in.
stdio transport by default; optional HTTP transport hardened with CORS and per-IP rate limiting.

Install

pip install -e .          # or: pip install -e .[dev] for tests

Related MCP server: tastytrade-mcp

1. Create a Tastytrade OAuth application

In the Tastytrade web app, open Manage → My Profile → API → OAuth Applications.
Create an application, select the scopes you need (read + trading), and add http://localhost:8000 as a valid redirect/callback URI.
Save the client secret (shown once).
Create a grant to obtain a long-lived refresh token.

Never paste secrets into code, .env, or version control.

2. Store credentials in the keyring

tastytrade-mcp secrets set
tastytrade-mcp secrets status

You'll be prompted (hidden input) for the client secret, refresh token, and an optional default account number. secrets status also shows which keyring backend is active — useful for diagnosing credential issues on a new machine.

Headless Linux (servers, Docker, CI)

Desktop Linux uses GNOME Keyring or KWallet. On headless systems (no desktop daemon) the native backend is unavailable. Install the encrypted-file fallback:

pip install 'tastytrade-mcp[headless]'
export PYTHON_KEYRING_BACKEND=keyrings.alt.file.EncryptedKeyring
tastytrade-mcp secrets set

EncryptedKeyring stores secrets in ~/.local/share/python_keyring/cryptedpass.cfg encrypted with a master password you set on first use. Keep this file out of version control. PYTHON_KEYRING_BACKEND selects the backend only; it is not a secret.

3. Configure

Copy .env.example to .env and adjust. Key flags:

Variable	Default	Meaning
`ENABLE_LIVE_TRADING`	`false`	Register order-placing tools
`FORCE_DRY_RUN`	`false`	Force all orders to dry-run (propose-only mode)
`BUYING_POWER_BUFFER_PCT`	`0`	Percent of buying power always kept in reserve (per order)
`ACCOUNT_DEPLOY_LIMIT_PCT`	`0`	Account-wide cap on deployed buying power (from live positions)
`MCP_CORS_ORIGIN`	`http://localhost:3333`	Allowed CORS origin (HTTP transport)
`MCP_RATE_LIMIT`	`120/minute`	Per-IP rate limit (HTTP transport)
`MCP_HTTP_HOST` / `MCP_HTTP_PORT`	`127.0.0.1` / `7698`	HTTP bind address

4. Run

tastytrade-mcp                    # stdio (default)
tastytrade-mcp --transport http   # HTTP, CORS + rate limited

Connect an agent (stdio)

Claude Desktop / Claude Code MCP config:

{
  "mcpServers": {
    "tastytrade": {
      "command": "tastytrade-mcp"
    }
  }
}

Tools

Always available (read-only): get_connection_status, get_market_overview, get_option_chain, get_strategies, get_account_info, get_positions, list_accounts, get_working_orders, get_watchlists.

Only when ENABLE_LIVE_TRADING=true: execute_trade, adjust_order, close_position, manage_watchlist. Order tools default to dry_run=true (validate without submitting).

Underlying last price

get_market_overview now includes a last field (most recent trade price from DXLink) alongside the IV metrics for each symbol. Pass it directly as around_price in get_strategies and get_option_chain:

get_market_overview({ "symbols": ["XSP"] })
// -> { "ok": true, "metrics": [{ "symbol": "XSP", "last": 736.55,
//      "implied_volatility_index_rank": "0.48", ... }] }

last is streamed in parallel with the metrics fetch (best-effort, 4 s timeout). It is omitted per symbol when the DXLink feed is unavailable — fall back to the ATM strike from get_option_chain in that case.

Futures options

Both get_option_chain and get_strategies work with futures-options underlyings. Pass the futures root symbol prefixed with /:

get_option_chain({ "symbol": "/ES", "expiration": "2026-06-27",
                   "include_greeks": true, "around_price": 5650.0 })

get_strategies({ "symbol": "/ES", "target_dte": 0, "short_delta": 0.10,
                 "wing_width": 25, "around_price": 5650.0 })

The response shape is identical to equity options. instrument_type on each leg will be "Future Option" instead of "Equity Option" — use the correct value when constructing order legs for execute_trade. contract_multiplier in the get_strategies response reflects the option-to-futures ratio (typically 1.0); the dollar value per point depends on the underlying futures contract's own multiplier (e.g. $50/point for /ES, $5/point for /MES) — verify before sizing.

Delta-based iron condor construction

get_strategies builds a complete iron condor candidate with live credit and POP estimates. Pass around_price (the underlying's last price from get_market_overview) so strike selection uses live greeks from the DXLink feed — without it, the tool cannot center its greeks window and falls back to a positional heuristic that will pick the wrong strikes on large chains (e.g. XSP, SPX):

get_strategies({
  "symbol": "XSP",
  "target_dte": 0,
  "short_delta": 0.15,
  "wing_width": 5,
  "around_price": 738.50    // always pass — required for delta-accurate strikes
})
// -> {
//   "ok": true,
//   "strategy": "iron_condor",
//   "net_credit": 1.20,
//   "net_credit_per_contract": 120.0,
//   "estimated_pop": 0.70,
//   "quotes_complete": true,
//   "greeks_used_for_strike_selection": true,   // false = fell back to heuristic
//   "legs": {
//     "short_put":  { "strike_price": "736", "symbol": "XSP...P736", ... },
//     "long_put":   { "strike_price": "731", "symbol": "XSP...P731", ... },
//     "short_call": { "strike_price": "739", "symbol": "XSP...C739", ... },
//     "long_call":  { "strike_price": "744", "symbol": "XSP...C744", ... }
//   }
// }

greeks_used_for_strike_selection — check this field before acting on the result. When false, the greeks feed was unavailable and the tool fell back to picking the lower/upper third of the full strike list, which is rarely the right delta on a large chain. Cross-check the returned strikes against get_option_chain deltas before entry.

quotes_complete — when false, net_credit is null (the DXLink quote feed was temporarily unavailable). Do not estimate credit from strike prices; retry next iteration.

Per-strike greeks on the option chain

get_option_chain returns instrument fields per strike by default. Pass include_greeks=true to merge live delta, gamma, theta, and iv (annualized implied volatility) into each strike — useful for verifying strike placement, detecting put/call skew from per-strike IV, and assessing 0DTE gamma risk:

get_option_chain({
  "symbol": "XSP",
  "expiration": "2026-06-20",   // recommended with greeks (bounds the fetch)
  "include_greeks": true,
  "strike_count": 15,           // ATM window: 15 strikes each side (default); null = full chain
  "around_price": 581.40,       // center on the underlying's last price
  "greeks_timeout": 6.0
})
// -> chain[expiration] = [
//   { "strike_price": "580", "option_type": "Put", "symbol": "...",
//     "streamer_symbol": ".XSP...", "delta": -0.18, "gamma": 0.042,
//     "theta": -0.95, "iv": 0.187 }, ... ]

Greeks come from the DXLink streaming feed (not the chain endpoint), so this adds latency and is opt-in. With include_greeks and no expiration, the tool defaults to the nearest expiration to bound the subscription. An ATM window is applied by default (strike_count defaults to 15 strikes each side of the money, centered on around_price or the median strike) to keep the subscription small and fast; pass strike_count: null for the full chain. If the feed is slow or unavailable, the chain is still returned and greeks_complete / greeks_received report coverage rather than failing.

Order safety layers

A live order requires all of the following, so it cannot happen by accident:

ENABLE_LIVE_TRADING=true — otherwise the order tools are not registered at all.
FORCE_DRY_RUN=false — when set to true, every order is forced to dry-run regardless of what the agent requests ("propose-only" mode).
The agent explicitly passes dry_run=false on the call.

Before any submission, execute_trade / adjust_order run a pre-flight dry-run and validate buying power: the order is rejected if it would leave projected buying power below the required reserve (BUYING_POWER_BUFFER_PCT of current buying power; with the default 0 it only blocks orders that would go negative), or if the API returns errors. Rejections return {"ok": false, "error": "pre-flight validation failed", "problems": [...]} and nothing is submitted. The projected buying-power effect — including required_reserve and buffer_pct when a buffer is set — is returned on every call under "buying_power".

Account-wide deployment cap. ACCOUNT_DEPLOY_LIMIT_PCT adds a ceiling on total deployed buying power (vs. the per-order BUYING_POWER_BUFFER_PCT). It is derived from live account state — used_derivative_buying_power vs. derivative_buying_power — not an in-memory counter. Capacity = used + available; the limit is that percent of capacity, and an order is rejected if it would push deployed buying power past it. Because it reads the account each time, it counts buying power consumed by existing positions (even ones this server didn't place) and stays correct across restarts and multiple server instances. The figures (account_deployed_current, account_deployed_after, account_deploy_limit, account_buying_power_capacity) appear in the "buying_power" block.

Safety

Account numbers are masked in logs to the last 4 digits (****1234); secrets are never logged.
HTTP transport restricts CORS to a single configured origin and rate-limits to 120 requests/minute per IP (HTTP 429 when exceeded).

Development

pip install -e .[dev]
pytest                       # unit + integration tests (SDK mocked, no network)
pytest --cov                 # with coverage report

Live integration tests

A separate, opt-in suite hits the real Tastytrade API using your stored credentials to confirm the SDK + OAuth + API contract works end-to-end. It is skipped by default and never submits a real order (the test server runs with force_dry_run=true). To run it:

tastytrade-mcp secrets set     # if not already stored
RUN_LIVE=1 pytest -m live -v

Tests that depend on endpoints which are intermittently unavailable (e.g. /market-metrics) skip themselves on a 5xx rather than failing.

Disclaimer

This software can place real orders against a live brokerage account. It is provided "as is", with no warranty, and is not financial advice. You are solely responsible for any trades it places and any resulting losses. Review the order-safety controls above before enabling live trading. The built-in risk checks reduce — but do not eliminate — the risk of an unintended or oversized order.

This is an independent project and is not affiliated with, endorsed by, or sponsored by tastytrade. It uses the unofficial third-party tastytrade SDK.

License

Available Tools

9 tools

get_account_infoA

Retrieve account balances and buying power.

Args: account_number: Specific account to query. Defaults to the stored default account, or the first account on the session.

ParametersJSON Schema

Name	Required	Description	Default
`account_number`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states 'retrieve' implying a read operation but does not disclose any behavioral traits such as permissions needed, rate limits, or side effects. Missing disclosure beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus an Args block, concise and front-loaded with the core purpose. Every sentence adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 optional param, no required, output schema exists), the description covers the return (balances and buying power) and parameter behavior. It is complete enough for an agent to understand the tool's function, though it omits potential error cases or multi-account handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter with no description (0% coverage). The description compensates by explaining the default behavior: 'Defaults to the stored default account, or the first account on the session.' This adds semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Retrieve account balances and buying power', which is a specific verb+resource combination. This distinguishes it from siblings like get_positions (positions) and get_working_orders (orders).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like list_accounts. The description only explains default behavior for the optional account_number parameter but does not provide usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_connection_statusA

Check Tastytrade connectivity and report environment configuration.

Returns whether credentials are present, the active environment (sandbox vs production), whether live trading is enabled, and how many accounts the session can see.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes return values (credentials, environment, live trading, accounts) but does not disclose side effects, authentication requirements, or potential errors. It implies a read-only check, but lacks explicit safety guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. First sentence states purpose, second details output. No extraneous words. Excellent front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description adequately covers the tool's purpose and return values. Missing potential context about errors, authentication state, or rate limits, but these are minor for a simple status check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Description adds no parameter information, but none is needed. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verb 'Check' and 'report', identifies resource 'Tastytrade connectivity' and 'environment configuration'. Clearly distinguishes from sibling tools like 'get_account_info' or 'get_positions' by focusing on connection status and session configuration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, common scenarios, or when not to use it. The description implicitly suggests it's for initial setup verification, but no explicit usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_market_overviewA

Scan symbols for market metrics.

Returns implied volatility rank/percentile, IV, beta, liquidity, and upcoming earnings (when available) for each underlying symbol.

Args: symbols: Underlying ticker symbols, e.g. ["SPY", "QQQ", "AAPL"].

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden but only discloses return metrics and notes that earnings are 'when available.' It does not mention rate limits, latency, or impact, which is acceptable for a simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the action, and structured with an Args section. Every sentence is relevant with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter) and the presence of an output schema (not shown), the description adequately covers the purpose and return values. Minor omission of error handling or special cases keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the 'symbols' parameter with an example format ('["SPY", "QQQ", "AAPL"]'), adding value beyond the schema's type definition. The context signal of 0% coverage likely conflicts with this, but the text itself provides sufficient clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans symbols for market metrics and lists specific metrics (IV, beta, liquidity, earnings). Although it does not explicitly differentiate from siblings, the function is distinct among the listed tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_option_chainA

Retrieve the option chain for an underlying symbol.

Returns expirations and strikes with their option symbols, grouped by expiration date.

Args: symbol: Underlying ticker symbol, e.g. "SPY".

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It implies a read operation but doesn't explicitly state it is non-destructive or mention any side effects. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise, no filler. Front-loaded with purpose and return structure. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter and existing output schema, the description sufficiently explains the tool's purpose and input. Could be improved with a note on data freshness or format, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter (symbol) has a description in the docstring with an example ('SPY'), adding value beyond the schema which has no description. Schema coverage is 0%, so description compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Retrieve the option chain for an underlying symbol' and explains what is returned (expirations, strikes, option symbols). This differentiates from sibling tools like get_positions or get_market_overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use or avoid this tool. No mention of alternatives or context where other tools might be better. The description lacks usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_positionsA

List open positions with quantities and P&L for an account.

Args: account_number: Specific account to query. Defaults to the stored default account, or the first account on the session.

ParametersJSON Schema

Name	Required	Description	Default
`account_number`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the schema by explaining the default behavior for account_number (stored default or first account on session). This adds useful behavioral context beyond a simple read operation, though it omits details like data freshness or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two lines), front-loads the core action, and includes parameter details in a structured Args block. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single optional parameter and existing output schema, the description covers core functionality, return values (quantities and P&L), and parameter behavior. Minor omissions (e.g., edge cases like no positions) prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by documenting the account_number parameter's semantics, including defaulting logic and the meaning of null. This provides essential information for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List', the resource 'open positions', and the scope 'for an account', making the tool's purpose specific and unambiguous. It distinguishes from sibling tools like get_account_info and get_working_orders by targeting positions data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., get_option_chain or get_working_orders). The description only states what it does, without providing context for selection or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_strategiesA

Build candidate iron condor setups for an underlying.

Selects an expiration near target_dte and proposes an iron condor with short strikes around the given target delta and the requested wing width. Returns the four legs (short/long put, short/long call) and an estimated probability of profit.

Args: symbol: Underlying ticker symbol, e.g. "SPY". target_dte: Desired days to expiration (default 45). wing_width: Distance in strikes between short and long legs. short_delta: Target absolute delta for the short strikes (~0.16 corresponds to roughly a 1-standard-deviation short strike).

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`target_dte`	No
`wing_width`	No
`short_delta`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the tool selects an expiration, proposes strikes based on target delta and wing width, returns four legs and probability of profit. No side effects or destructive behaviors are mentioned, which is appropriate for a read-only analytical tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear one-sentence purpose, a brief procedural paragraph, and an Args list. While it is longer than minimal, every part adds value, especially the parameter descriptions given zero schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of option strategies, the description covers the inputs, selection process, and output (four legs and probability of profit). An output schema exists, so return value details are not required. The description is sufficiently complete for an agent to understand and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes an Args section that explains each parameter in plain language, describing the role of symbol, target_dte, wing_width, and short_delta. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Build candidate iron condor setups for an underlying.' which clearly indicates the verb ('build') and resource ('iron condor setups'). This distinguishes it from sibling tools like get_option_chain or get_market_overview that provide raw market data rather than a specific strategy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how the tool selects parameters and returns an iron condor, implying usage for strategy generation. However, it does not explicitly state when to use this tool versus alternatives (e.g., when raw option chain data is needed) or provide any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_watchlistsA

Retrieve the user's private watchlists.

Args: name: If given, return only the watchlist with this name; otherwise return all private watchlists.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavior. It discloses the conditional behavior based on the 'name' parameter. However, it does not mention side effects, authorization, or error handling, which are minimal for a read operation. Scores 3 as minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence and a bullet-free parameter explanation. Every word is informative, and the action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, output schema present), the description covers the essential behavior: retrieving private watchlists with optional filtering. It is complete for the agent's understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 0%, so the description fully explains the single parameter 'name', including its effect (filter vs. all). This adds significant meaning beyond the schema's type information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retrieve') and the resource ('user's private watchlists'). It distinguishes itself from sibling tools like get_positions or get_account_info by specifying a unique resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description implies usage by context but lacks explicit conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_working_ordersA

List live (working / unfilled) orders for an account.

Args: account_number: Specific account to query. Defaults to the stored default account, or the first account on the session.

ParametersJSON Schema

Name	Required	Description	Default
`account_number`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the burden. 'List' clearly indicates a read-only operation with no side effects. It does not detail pagination, limits, or error behavior but is adequate for a simple list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then parameter details. The Args block is clear but slightly informal. No unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter list tool with an output schema, the description covers all necessary aspects. No missing information for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the tool’s description explains the sole parameter 'account_number' thoroughly, including default behavior. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'List', resource 'live (working / unfilled) orders', and scope 'for an account'. Distinguishes from siblings like get_positions which likely list filled positions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like get_positions or get_account_info. The default account behavior is noted but does not help in tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_accountsA

List all accounts available to the authenticated session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description implies a read-only, non-destructive operation but lacks details on authentication requirements, rate limits, or potential side effects. Adequate for a simple list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no unnecessary words. Highly concise and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and an existing output schema, the description is mostly complete. It could optionally mention the return type (e.g., list of account IDs), but given the output schema, it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The description adds value by specifying 'available to the authenticated session', which is a helpful qualifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and resource 'accounts' with the qualifier 'available to the authenticated session', clearly distinguishing it from sibling tools like get_account_info or get_positions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as get_account_info or other siblings. The description simply states what it does without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Jun 18, 2026
- First observedget_account_info
- First observedget_connection_status
- First observedget_market_overview
- First observedget_option_chain
- First observedget_positions
- First observedget_strategies
- First observedget_watchlists
- First observedget_working_orders
- First observedlist_accounts

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-06-18 09:15 across 9 tools

Disambiguation5/5

Each tool targets a distinct aspect: account info, connection status, market metrics, option chains, positions, strategy building, watchlists, orders, and account listing. No two tools have overlapping purposes, minimizing agent confusion.

Naming Consistency4/5

All tools use a consistent 'get_' prefix except 'list_accounts', which deviates. Additionally, 'get_strategies' implies retrieval but actually builds setups. Overall, the pattern is mostly uniform.

Tool Count5/5

With 9 tools, the set is well-scoped for a trading platform's core operations: account management, market data, options, positions, orders, and watchlists. Not excessive nor sparse.

Completeness2/5

The surface lacks critical trading actions like placing, modifying, or canceling orders. It also misses trade history and account transactions, making it incomplete for a trading platform's lifecycle.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
gainium-mcpOAuth
io.gainium
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Cryptocurrency Finance
22
Mudrex MCP Server
io.github.mudrex
MCP server for Mudrex futures trading enabling AI agents to securely access data and risk tools.
Finance Blockchain Cryptocurrency
2

Related MCP Servers

eToro MCP Server
Finance Cryptocurrency Social Media
ranjanvipul88
F
license
A
quality
D
maintenance
A security-hardened MCP server that wraps the eToro public API, enabling AI assistants to trade, access market data, manage portfolios, and interact with social feeds via 34 tools.
Updated 3 months ago (2026-06-10 17:09 UTC)
6
-
tastytrade-mcp
Finance Research & Data
bholzer
F
license
A
quality
D
maintenance
MCP server for the tastytrade brokerage API, providing tools for account management, market data, and order execution.
Updated 3 months ago (2026-06-10 18:42 UTC)
18
-
ibkr-mcp-server
Finance Research & Data
dapdevsoftware
A
license
Not graded
quality
D
maintenance
MCP server for Interactive Brokers that exposes portfolio data, market quotes, trading, and analysis to any MCP-compatible AI client, with support for EU investors and safety-gated trading.
Updated 7 months ago (2026-02-26 12:22 UTC)
1
MIT
cpzai-mcp-serverofficial
Finance Autonomous Agents
CPZ-Lab
A
license
Not graded
quality
D
maintenance
MCP server for CPZAI platform, enabling AI agents to manage trading strategies, run backtests, route orders across brokers, and access portfolios, risk analytics, and market data through natural language.
Updated 6 days ago (2026-09-15 09:27 UTC)
1
MIT

tastytrade-mcp

Install

1. Create a Tastytrade OAuth application

2. Store credentials in the keyring

Headless Linux (servers, Docker, CI)

3. Configure

4. Run

Connect an agent (stdio)

Tools

Underlying last price

Futures options

Delta-based iron condor construction

Per-strike greeks on the option chain

Order safety layers

Safety

Development

Live integration tests

Disclaimer

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

cpzai-mcp-serverofficial