What can you do with this server?

The mcp-tastytrade-server lets you manage your TastyTrade brokerage account, place trades, and retrieve market data through an MCP client. Key capabilities: * Account Management: list accounts, view balances & buying power, get open positions, retrieve transaction history (with date filtering and pagination), and access customer watchlists. * Order Management: view orders filtered by status (e.g., Live, Filled, Cancelled, Rejected); place live orders (Limit, Market, Stop, Stop Limit, Notional Market) for equities, equity options, futures, and future options; cancel orders; and validate orders without placing (dry_run_order) to check buying power impact, fees, and warnings. Option symbols are auto-formatted to OCC standard. * Market Data & Research: fetch option chains (nested by expiry or as a compact flat list); get market metrics (IV rank, IV percentile, 30-day IV, liquidity) for one or more symbols; search equities by symbol or partial term, optionally filtering by lendability (Easy To Borrow, Locate Required, Preborrow Required). * Security & Safety: uses OAuth2 (no password stored); supports a sandbox environment (TASTYTRADE_SANDBOX=true) for risk-free testing; dry-run orders let you preview costs and buying power effects before committing real capital.

How do I use mcp-tastytrade-server?

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., "@mcp-tastytrade-server show my 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.

mcp-tastytrade-server

by morsingnet

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mcp-tastytrade-server

An MCP server that exposes the TastyTrade brokerage API as tools for Claude and other MCP-compatible clients.

Features

Tool	Description
`get_accounts`	List all accounts
`get_positions`	Open positions for an account
`get_balances`	Balances and buying power
`get_orders`	Orders (filterable by status)
`dry_run_order`	Validate an order — fees, BP impact, warnings
`place_order`	Place a live order
`cancel_order`	Cancel a live order
`get_option_chain`	Option chain (nested by expiry or compact flat list)
`get_market_metrics`	IV rank, IV percentile, 30-day IV, liquidity
`get_transactions`	Transaction history
`search_equities`	Search equity instruments by symbol
`get_watchlists`	Customer watchlists

Related MCP server: TastyTrade MCP Server

Setup

1. Install dependencies

pip install -e .
# or with uv:
uv pip install -e .

2. OAuth2 setup

This server authenticates with OAuth2 — a scoped, revocable refresh token — instead of your TastyTrade account password. Your actual login credentials are never entered anywhere in this project.

