This ETRADE MCP Server provides programmatic access to ETRADE's Market API through the Model Context Protocol, enabling comprehensive market data retrieval and analysis.
Authentication Management: Handle OAuth authentication by retrieving the authorization URL (etrade_get_auth_url) and completing authentication with verification codes (etrade_authenticate).
Market Data Access: Get real-time or delayed quotes for single or multiple symbols (etrade_get_quote), including price, volume, bid/ask spreads, and optionally earnings dates. Supports stocks, options, and mutual funds.
Security Lookup: Search for financial products (etrade_lookup_product) by full or partial symbols or company names, with filtering across security types (equities, mutual funds, options).
Options Analysis: Retrieve detailed option chains (etrade_get_option_chains) with customizable filters for expiration dates, strike price ranges, option types (calls/puts), weekly vs standard options, and price positioning (at-the-money or all).
Expiration Date Discovery: List available option expiration dates (etrade_get_option_expire_dates) for any symbol, filterable by type (weekly, monthly, quarterly, or all).
Environment Support: Works with both E*TRADE sandbox (testing) and production environments, with secure credential management via environment variables.
Click on "Install 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., "@E*TRADE MCP Server get quote for AAPL and MSFT"
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 Model Context Protocol (MCP) server for E*TRADE's Market API, built with FastMCP.
This MCP server provides access to E*TRADE's Market API endpoints:
Quote: Get real-time and delayed quotes for stocks, options, and mutual funds
Product Lookup: Search for securities by symbol or company name
Option Chains: Get option chains with strikes and expirations
Option Expire Dates: Get available expiration dates for options
Related MCP server: E*TRADE MCP Server
Clone this repository
Install dependencies:
pip install -e .Copy .env.example to .env and add your E*TRADE API credentials:
cp .env.example .envEdit .env and add your credentials:
ETRADE_CONSUMER_KEY=your_consumer_key_here
ETRADE_CONSUMER_SECRET=your_consumer_secret_here
ETRADE_ENVIRONMENT=sandbox # or 'production'Go to E*TRADE Developer Portal
Sign up or log in with your E*TRADE account
Request a Sandbox consumer key at https://us.etrade.com/etx/ris/apikey
Get your Consumer Key and Consumer Secret
Start with the sandbox environment for testing
Run the authentication script to get and save your access tokens:
python authenticate.pyThis will:
Prompt you to visit an E*TRADE authorization URL
Ask you to enter the verification code
Save the access tokens to your .env file
The MCP server will automatically use these saved tokens.
Note: Access tokens expire at midnight US Eastern time, so you'll need to re-authenticate daily.
You can also authenticate through the MCP tools:
Call etrade_get_auth_url() to get the authorization URL
Visit the URL in your browser and authorize the application
Copy the verification code
Call etrade_authenticate(verifier="YOUR_CODE") with the verification code
The server runs as an HTTP server on port 8000 with the MCP endpoint at /mcp:
etrade-mcpOr with Python:
python -m etrade_mcp.serverThe server will start at http://localhost:8000 with the MCP endpoint available at http://localhost:8000/mcp.
Configure your MCP client to connect to the HTTP endpoint:
{
"mcpServers": {
"etrade": {
"url": "http://localhost:8000/mcp"
}
}
}etrade_get_auth_url()Get the OAuth authorization URL. This is the first step in authentication.
Returns: Authorization URL to visit in browser
etrade_authenticate(verifier: str)Complete authentication with the verification code from E*TRADE.
Args:
verifier: Verification code from E*TRADE
Returns: Success message
etrade_get_quote(symbols: str, require_earnings_date: bool = False, skip_mini_options_check: bool = False)Get stock quotes for one or more symbols.
Args:
symbols: Comma-separated list of symbols (e.g., "AAPL,MSFT,GOOGL")
require_earnings_date: Include next earnings date
skip_mini_options_check: Skip mini options check
Returns: Quote data with prices, volume, bid/ask, etc.
etrade_lookup_product(search: str, company: str = None, type: str = None)Look up products by symbol or company name.
Args:
search: Symbol or partial symbol to search
company: Company name (optional)
type: Security type - EQ, MF, OPTN (optional)
Returns: List of matching products
etrade_get_option_chains(symbol: str, ...)Get option chains for a symbol with various filters.
Args:
symbol: Underlying symbol
expiry_year, expiry_month, expiry_day: Expiration date filters
strike_price_near: Filter strikes near this price
no_of_strikes: Number of strikes to return
include_weekly: Include weekly options
option_category: STANDARD, ALL, MINI
chain_type: CALL, PUT, CALLPUT
And more...
Returns: Option chain data
etrade_get_option_expire_dates(symbol: str, expiry_type: str = None)Get available option expiration dates.
Args:
symbol: Underlying symbol
expiry_type: WEEKLY, MONTHLY, QUARTERLY, ALL
Returns: List of expiration dates
# Get authorization URL
auth_url = etrade_get_auth_url()
# Visit the URL, authorize, get verifier code
# Authenticate
etrade_authenticate(verifier="12345")
# Get a quote
quote = etrade_get_quote(symbols="AAPL")
# Look up a product
results = etrade_lookup_product(search="Apple")
# Get option chains
chains = etrade_get_option_chains(
symbol="AAPL",
chain_type="CALL",
price_type="ATNM"
)
# Get expiration dates
dates = etrade_get_option_expire_dates(symbol="AAPL")For detailed API documentation, see:
ETRADE_CONSUMER_KEY: Your E*TRADE consumer key (required)
ETRADE_CONSUMER_SECRET: Your E*TRADE consumer secret (required)
ETRADE_ENVIRONMENT: sandbox or production (default: sandbox)
ETRADE_SANDBOX_BASE_URL: Sandbox API URL (default: https://apisb.etrade.com)
ETRADE_PROD_BASE_URL: Production API URL (default: https://api.etrade.com)
Never commit your .env file or expose your API credentials
Start with the sandbox environment for testing
OAuth tokens expire; you'll need to re-authenticate periodically
Production environment requires additional E*TRADE account approvals
This server is based on E*TRADE's sample Python client, which is included in the EtradePythonClient directory for reference.
MIT
Complete E*TRADE OAuth authentication with verification code.
Args: verifier: The verification code received after authorizing the application
Returns: Success message
| Name | Required | Description | Default |
|---|---|---|---|
| verifier | Yes |
| 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 the tool completes OAuth authentication, implying it's a write/mutation operation that likely stores tokens or establishes a session. However, it doesn't disclose critical behavioral traits such as whether this is a one-time setup, if it requires prior steps (like calling 'etrade_get_auth_url'), error handling, or rate limits. For a tool with no annotations and significant behavioral implications, this is inadequate.
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: the first sentence states the purpose clearly, followed by structured 'Args' and 'Returns' sections. There's no wasted text, and the structure aids readability. It could be slightly more concise by integrating the 'Args' explanation into the main description, but it's efficient overall.
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 the tool's complexity (OAuth authentication with no annotations and an output schema), the description is minimally complete. It explains the parameter and return value ('Success message'), and the output schema likely provides more detail on returns. However, it lacks context on prerequisites (e.g., dependency on 'etrade_get_auth_url'), error cases, or behavioral nuances, leaving gaps for an AI agent to infer usage correctly.
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 schema description coverage is 0%, but the description includes an 'Args' section that explains 'verifier' as 'The verification code received after authorizing the application.' This adds meaningful semantics beyond the bare schema, clarifying the parameter's purpose and source. However, it doesn't provide format details (e.g., length, character set) or examples. With 0% schema coverage, the description compensates partially but not fully.
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: 'Complete E*TRADE OAuth authentication with verification code.' It specifies the verb ('Complete authentication') and resource ('E*TRADE OAuth'), though it doesn't explicitly differentiate from sibling tools like 'etrade_get_auth_url' which likely provides the initial authorization URL. The purpose is clear but lacks sibling distinction.
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 implies usage context by mentioning 'verification code received after authorizing the application,' suggesting this tool is used after obtaining an auth URL (likely from 'etrade_get_auth_url'). However, it doesn't explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get E*TRADE OAuth authorization URL. This is the first step in authentication - returns a URL for the user to visit.
Returns: Authorization URL that the user should visit in their browser
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a URL for user interaction and is part of an OAuth flow, which is useful behavioral context. However, it lacks details on error handling, rate limits, or authentication prerequisites, leaving gaps 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 front-loaded with the core purpose in the first sentence, followed by additional context and return details. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
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 the tool's low complexity (0 parameters, output schema exists), the description is largely complete, covering purpose, usage, and return value. However, with no annotations, it could benefit from more behavioral details like error cases or integration steps with etrade_authenticate, slightly reducing 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a high baseline score. It could slightly improve by noting the absence of parameters, but this is minor.
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 specific action ('Get E*TRADE OAuth authorization URL') and resource ('URL'), distinguishing it from sibling tools like etrade_authenticate (which likely uses the URL) and other data retrieval tools. It precisely communicates the tool's function as the first authentication step.
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 explicitly states when to use this tool ('first step in authentication'), providing clear context. However, it does not specify when not to use it or name alternatives, such as whether to use etrade_authenticate directly in some scenarios, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option chains for a symbol.
Args: symbol: Underlying stock symbol (e.g., "AAPL") expiry_year: Expiration year (4-digit, e.g., 2024) expiry_month: Expiration month (1-12) expiry_day: Expiration day (1-31) strike_price_near: Strike price near this value no_of_strikes: Number of strikes to return include_weekly: Include weekly options skip_adjusted: Skip adjusted options option_category: STANDARD, ALL, or MINI chain_type: CALL, PUT, or CALLPUT price_type: ATNM (at the money) or ALL
Returns: Option chain data with available strikes and expiration dates
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| expiry_year | No | ||
| expiry_month | No | ||
| expiry_day | No | ||
| strike_price_near | No | ||
| no_of_strikes | No | ||
| include_weekly | No | ||
| skip_adjusted | No | ||
| option_category | No | ||
| chain_type | No | ||
| price_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical details: it doesn't mention authentication requirements (though sibling tools suggest it's needed), rate limits, error handling, or whether this is a read-only operation. The 'Returns' section hints at output but doesn't fully describe behavior.
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 well-structured with a clear purpose statement followed by organized parameter and return sections. It's appropriately sized for an 11-parameter tool, though the 'Returns' section could be more detailed given the complexity. Every sentence earns its place, but minor verbosity in listing all parameters slightly reduces efficiency.
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?
For a complex tool with 11 parameters, no annotations, and an output schema, the description is moderately complete. It covers parameter semantics well but lacks behavioral context (e.g., authentication, errors) and doesn't leverage the output schema to explain return values in detail. It's adequate but has clear gaps given the tool's complexity.
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?
Given 0% schema description coverage, the description compensates excellently by providing clear semantics for all 11 parameters. Each parameter is explained with examples (e.g., 'AAPL' for symbol) and valid ranges/enums (e.g., 'STANDARD, ALL, or MINI' for option_category), adding significant value beyond the bare schema.
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 verb 'Get' and the resource 'option chains for a symbol', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'etrade_get_option_expire_dates' or 'etrade_get_quote', which prevents a perfect score.
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. There's no mention of sibling tools like 'etrade_get_option_expire_dates' for expiration dates or 'etrade_get_quote' for stock quotes, nor any context about prerequisites such as authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option expiration dates for a symbol.
Args: symbol: Underlying stock symbol (e.g., "AAPL") expiry_type: WEEKLY, MONTHLY, QUARTERLY, or ALL (optional)
Returns: List of available expiration dates for options
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| expiry_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the tool 'Get[s]' data, implying a read-only operation, but doesn't address other behavioral aspects like authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with no annotation coverage, this is a significant gap.
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: the first sentence states the purpose clearly, followed by structured sections for 'Args' and 'Returns'. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which covers return values), the description is mostly complete. It explains parameters well, but lacks context on usage guidelines and behavioral traits, which slightly reduces completeness for agent invocation.
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 beyond the input schema. The schema has 0% description coverage, but the description explains 'symbol' as 'Underlying stock symbol (e.g., "AAPL")' and 'expiry_type' with allowed values ('WEEKLY, MONTHLY, QUARTERLY, or ALL') and notes it's optional. This compensates well for the schema's lack of documentation.
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 option expiration dates for a symbol.' It specifies the verb ('Get') and resource ('option expiration dates'), and the scope ('for a symbol') is clear. However, it doesn't explicitly differentiate from sibling tools like 'etrade_get_option_chains' or 'etrade_lookup_product', which prevents a perfect score.
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. It doesn't mention sibling tools like 'etrade_get_option_chains' or 'etrade_lookup_product', nor does it specify prerequisites such as authentication. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock quote for one or more symbols.
Args: symbols: Comma-separated list of stock symbols (e.g., "AAPL", "MSFT,GOOGL") require_earnings_date: If true, return next earnings date skip_mini_options_check: If true, skip check for mini options
Returns: Quote data including price, volume, bid/ask, and other market information
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | ||
| require_earnings_date | No | ||
| skip_mini_options_check | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what data is returned but doesn't cover critical aspects like rate limits, authentication requirements (implied by sibling tools but not stated), error handling, or whether this is a read-only operation. The return statement adds some value but is insufficient for a mutation-free tool with zero annotation coverage.
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 well-structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place by explaining parameters or outputs. It could be slightly more front-loaded by integrating the return info into the opening, but it's efficiently sized without 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 3 parameters with 0% schema coverage and an output schema (implied by 'Has output schema: true'), the description does a decent job. It explains all parameters and outlines return data, but lacks context on authentication (suggested by sibling tools), error cases, or usage limits. The output schema reduces the need for detailed return explanations, but behavioral gaps remain.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: symbols (format and examples), require_earnings_date (effect on return data), and skip_mini_options_check (behavioral effect). This adds significant value beyond the bare schema, though it doesn't detail all possible return fields exhaustively.
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 stock quote for one or more symbols.' It specifies the verb ('Get') and resource ('stock quote'), and distinguishes it from siblings like option chains or product lookup. However, it doesn't explicitly differentiate from similar quote tools that might exist elsewhere, keeping it at 4 rather than 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?
No guidance is provided on when to use this tool versus alternatives. While siblings include authentication and option-related tools, the description doesn't mention when to choose this over etrade_lookup_product or other potential quote tools. It only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up products by symbol or company name.
Args: search: Full or partial symbol name to search for company: Full or partial company name (optional) type: Security type - EQ (equity), MF (mutual fund), OPTN (option) (optional)
Returns: List of matching products with details
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | ||
| company | No | ||
| type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a list of matching products but doesn't mention critical aspects like authentication requirements (implied by sibling tools), rate limits, error handling, or whether this is a read-only operation. The description is minimal and lacks 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by Args and Returns sections. It's concise with no wasted sentences, though the lack of usage guidelines or behavioral details means it could be more informative without sacrificing brevity.
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 the tool has an output schema (which covers return values), the description doesn't need to detail returns. However, with 3 parameters, 0% schema coverage, and no annotations, the description only partially compensates. It explains parameters but misses authentication needs, error cases, and sibling differentiation, making it incomplete for safe and effective use.
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 some parameter semantics beyond the schema, which has 0% coverage. It explains that 'search' is for symbol names, 'company' for company names, and 'type' for security types with examples (EQ, MF, OPTN). However, it doesn't clarify if searches are case-sensitive, the format of returns, or how partial matches work, leaving gaps in understanding.
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 as 'Look up products by symbol or company name,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like etrade_get_quote, which might also retrieve product information, leaving room for potential confusion about when to use each.
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 like etrade_get_quote or other siblings. It mentions optional parameters but doesn't explain scenarios where searching by symbol vs. company name is preferred or how this tool complements others in the server.
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.
v1.0.0etrade_authenticateetrade_get_auth_urletrade_get_option_chainsetrade_get_option_expire_datesetrade_get_quoteetrade_lookup_productScored across 6 tools
Each tool has a clearly distinct purpose with no overlap. Authentication tools handle OAuth flow, option tools retrieve chains and expiration dates, quote tool gets market data, and lookup tool searches for products. An agent can easily distinguish between these functions.
All tools follow a consistent 'etrade_verb_noun' pattern with snake_case throughout. The naming convention is perfectly uniform across all six tools, making them predictable and easy to understand.
Six tools is reasonable for an E*TRADE API server, covering authentication, options data, quotes, and product lookup. While slightly lean, it provides core functionality without being overwhelming or insufficient for the domain.
The server covers authentication, options data retrieval, quotes, and product lookup well. However, there are notable gaps for a trading platform: no tools for account management (balances, positions), order placement (buy/sell), or portfolio analysis, which limits comprehensive trading workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time stock quotes, history, options chains, sector performance & screening for agents.
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries.
Tradier MCP — stock & options market data via the Tradier Brokerage API
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
