Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tastytrade MCP Server get the price history for SPY for the last 5 days"
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.
A server that provides access to Tastytrade historical price data via the Model Context Protocol (MCP).
Tastytrade credentials (Client Secret, Refresh Token)
uv (Python package manager)
Related MCP server: MCP Yahoo Finance
This project uses uv to manage dependencies and ensure a consistent environment for all users.
Clone the repository and navigate to the directory.
Install the dependencies:
uv syncThis will create a .venv directory with the exact versions specified in uv.lock.
It is not recommended to store credentials directly in your MCP client configuration file. Instead, this server is configured to load them automatically from the .env file located in the same directory as the script.
Ensure you have created your .env file with your credentials:
cp .env.example .env
# Edit .env with your actual detailsConfigure your MCP client (e.g., claude_desktop_config.json) with the command to run the server.
{
"mcpServers": {
"tastytrade": {
"command": "/home/username/.pyenv/versions/data/bin/python",
"args": [
"/home/username/Desktop/projects/mcp_tasty/tastytrade_server.py"
]
}
}
}Note: Since dependencies are now managed by the project, point the command to the .venv python if you want to use the lockfile environment, or just use uv as the command.
Recommended Configuration (using uv):
{
"mcpServers": {
"tastytrade": {
"command": "uv",
"args": [
"run",
"/home/username/Desktop/projects/mcp_tasty/tastytrade_server.py"
]
}
}
}get_price_history(symbol, days=7, interval='1d'): Get historical candle data for a symbol (e.g., "SPY").
To run the test client using the project environment:
uv run test_client.pyGet historical price data (candles) for a symbol.
Args:
symbol: The symbol to fetch data for (e.g. 'SPY', 'AAPL').
days: Number of past days to fetch data for (default 7).
interval: Candle interval (e.g. '1d', '1h', '5m').
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| days | No | ||
| interval | No | 1d |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions fetching data but doesn't cover critical aspects like rate limits, authentication needs, data freshness, or error handling. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details in a structured list. It avoids unnecessary fluff, but the parameter explanations could be slightly more concise (e.g., by integrating defaults more seamlessly). Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), the description doesn't need to explain outputs. However, for a tool with 3 parameters, no annotations, and moderate complexity (financial data retrieval), it lacks details on behavioral traits like data sources or limitations. It's adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for all three parameters beyond the input schema, which has 0% description coverage. It explains that 'symbol' is for fetching data (e.g., 'SPY', 'AAPL'), 'days' specifies the past days to fetch (with a default), and 'interval' defines candle intervals (e.g., '1d', '1h'). This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get historical price data (candles) for a symbol.' It specifies the verb ('Get'), resource ('historical price data'), and scope ('candles'), making it easy to understand what the tool does. However, since there are no sibling tools mentioned, it doesn't need to differentiate from alternatives, so it doesn't reach the highest score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or contextual constraints. It only lists parameters without explaining usage scenarios, such as for financial analysis or backtesting. This lack of guidance makes it less helpful for an AI agent in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_price_historyScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly distinct and standalone.
The single tool name follows a clear verb_noun pattern (get_price_history), and with only one tool, consistency is inherently perfect as there are no other tools to compare against.
A single tool is too few for a server named 'Tastytrade MCP Server', which implies a broader financial or trading domain. This minimal toolset feels thin and under-scoped for such a purpose.
The server is severely incomplete for its implied domain. It only provides historical price data, with no tools for account management, order placement, real-time quotes, or other core trading functionalities, leading to significant gaps.
Real-time and historical price feeds for 500+ crypto, equities, FX, and commodities assets.
Real-time & historical market data: forex, stocks, crypto, indices, metals, K-line, quotes
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries.
Twelve Data MCP: real-time & historical market data (stocks, crypto, forex, etc).
