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., "@yfin-mcp Get historical stock prices for AAPL over the past month"
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.
Enhanced fork of yahoo-finance-mcp by Alex2Yang97
With intelligent pagination, caching, and LLM-optimized responses
A high-performance Model Context Protocol (MCP) server that provides comprehensive financial data from Yahoo Finance with intelligent pagination, caching, and LLM-optimized responses.
This project is built upon the excellent foundation of yahoo-finance-mcp created by Alex2Yang97. The original implementation provides a comprehensive set of tools for accessing Yahoo Finance data through the Model Context Protocol.
While using the original implementation with LLM agents (Claude, ChatGPT, etc.), I encountered critical limitations:
Problem 1: Context Window Overflow
Historical stock data with period="max" could return thousands of rows
Option chains for popular stocks contained hundreds of contracts
LLM context windows (typically 200K tokens) would overflow
Responses would be truncated, losing critical data
Problem 2: No Data Persistence
Large datasets couldn't be saved for offline analysis
Repeated queries wasted API calls and time
No way to export data for use in other tools
Problem 3: Poor LLM Readability
JSON responses were hard for LLMs to parse when truncated
No clear navigation guidance for paginated data
Cache status was invisible to the LLM
This fork adds three key enhancements:
Token-Based Pagination (6,000 token limit per page)
Prevents context window overflow
Clear navigation guidance for LLMs
Dynamic page sizing based on data complexity
Intelligent Caching (TTL: 5min-1hr)
Reduces redundant API calls by 50-80%
Sub-millisecond response times for cached data
Automatic cache invalidation based on data volatility
JSON Export (File Download)
Save full datasets for offline analysis
Export to Excel, databases, or other tools
Preserve complete data without pagination
Original Author: Alex2Yang97 deserves full credit for:
✅ Complete Yahoo Finance API integration
✅ All 9 MCP tools implementation
✅ Robust error handling
✅ Comprehensive documentation
This Fork Adds: Pagination, caching, and export features to make the server production-ready for LLM agents handling large financial datasets.
Related MCP server: yahoo-finance-mcp-server
The server exposes the following tools through the Model Context Protocol:
Tool | Description |
| Get historical OHLCV data for a stock with customizable period and interval |
| Get comprehensive stock data including price, metrics, and company details |
| Get latest news articles for a stock |
| Get stock dividends and splits history |
Tool | Description |
| Get income statement, balance sheet, or cash flow statement (annual/quarterly) |
| Get major holders, institutional holders, mutual funds, or insider transactions |
Tool | Description |
| Get available options expiration dates |
| Get options chain for a specific expiration date and type (calls/puts) |
Tool | Description |
| Get analyst recommendations or upgrades/downgrades history |
With this MCP server, you can use Claude to:
Price Analysis: "Show me the historical stock prices for AAPL over the last 6 months with daily intervals."
Financial Health: "Get the quarterly balance sheet for Microsoft."
Performance Metrics: "What are the key financial metrics for Tesla from the stock info?"
Trend Analysis: "Compare the quarterly income statements of Amazon and Google."
Cash Flow Analysis: "Show me the annual cash flow statement for NVIDIA."
News Analysis: "Get the latest news articles about Meta Platforms."
Institutional Activity: "Show me the institutional holders of Apple stock."
Insider Trading: "What are the recent insider transactions for Tesla?"
Options Analysis: "Get the options chain for SPY with expiration date 2024-06-21 for calls."
Analyst Coverage: "What are the analyst recommendations for Amazon over the last 3 months?"
"Create a comprehensive analysis of Microsoft's financial health using their latest quarterly financial statements."
"Compare the dividend history and stock splits of Coca-Cola and PepsiCo."
"Analyze the institutional ownership changes in Tesla over the past year."
"Generate a report on the options market activity for Apple stock with expiration in 30 days."
"Summarize the latest analyst upgrades and downgrades in the tech sector over the last 6 months."
Python 3.11 or higher
Dependencies as listed in pyproject.toml, including:
mcp
yfinance
pandas
pydantic
and other packages for data processing
Install the package directly from PyPI:
pip install yfin-mcpClone this repository:
git clone https://github.com/fritzprix/yahoo-finance-mcp.git
cd yahoo-finance-mcpCreate and activate a virtual environment and install dependencies:
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e .After installing the package, you can integrate it with Claude for Desktop:
Install the package (if not already installed):
pip install yfin-mcpConfigure Claude Desktop:
MacOS: Edit ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: Edit %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration:
Using uvx (Recommended - No installation needed):
{
"mcpServers": {
"yfinance": {
"command": "uvx",
"args": ["yfin-mcp"]
}
}
}Using Python directly (if installed via pip):
{
"mcpServers": {
"yfinance": {
"command": "python",
"args": ["-m", "yfin_mcp"]
}
}
}For development/source installation:
macOS:
{
"mcpServers": {
"yfinance": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/yahoo-finance-mcp",
"run",
"server.py"
]
}
}
}Windows:
{
"mcpServers": {
"yfinance": {
"command": "uv",
"args": [
"--directory",
"C:\\ABSOLUTE\\PATH\\TO\\yahoo-finance-mcp",
"run",
"server.py"
]
}
}
}Restart Claude for Desktop
For testing with MCP Inspector:
# From source
uv run yfin-mcp
# Or if installed via pip
python -m yfin_mcpTo build and publish the package, use the provided scripts. You can optionally provide an argument to bump the version:
# Just build and publish current version
publish_package.bat
# Bump version and then publish
publish_package.bat patch
publish_package.bat minor
publish_package.bat majorchmod +x publish_package.sh
# Just build and publish current version
./publish_package.sh
# Bump version and then publish
./publish_package.sh patch
./publish_package.sh minor
./publish_package.sh majorThe scripts will build the package into thedist/ directory and then use twine to upload it. Ensure you have your PyPI credentials configured in ~/.pypirc (or %HOME%\.pypirc on Windows) or set the TWINE_PASSWORD environment variable.
If you see this error when running publish_package.bat or uv build, it means the MCP server is still running and locking the executable.
Close Claude Desktop or any app using the yfinance MCP server.
Stop any running MCP Inspector instances.
If the error persists, manually kill the processes:
taskkill /F /IM yfin-mcp.exe /T
taskkill /F /IM python.exe /TMIT License
Original Work: Copyright (c) 2025 AlexYoung
Fork Enhancements: Copyright (c) 2026 SKTelecom
This project maintains the MIT License from the original yahoo-finance-mcp project. All enhancements (pagination, caching, export) are also released under MIT License.
See LICENSE file for full details.
Get financial statement for a given ticker symbol from yahoo finance. You can choose from the following financial statement types: income_stmt, quarterly_income_stmt, balance_sheet, quarterly_balance_sheet, cashflow, quarterly_cashflow.
Args: ticker: str The ticker symbol of the stock to get financial statement for, e.g. "AAPL" financial_type: str The type of financial statement to get. You can choose from the following financial statement types: income_stmt, quarterly_income_stmt, balance_sheet, quarterly_balance_sheet, cashflow, quarterly_cashflow.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| financial_type | Yes | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature, rate limits, or error handling. It only states it gets data from yahoo finance, omitting return format, pagination, or potential failures.
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 moderately concise but repeats the financial type list twice (once in the text and again in the Args section), which is redundant. It could be streamlined.
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, no output schema, and no annotations, the description should explain return values or data format. It does not, leaving the agent uncertain about what the tool returns.
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 coverage is 0%, so the description must compensate. It explains ticker and financial_type but repeats the same list of types. It does not describe export_path at all, despite it being an optional parameter.
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 gets a financial statement for a ticker from Yahoo Finance, lists the available statement types, and is distinct from sibling tools like get_stock_info or get_historical_stock_prices.
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 use for retrieving financial statements but does not explicitly guide when to choose this tool over siblings. It lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical stock prices for a given ticker symbol from yahoo finance. Include the following information: Date, Open, High, Low, Close, Volume, Adj Close. Args: ticker: str The ticker symbol of the stock to get historical prices for, e.g. "AAPL" period : str Valid periods: 1d,5d,1mo,3mo,6mo,1y,2y,5y,10y,ytd,max Either Use period parameter or use start and end Default is "1mo" interval : str Valid intervals: 1m,2m,5m,15m,30m,60m,90m,1h,1d,5d,1wk,1mo,3mo Intraday data cannot extend last 60 days Default is "1d"
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| period | No | 1mo | |
| interval | No | 1d | |
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions intraday data limitations and parameter defaults, but lacks details on auth, rate limits, side effects, or return structure beyond column names.
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?
Moderately concise with clear Args section, but includes redundant defaults already in schema and references non-existent start/end parameters, making it somewhat bloated.
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?
Returns fields are listed, but two of five parameters are undocumented. No output schema exists, so description should fully explain return values and pagination, which it partially does.
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?
Describes ticker, period, and interval with valid values and constraints, which adds value over the schema (0% coverage). However, it omits page and export_path entirely, and mentions start/end parameters that are not in the schema, causing confusion.
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?
Description clearly states it gets historical stock prices for a ticker symbol from Yahoo Finance, listing the data fields. This distinguishes it from sibling tools like get_stock_info or get_financial_statement.
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?
Provides guidance on period vs. start/end usage and intraday data constraints, but does not explicitly state when to choose this over alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get holder information for a given ticker symbol from yahoo finance. You can choose from the following holder types: major_holders, institutional_holders, mutualfund_holders, insider_transactions, insider_purchases, insider_roster_holders.
Args: ticker: str The ticker symbol of the stock to get holder information for, e.g. "AAPL" holder_type: str The type of holder information to get. You can choose from the following holder types: major_holders, institutional_holders, mutualfund_holders, insider_transactions, insider_purchases, insider_roster_holders.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| holder_type | Yes | ||
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral context. It only states the function and parameters, lacking transparency on data source behavior, rate limits, or output characteristics.
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 main purpose and structured with an Args section. The list of holder types is detailed but necessary. Slightly verbose but overall reasonable.
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?
The tool has four parameters and no output schema, so the description should explain the output structure or data returned. It also lacks usage context relative to siblings. The description is adequate for basic invocation but not for full understanding.
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 explains ticker and holder_type with examples and allowed values, compensating for the schema's lack of descriptions. However, page and export_path are not described, leaving their semantics unclear.
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 retrieves holder information for a stock ticker from Yahoo Finance, listing specific holder types. This distinguishes it from other financial tools like get_stock_info or get_recommendations.
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 lists available holder types, implying usage for those specific queries, but does not provide guidance on when to prefer this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the option chain for a given ticker symbol, expiration date, and option type.
Args: ticker: str The ticker symbol of the stock to get option chain for, e.g. "AAPL" expiration_date: str The expiration date for the options chain (format: 'YYYY-MM-DD') option_type: str The type of option to fetch ('calls' or 'puts')
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| expiration_date | Yes | ||
| option_type | Yes | ||
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as read-only nature, authentication needs, rate limits, or error behavior. This minimal transparency is insufficient for a data retrieval tool.
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 concise and well-structured with a clear docstring including an Args section. It avoids unnecessary details, though the repetition of parameter names in the list could be condensed.
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 absence of an output schema and annotations, the description should explain return data structure and pagination behavior (due to page parameter). It does not address these, leaving the agent without key context for interpreting results.
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 meaning for the three required parameters (ticker, expiration_date, option_type) by providing examples and format, but it fails to document the optional parameters (page, export_path) which exist in the schema. Schema coverage is 0%, so the description partially compensates.
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 states 'Fetch the option chain for a given ticker symbol, expiration date, and option type,' which is a specific verb+resource. It clearly distinguishes from siblings like get_option_expiration_dates by mentioning the parameters, but does not explicitly differentiate usage.
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 (e.g., get_option_expiration_dates). The description lacks context on prerequisites or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the available options expiration dates for a given ticker symbol.
Args: ticker: str The ticker symbol of the stock to get option expiration dates for, e.g. "AAPL"
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behaviors. It only says 'Fetch' with no details on data freshness, mutability, or response characteristics. Minimal 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?
Description is short (two sentences) and front-loaded with purpose. No fluff, though the arg docstring could be integrated more cleanly.
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?
With no output schema and no annotations, the description is adequate for a simple single-parameter tool but lacks details on return format (e.g., list of dates, format) and potential errors.
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%, but the tool description includes an example ('e.g., "AAPL"') for the ticker parameter. However, it does not elaborate on format constraints or case sensitivity, so it adds only marginal value beyond the 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?
Clearly states 'Fetch the available options expiration dates for a given ticker symbol.' The verb 'fetch' and resource 'options expiration dates' are specific. Given sibling tools like get_option_chain, this purpose is well-differentiated.
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 on when to use this tool versus alternatives (e.g., get_option_chain). Does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recommendations or upgrades/downgrades for a given ticker symbol from yahoo finance. You can also specify the number of months back to get upgrades/downgrades for, default is 12.
Args: ticker: str The ticker symbol of the stock to get recommendations for, e.g. "AAPL" recommendation_type: str The type of recommendation to get. You can choose from the following recommendation types: recommendations, upgrades_downgrades. months_back: int The number of months back to get upgrades/downgrades for, default is 12.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| recommendation_type | Yes | ||
| months_back | No | ||
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions source (Yahoo Finance) but lacks disclosure on data freshness, rate limits, error handling, or safe mutation behavior (likely read-only but not stated).
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?
Description is clear and includes an 'Args' section for structure. It is front-loaded with purpose, but could be trimmed by removing redundant phrasing (e.g., 'from yahoo finance' in both sentences).
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?
With 5 parameters, no output schema, and no annotations, the description should be comprehensive. Missing documentation for 2 parameters and does not explain return format or behavior. Incomplete for a data lookup tool.
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 coverage is 0%, so description must add meaning. It explains 'ticker', 'recommendation_type', and 'months_back', but 'page' and 'export_path' are completely undocumented. Partial value but significant gap.
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?
Clearly states it gets recommendations/upgrades_downgrades for a ticker from Yahoo Finance. However, it does not differentiate from sibling tools like 'get_stock_actions' which might also provide similar data.
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?
Provides some guidance on the 'months_back' parameter and default, but no explicit when-to-use or when-not-to-use compared to other tools. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock dividends and stock splits for a given ticker symbol from yahoo finance.
Args: ticker: str The ticker symbol of the stock to get stock actions for, e.g. "AAPL"
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It merely says 'Get' implying a read operation, but does not explicitly state it is read-only, safe, or require any authentication. No mention of behavior like pagination or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a clear separation of purpose and args. However, the use of 'Args:' section could be more complete to include all parameters without requiring extra tool configuration. Still, it's efficient.
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?
Despite low complexity, the description is incomplete: no output schema, no explanation of return values, and two undocumented parameters. The sibling tools provide context but the description itself lacks completeness for an agent to use the tool effectively.
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%. The description only covers the 'ticker' parameter with a brief explanation and example. The 'page' and 'export_path' parameters are entirely undocumented, leaving the agent without guidance on their purpose or usage.
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?
Clearly states the tool retrieves stock dividends and splits for a given ticker symbol from Yahoo Finance. The verb 'Get' and specific resource 'stock actions' differentiate it from sibling tools like 'get_financial_statement' or 'get_historical_stock_prices'.
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?
Provides an example ticker 'AAPL' but no guidance on when to use this tool vs alternatives (e.g., get_stock_info for general info, get_historical_stock_prices for price data). No when-not or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock information for a given ticker symbol from yahoo finance. Include the following information: Stock Price & Trading Info, Company Information, Financial Metrics, Earnings & Revenue, Margins & Returns, Dividends, Balance Sheet, Ownership, Analyst Coverage, Risk Metrics, Other.
Args: ticker: str The ticker symbol of the stock to get information for, e.g. "AAPL"
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| fields | No | ||
| page | No | ||
| export_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions data source (Yahoo Finance) but lacks details on rate limits, data freshness, caching, or whether it triggers mutations. It lists categories but no behavioral traits beyond the basic operation.
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 reasonably structured with a list of categories, but it is verbose, repeating 'Include the following information:' and enumerating many items. It could be more concise without losing meaning.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain parameters like fields and page, and does not describe the return format or pagination behavior. A more complete description would cover these gaps.
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%. Of 4 parameters (ticker, fields, page, export_path), only ticker is mentioned in the description. The fields parameter's purpose (filtering results) and format are undefined, and page/export_path are not explained. The description adds no value over the 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 tool retrieves stock information for a ticker from Yahoo Finance and lists broad categories. It is specific about the resource (stock info) and action (get). However, it does not differentiate from sibling tools like get_financial_statement or get_holder_info, which also return financial data.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for general stock info, but does not specify scenarios where siblings would be more appropriate (e.g., detailed financial statement vs. overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get news for a given ticker symbol from yahoo finance.
Args: ticker: str The ticker symbol of the stock to get news for, e.g. "AAPL"
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| page | No | ||
| export_path | No |
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 'get news' without detailing behavior like pagination, rate limits, or whether it fetches all news or recent ones. The page parameter suggests pagination but is not explained.
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?
Brief description with a separate Args section, but it lacks structured information about all parameters. It is concise but not fully organized.
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 are three parameters, no annotations, and no output schema, the description is incomplete. It fails to explain pagination, export functionality, or the nature of the news returned.
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?
Only the ticker parameter is described with an example. The page and export_path parameters are not explained, despite having schema description coverage of 0%. The description does not add meaning beyond the schema for these parameters.
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?
Clearly states 'Get news for a given ticker symbol from yahoo finance', which is a specific verb+resource. Distinguishes from sibling tools like get_financial_statement or get_historical_stock_prices.
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 on when to use this tool versus alternatives. The description does not mention any context for usage, such as retrieving recent news or any filtering criteria.
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.
v0.2.9get_financial_statementget_historical_stock_pricesget_holder_infoget_option_chainget_option_expiration_datesget_recommendationsget_stock_actionsget_stock_infoget_yahoo_finance_newsScored across 9 tools
All tools target distinct financial data categories: financial statements, historical prices, holder info, options, recommendations, stock actions, general info, and news. No overlap in functionality.
All tools follow a consistent 'get_' prefix with underscore-separated descriptive nouns (e.g., get_financial_statement, get_historical_stock_prices). The pattern is uniform and predictable.
With 9 tools, the server covers the essential Yahoo Finance data domains without being bloated or sparse. Each tool serves a specific purpose, and the count is well-scoped for the server's purpose.
The set covers financial statements, historical prices, holders, options, recommendations, actions, general info, and news. Minor gaps like earnings call transcripts or more granular estimates exist, but the core data surface is nearly complete.
Multi-tenant FastMCP server for Charles Schwab brokerage data, monetized via DPYC Tollbooth
Finnhub MCP — wraps Finnhub Stock API (finnhub.io)
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
MCP server for stocksense-ai documentation, generated by doc2mcp.