Go to my.tastytrade.com → Manage → My Profile → API → OAuth Applications.
Click + New OAuth Client, give it any name, and set a redirect URI (e.g. http://localhost) — it's required but unused by the personal-grant flow below.
Save the app, then note the Client Secret shown (it's only displayed once).
Click Manage on the new app → Create Grant to issue yourself a Personal Grant. Copy the Refresh Token shown (also only displayed once).
Copy the env template and fill in those two values:

cp .env.example .env

Variable	Required	Description
`TASTYTRADE_CLIENT_SECRET`	Yes	Client secret from the OAuth application
`TASTYTRADE_REFRESH_TOKEN`	Yes	Refresh token from the personal grant
`TASTYTRADE_SANDBOX`	No	Set to `true` to use the certification environment (default: `false`)

The refresh token doesn't expire on its own — if you ever want to cut off access, revoke the grant at my.tastytrade.com and generate a new one, no password change required.

3. Test the connection

python scripts/smoke_test.py

This runs every read-only tool (get_accounts, get_balances, get_positions, get_orders, search_equities, get_market_metrics, get_option_chain, get_watchlists) through the same list_tools()/call_tool() interface a real MCP client uses, and prints PASS/FAIL for each. It never places or cancels orders. Requires .env to be filled in (step 2).

4. Configure Claude Desktop

Add the following to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "tastytrade": {
      "command": "mcp-tastytrade",
      "env": {
        "TASTYTRADE_CLIENT_SECRET": "your_client_secret",
        "TASTYTRADE_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

Or using uv run without installing:

{
  "mcpServers": {
    "tastytrade": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/mcp-tastytrade-server", "mcp-tastytrade"],
      "env": {
        "TASTYTRADE_CLIENT_SECRET": "your_client_secret",
        "TASTYTRADE_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

Option symbol format

Options use the OCC 21-character format: SYMBOL YYMMDDCPRICE

Examples:

AAPL 241220C00200000 — AAPL $200 call expiring 2024-12-20
SPY 241220P00580000 — SPY $580 put expiring 2024-12-20

The get_option_chain tool returns symbols already formatted correctly.

Development

# Run directly
python -m mcp_tastytrade.server

# Or via the installed script
mcp-tastytrade

Security

Authentication uses OAuth2 (client secret + refresh token) — your TastyTrade account password is never used or stored anywhere in this project.
Credentials are passed via environment variables only.
The .env file is in .gitignore and must never be committed.
Access tokens are short-lived (~15 minutes), held in memory only, and refreshed automatically.
To revoke access at any time, delete the grant at my.tastytrade.com — no password change needed.
Use TASTYTRADE_SANDBOX=true for testing — the certification environment uses separate accounts with no real money.

Available Tools

12 tools

cancel_orderC

Cancel a live order on a TastyTrade account.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes	The numeric order ID to cancel
`account_number`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as side effects, reversibility, immediacy, or validation. For a cancellation tool, important context is missing.

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 a single sentence with 9 words, no redundant or extraneous content. It is efficiently structured but may be too sparse given the tool's significance.

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

Completeness2/5

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

With no output schema and no annotations, the description is incomplete. It does not mention success/failure indicators, error cases, or order status requirements.

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

Parameters2/5

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

Schema description coverage is 50% (account_number lacks description), and the tool description does not add any meaning beyond what the schema provides. It does not compensate for the missing parameter 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 uses the verb 'cancel' and specifies the resource 'a live order on a TastyTrade account'. It clearly distinguishes from sibling tools like 'place_order' and 'get_orders' by indicating a different action.

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 vs alternatives. It does not mention prerequisites (e.g., order must be live and not already cancelled) or exclusions.

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

dry_run_orderA

Validate an order without placing it. Returns buying power effect, fees, and any warnings.

ParametersJSON Schema

Name	Required	Description	Default
`legs`	Yes
`price`	No
`order_type`	Yes
`price_effect`	Yes
`time_in_force`	Yes
`account_number`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It clearly states this is a non-mutating validation (dry run) and lists what is returned (effect, fees, warnings). However, it does not mention failure modes or constraints like 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 extremely concise with two sentences. The first sentence states the purpose, the second lists outputs. No redundant information.

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

Completeness2/5

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

Given the tool's complexity (6 params, nested 'legs' array, 5 required), the description is insufficient. It omits details on parameter semantics, relationships, and how to construct valid input. The output schema is missing, leaving the agent without return structure guidance.

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

Parameters1/5

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

Schema coverage is 0% — the description adds no meaning to any of the 6 parameters. It fails to explain the critical 'legs' nested object or the purpose of 'price_effect', which is essential 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 'validate', the resource 'order', and explicitly distinguishes from placement by saying 'without placing it'. It also lists the returned values: buying power effect, fees, and warnings.

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 implies usage for order validation before placement but provides no explicit guidance on when to use it versus alternatives like place_order or cancel_order. No comparisons or exclusions are given.

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

get_accountsA

List all TastyTrade accounts for the authenticated customer.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It states the tool lists accounts but does not elaborate on authentication requirements (though implied), rate limits, or any side effects. It is adequate for a simple read-only tool but lacks depth.

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 a single, clear sentence with no unnecessary words. It efficiently conveys 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?

Given the tool's simplicity (no parameters, no output schema), the description is mostly sufficient. However, it could briefly mention that the output is a list of account objects or any implicit filtering. Slight lack of detail prevents a perfect score.

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?

No parameters exist in the input schema, so schema coverage is 100% (vacuously). The description adds no parameter information, but with zero parameters the baseline is 4.

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 'List all TastyTrade accounts for the authenticated customer', specifying the verb 'list', the resource 'accounts', and the scope 'for the authenticated customer'. This distinguishes it from sibling tools like get_positions or get_balances.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools for related tasks.

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

get_balancesC

Get current balances and buying power for a TastyTrade account.

ParametersJSON Schema

Name	Required	Description	Default
`account_number`	Yes

TDQS

C2.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 full burden. It only states the function without disclosing behavioral traits like whether it is read-only, requires authentication, or has side effects.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose. However, it is slightly under-specified for a production tool.

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

Completeness2/5

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

Given the single parameter and no output schema, the description is incomplete. It lacks usage guidelines and parameter details, providing only minimal context for an agent to correctly invoke the tool.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning beyond the parameter name 'account_number'. It does not explain what the parameter represents or how to obtain it, failing to compensate for missing schema descriptions.

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 retrieves current balances and buying power for a TastyTrade account, specifying the verb 'Get' and resource 'balances and buying power'. It distinguishes from sibling tools like get_accounts that list accounts, but does not explicitly differentiate.

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 over siblings. It does not specify prerequisites, exclusions, or alternative tools, making it difficult for an agent to decide when to invoke this vs. other account-related tools.

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

get_market_metricsB

Get market metrics for one or more symbols: IV rank, IV percentile, 30-day IV, liquidity rating, and more.

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes	Underlying symbols, e.g. ['AAPL', 'SPY', 'QQQ']

TDQS

B3.4/5.0

Behavior3/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 indicates a read operation ('Get') and lists some output fields, but does not disclose additional behaviors like data freshness, rate limits, or required permissions. This is adequate but not thorough.

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 a single, concise sentence that front-loads the verb and resource. It lists specific metrics efficiently. There is no wasted text.

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 there is no output schema, the description compensates by listing the included metrics (IV rank, IV percentile, etc.). It covers the main use case of retrieving multiple metrics for symbols. It does not explain the return format or error handling, but is sufficient for basic understanding.

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?

Schema coverage is 100% and the description adds 'for one or more symbols' matching the parameter's purpose. The schema itself already describes the 'symbols' parameter with an example. The description does not add new semantics beyond what is in the schema, so baseline 3 is appropriate.

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 verb 'Get', the resource 'market metrics', and specifies the scope 'for one or more symbols'. It also lists specific metrics like IV rank, IV percentile, etc., providing a clear purpose. However, it does not distinguish this tool from siblings like get_option_chain or search_equities.

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 given on when to use this tool versus alternatives. The description implies it is for retrieving market metrics, but does not specify prerequisites or exclusions compared to sibling tools such as get_positions or get_balances.

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

get_option_chainA

Get the option chain for an underlying symbol. Use format='nested' (default) for expirations grouped by date, or format='compact' for a flat list.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No		nested
`symbol`	Yes	Underlying symbol, e.g. 'AAPL'

TDQS

A4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions the data retrieval nature implicitly and describes format behavior. It lacks explicit statements about read-only status, error handling for invalid symbols, or any side effects. More transparency would be beneficial.

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: two short sentences that convey the core purpose and key parameter guidance. Every word earns its place with no redundancy or unnecessary information.

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 (two parameters, no output schema), the description covers the essential aspects. It could mention the structure of the returned data or that it's a read-only operation, but the lack of such details does not significantly impair an agent's ability to use the tool correctly.

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 covers symbol with an example, but format lacks description. The description adds value by explaining the effect of each format option ('grouped by date' vs 'flat list'), which compensates for the missing schema description. With 50% schema coverage, the description meaningfully enriches parameter understanding.

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 ('Get') and the resource ('option chain for an underlying symbol'), making the tool's purpose unambiguous. Among sibling tools focused on accounts, orders, and watchlists, this tool is distinct and appropriately named.

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

Usage Guidelines4/5

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

The description explains the two format options and their effects ('nested' for grouping by date, 'compact' for flat list), guiding usage. However, it does not explicitly state when not to use this tool or mention alternatives, though no obvious alternatives exist among siblings.

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

get_ordersC

Get orders for a TastyTrade account, optionally filtered by status.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter by order status
`account_number`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must reveal behaviors. It only states basic purpose, omitting details like pagination, rate limits, authentication needs, or data scope.

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?

Single sentence, no redundancy. Could be slightly improved by front-loading key constraints, but effective for length.

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

Completeness2/5

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

With no output schema, no annotations, and minimal description, the tool lacks critical context about return format, pagination, or error handling.

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

Parameters2/5

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

Schema coverage is 50% (only status has description). The description reiterates the optional status filter but adds no meaning for the required account_number parameter.

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 the verb 'Get', resource 'orders', context 'TastyTrade account', and optional filter by status. Distinguishes from sibling tools like get_positions or place_order.

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 (e.g., get_transactions for financial details). No exclusions or prerequisites mentioned.

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

get_positionsB

Get current open positions for a TastyTrade account.

ParametersJSON Schema

Name	Required	Description	Default
`account_number`	Yes	Account number (e.g. 5WX12345)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states 'Get current open positions' without mentioning side effects, permissions, data freshness, or error conditions.

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 a single, focused sentence with no unnecessary words, efficiently conveying the tool's purpose.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description is adequate but lacks details about the response format or handling of edge cases (e.g., no open positions).

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?

Schema coverage is 100%, with the parameter 'account_number' documented well in the schema. The description adds no additional meaning beyond the schema, meeting the baseline.

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 'Get current open positions for a TastyTrade account' with a specific verb, resource, and domain, distinguishing it from siblings like get_accounts or get_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 usage guidelines or when-to-use vs alternatives are provided. The description lacks context about prerequisites or scenarios where this tool is appropriate.

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

get_transactionsC

Get transaction history for a TastyTrade account.

ParametersJSON Schema

Name	Required	Description
`end_date`	No	End date YYYY-MM-DD
`per_page`	No	Results per page (max 250, default 50)
`start_date`	No	Start date YYYY-MM-DD
`account_number`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It fails to mention pagination, sorting, data freshness, rate limits, or any side effects. Only the basic purpose is stated.

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 concise with one sentence containing the core purpose. However, it is overly brief, sacrificing necessary details.

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

Completeness2/5

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

No output schema exists, so description should explain return format. It does not describe what the transaction history contains, any filtering behavior, or output structure. Not complete for a tool with 4 parameters.

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?

Schema coverage is 75%, and the description does not add meaning beyond the schema. The account_number parameter lacks a description both in schema and description. Other parameters have adequate descriptions in schema.

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 retrieves transaction history for a TastyTrade account. It uses specific verb and resource, and is distinct from sibling tools like get_accounts 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 on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The description lacks context for agent decision-making.

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

get_watchlistsA

Get all watchlists for the authenticated customer.

ParametersJSON Schema

Name	Required	Description	Default
No 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 carries the full burden. It states the action and scope but does not disclose any behavioral traits such as authentication requirements, rate limits, or what happens with empty results.

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 a single, front-loaded sentence with no unnecessary words. Every word adds value.

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

Completeness3/5

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

Given no output schema or annotations, the description is minimal. It covers the basic purpose but lacks detail on return format or edge cases. For a simple tool, it is adequate but not 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?

There are no parameters, so baseline is 4. The description adds no extra parameter info, but none is needed since the schema covers 100% with zero parameters.

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 'Get' and the resource 'watchlists', specifying scope 'for the authenticated customer', distinguishing it from sibling tools like get_accounts 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 Guidelines3/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. The usage is implied as a simple retrieval, but no exclusions or alternative suggestions are provided.

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

place_orderB

Place a new order on a TastyTrade account. Use dry_run_order first to validate the order and check buying power impact.

ParametersJSON Schema

Name	Required	Description
`legs`	Yes
`price`	No	Limit price as a string (e.g. '1.50'). Required for Limit orders.
`order_type`	Yes
`price_effect`	Yes	Debit = you pay; Credit = you receive.
`time_in_force`	Yes
`account_number`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It implies mutation ('Place a new order') but fails to disclose idempotency, error handling, or consequences. Minimal behavioral insight beyond the action itself.

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 sentences, front-loaded with main action, no waste. Efficiently conveys core purpose and a key usage tip.

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

Completeness2/5

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

Lacks output description, no guidance on return values (e.g., order ID). Complex inputs (legs array) are not elaborated, leaving the agent underinformed for correct invocation.

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

Parameters1/5

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

Schema coverage is low (33%), and the description adds no parameter details. It does not explain account_number, legs, or other fields beyond what is in the schema, missing an opportunity to compensate.

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 'Place' and resource 'new order' on 'TastyTrade account', effectively distinguishing it from sibling tools like cancel_order or get_orders.

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

Usage Guidelines4/5

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

Explicitly advises using dry_run_order first for validation, providing clear context for when to use this tool vs. its sibling. However, no when-not conditions are given.

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

search_equitiesC

Search for equity instruments by symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Symbol or partial symbol to search
`lendability`	No	Filter by short-sell lendability

TDQS

C2.9/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 full burden. It only says 'Search,' implying a read-only operation, but does not disclose potential rate limits, authentication requirements, or whether it returns only exact matches or partial matches. Minimal behavioral context.

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?

Single sentence that is front-loaded with the action and object. No redundant phrases. Could be slightly more detailed without losing conciseness, but currently efficient.

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

Completeness3/5

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

With no output schema, the description should hint at return format (e.g., list of symbols or full equity objects). It is adequate for a simple search but lacks completeness in specifying what the agent can expect after invocation.

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?

Schema description coverage is 100%, with both parameters well-documented: 'symbol' is described as 'Symbol or partial symbol to search' and 'lendability' has an enum and description. The description adds no extra meaning beyond the schema, meeting the baseline for full coverage.

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?

Description clearly states the tool searches for equity instruments by symbol. It distinguishes itself from sibling tools like get_accounts and get_positions, which are not search tools. However, it could be more specific about what is returned (e.g., list of matching equities).

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. While siblings are distinct, there is no mention of scenarios where search_equities is appropriate or when other tools might be better (e.g., using get_market_metrics for details).

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.

12 tool updatesv0.1.0Jul 28, 2026
- First observedcancel_order
- First observeddry_run_order
- First observedget_accounts
- First observedget_balances
- First observedget_market_metrics
- First observedget_option_chain
- First observedget_orders
- First observedget_positions
- First observedget_transactions
- First observedget_watchlists
- First observedplace_order
- First observedsearch_equities

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.5/5.0

Scored 2026-07-28 09:55 across 12 tools

Disambiguation5/5

Each tool has a distinct purpose clearly described. get_positions and get_balances are separate, place_order and dry_run_order are complementary but distinct, no overlapping functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores (e.g., get_accounts, cancel_order, dry_run_order). The verbs vary but are appropriate and predictable.

Tool Count5/5

12 tools cover the essential operations for a trading platform without being excessive. Each tool serves a clear need, and the count is within the ideal range.

Completeness4/5

Core workflows like account information, order management, and market data are covered. Minor gaps exist, such as no modify order or create watchlist, but agents can work around these with the available tools.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Light Horse SecuritiesOAuth
io.lighthorse
Agentic brokerage access to a US brokerage account: quotes, orders, positions, cash and documents.
Finance Payments & Billing
1
trayd-mcpOAuth
io.github.teamtrayd
Trade Robinhood through natural language in Claude Code.
Finance App Automation
242
mcp A
com.googleapis.stitch
Interact with the Stitch API using natural language commands.
Search App Automation
152
Gogi AOAuth
ai.gogi.api
Unified financial infrastructure connecting AI agents directly to trade live/demo brokerage accounts, Web3 non-custodial wallets, real-time market data across equities, ETFs, crypto, forex, options, DeFi swaps, and prediction markets, institutional research feeds, and algorithmic strategy backtesters.
Agent Orchestration AI & Machine Learning Finance
371

Related MCP Servers

alpaca-mcp-server
Finance Cryptocurrency
mfoster5303-1
A
license
Not graded
quality
D
maintenance
Enables natural language trading operations for stocks, options, crypto, and portfolio management via Alpaca's Trading API through AI assistants.
Updated a year ago (2025-10-11 00:42 UTC)
MIT
TastyTrade MCP Server
Finance Search
bostrovsky
A
license
Not graded
quality
C
maintenance
Connects your TastyTrade trading account to AI assistants like Claude Desktop and ChatGPT for conversational trading and portfolio management.
Updated a year ago (2025-10-09 20:52 UTC)
5
MIT
TastyScanner MCP Server
Finance AI & Machine Learning Autonomous Agents
technet365
A
license
Not graded
quality
A
maintenance
Enables AI agents to scan markets, build option strategies, track positions, and execute trades on TastyTrade via the Model Context Protocol.
Updated a day ago (2026-09-14 13:45 UTC)
3
MIT
NexusTrader MCPofficial
Finance Cryptocurrency
Quantweb3-com
F
license
Not graded
quality
C
maintenance
Exposes NexusTrader's account, positions, market data, and trading capabilities to AI assistants via natural language.
Updated 5 months ago (2026-04-15 10:58 UTC)
1
-

mcp-tastytrade-server

Features

Setup

1. Install dependencies

2. OAuth2 setup

3. Test the connection

4. Configure Claude Desktop

Option symbol format

Development

Security

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

NexusTrader MCPofficial