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., "@YFinance MCP Server show me Apple's current stock price"
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 comprehensive Model Context Protocol (MCP) server that provides financial data through Yahoo Finance API integration. This server enables AI agents to access real-time stock market data, historical prices, financial statements, and market analysis.
10 Comprehensive Financial Tools for complete market data access
Real-time Stock Information including prices, market cap, and key metrics
Historical Data Analysis with flexible time periods and intervals
Financial Statements (income statement, balance sheet, cash flow)
Earnings Data (annual and quarterly)
Dividend and Split History
News and Analyst Recommendations
Stock Search and Multi-quote Support
Robust Error Handling with structured JSON responses
FastMCP Framework with async support for high performance
Related MCP server: MCP YFinance Stock Server
Python 3.11+
uv (Python package manager)
# Clone the repository
git clone https://github.com/barvhaim/yfinance-mcp-server.git
cd yfinance-mcp-server
# Install dependencies
uv sync# Start the MCP server
uv run main.py
# The server will start and be ready to accept MCP client connectionsGet comprehensive stock information including current price, market cap, and financial metrics.
Parameters:
symbol (str): Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Stock information including price, market cap, P/E ratio, dividend yield, 52-week range, volume, beta, and company details.
Retrieve historical stock price data with flexible time periods and intervals.
Parameters:
symbol (str): Stock ticker symbol
period (str): Time period (1d, 5d, 1mo, 3mo, 6mo, 1y, 2y, 5y, 10y, ytd, max)
interval (str): Data interval (1m, 2m, 5m, 15m, 30m, 60m, 90m, 1h, 1d, 5d, 1wk, 1mo, 3mo)
Returns: Historical OHLCV data with dates and volume information.
Get dividend payment history for a stock.
Parameters:
symbol (str): Stock ticker symbol
Returns: List of dividend payments with dates and amounts.
Retrieve stock split history.
Parameters:
symbol (str): Stock ticker symbol
Returns: List of stock splits with dates and split ratios.
Get comprehensive financial statements.
Parameters:
symbol (str): Stock ticker symbol
quarterly (bool): Get quarterly data if True, annual if False
Returns: Income statement, balance sheet, and cash flow statement data.
Retrieve earnings data for analysis.
Parameters:
symbol (str): Stock ticker symbol
Returns: Annual and quarterly earnings data.
Get recent news articles related to a stock.
Parameters:
symbol (str): Stock ticker symbol
count (int): Number of articles to return (default: 10)
Returns: List of news articles with titles, links, publishers, and timestamps.
Get analyst recommendations and ratings.
Parameters:
symbol (str): Stock ticker symbol
Returns: List of analyst recommendations with firms, ratings, and actions.
Search for stocks by company name or ticker symbol.
Parameters:
query (str): Search query (company name or ticker)
limit (int): Maximum results to return (default: 10)
Returns: List of matching stocks with symbols, names, and exchange information.
Get current quotes for multiple stocks simultaneously.
Parameters:
symbols (List[str]): List of stock ticker symbols
Returns: Dictionary of stock quotes with current prices, changes, and basic metrics.
# Get Apple stock information
result = await get_stock_info("AAPL")
print(f"Current Price: ${result['current_price']}")
print(f"Market Cap: ${result['market_cap']:,}")# Get 1-year daily data for Google
result = await get_historical_data("GOOGL", period="1y", interval="1d")
print(f"Retrieved {result['count']} data points")# Get quotes for tech stocks
result = await get_multiple_quotes(["AAPL", "GOOGL", "MSFT", "AMZN"])
for symbol, quote in result['quotes'].items():
print(f"{symbol}: ${quote['current_price']}")To connect this server with Claude Desktop:
Start the server in one terminal:
uv run main.pyConfigure Claude Desktop by editing your MCP settings file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration:
{
"yfinance": {
"command": "uv",
"args": [
"--directory",
"/path/to/yfinance-mcp-server",
"run",
"main.py"
]
}
}Update the cwd path to your actual project directory
Restart Claude Desktop to load the new server
Verify connection by asking Claude: "What financial data tools do you have available?"
For other MCP clients:
Start the server: uv run main.py
Configure your MCP client to connect to the server endpoint
Tools will be automatically discovered by your AI agent
Use standard stock symbols (AAPL, GOOGL, MSFT, etc.) with the tools
# Format code with black
uv run black .
# Check formatting
uv run black --check .
# Show formatting differences
uv run black --diff .Create a new async function in main.py
Decorate with @mcp.tool()
Add proper type hints and docstrings
Include error handling
Test the implementation
Copy .env.sample to .env for any configuration needed:
cp .env.sample .envAll tools include comprehensive error handling:
Invalid symbols return structured error messages
Network issues are caught and reported
Data unavailability is handled gracefully
Rate limiting is respected automatically by yfinance
Async operations for optimal performance
Efficient data serialization with structured JSON
Minimal data processing to reduce latency
Built-in caching by yfinance for frequently accessed data
fastmcp - FastMCP framework for MCP server implementation
yfinance - Yahoo Finance API for financial data
python-dotenv - Environment variable management
black - Code formatting
pydantic - Data validation and serialization
This project is available under the MIT License.
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Format code with black
Submit a pull request
For issues and questions:
Check the Issues section
Review the CLAUDE.md file for development guidance
Ensure all dependencies are properly installed with uv sync
Initial implementation with 10 financial data tools
FastMCP server framework integration
Comprehensive error handling
Full yfinance API coverage
MCP client integration support
Get dividend history for a stock.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Dictionary containing dividend history
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (dictionary containing dividend history), which is basic behavioral information. However, it lacks details on data coverage, limitations, or error handling, and no annotations are present to supplement.
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 brief and uses a clear Args/Returns structure. Every sentence adds value, with no extraneous information.
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 tool with a single parameter and an output schema (not shown), the description covers the essential details. However, it omits usage differentiation and any caveats, making it less complete than ideal for guiding tool selection.
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 the 'symbol' parameter as 'Stock ticker symbol' with examples ('AAPL', 'GOOGL'), adding meaning beyond the bare schema type definition. This helps an agent understand the expected format.
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 'Get dividend history for a stock' clearly identifies the action and resource. It does not explicitly distinguish it from sibling tools like get_historical_data, but the purpose is unambiguous.
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 such as get_historical_data or get_financials. The description only states what it does, not when it is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get earnings data for a stock. Note: Uses income statement data as 'earnings' property is deprecated.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Dictionary containing earnings data extracted from financial statements
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by noting that the 'earnings' property is deprecated and that income statement data is used instead, which is a useful behavioral detail. However, it does not describe potential limitations, error behavior, or other important 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 concise and well-structured: a one-sentence purpose, a valuable note, and an Args/Returns breakdown. Every sentence earns its place without unnecessary fluff.
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 simple one-parameter getter with an output schema available, the description provides sufficient context: what it does, what input it needs, and the general return type. It lacks usage-alternative guidance, but that is already captured in the usage dimension and does not significantly detract from 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 only provides the parameter name and type, so the description's explanation that 'symbol' is a stock ticker with examples ('AAPL', 'GOOGL') adds meaningful semantic value. This compensates well for the 0% schema description coverage.
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 this tool retrieves earnings data for a stock, using a specific verb and resource. It distinguishes itself from sibling tools like get_stock_info, get_historical_data, and get_financials by focusing specifically on earnings.
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 get_financials. While the purpose implies earnings-related use, it does not state explicit exclusions or scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get financial statements for a stock.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL') quarterly: If True, get quarterly data; if False, get annual data
Returns: Dictionary containing financial statements
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| quarterly | 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 explains the quarterly condition (True = quarterly, False = annual) and returns a dictionary. However, it does not disclose any limitations (e.g., data freshness, availability for all symbols, rate limits), which keeps this at a mid-level 3.
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 a compact docstring with clear Args and Returns sections. Every sentence serves a purpose, no fluff, and it front-loads the main verb/resource. It is appropriately sized for the tool's simplicity.
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 is simple (2 params, output schema present). The description covers the essential behavior and parameter usage, while the output schema handles return structure. No critical contextual gaps (e.g., prerequisites for a read operation) are evident, so it is complete.
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 description fully compensates: it gives a concrete example for symbol ('AAPL') and specifies the exact behavior of the quarterly flag. This adds meaning beyond the bare schema types and defaults, making parameter semantics excellent.
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 'Get financial statements for a stock' with specific verb and resource. It is distinct from siblings like get_earnings (which focuses on earnings data) and get_historical_data (price history), so it unambiguously identifies the tool's purpose.
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 clear context on when to use the tool (to retrieve financial statements) and explains the quarterly vs. annual data option. It does not explicitly name alternatives or exclusions, but the purpose is self-evident among siblings, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical stock price data.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL') period: Time period (1d,5d,1mo,3mo,6mo,1y,2y,5y,10y,ytd,max) interval: Data interval (1m,2m,5m,15m,30m,60m,90m,1h,1d,5d,1wk,1mo,3mo)
Returns: Dictionary containing historical price data
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1mo | |
| symbol | Yes | ||
| interval | No | 1d |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the accepted period and interval values and notes that a dictionary is returned, which is some behavioral context. However, it omits details like data source, whether prices are adjusted, or any error/rate-limit behavior, leaving notable gaps.
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 structured with Args and Returns sections, making it scannable. The enum lists are somewhat verbose but are justified because they substitute for missing schema descriptions. No filler or redundancy.
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 moderate complexity, the description covers parameters and return type, and an output schema exists. However, it lacks usage context, such as when to choose this over siblings or any caveats about historical data, making it minimally viable but not complete.
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 does so fully by explaining symbol with ticker examples and enumerating all valid values for period and interval. This adds substantial meaning 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 opens with 'Get historical stock price data,' which is a specific verb+resource+scope. It clearly distinguishes itself from sibling tools like get_stock_info, get_dividends, and get_financials by focusing on historical price data rather than company info or corporate actions.
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 when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives (e.g., using get_multiple_quotes for current prices) or exclusions, leaving the agent to infer usage solely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current quotes for multiple stocks at once.
Args: symbols: List of stock ticker symbols (e.g., ['AAPL', 'GOOGL', 'MSFT'])
Returns: Dictionary containing quotes for all requested symbols
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes |
| 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 transparency burden. It states the tool 'gets' data and returns a dictionary, implying a safe read operation, but does not mention error handling, rate limits, or partial failures. The return type is also already covered by the output schema, so the description adds 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose followed by structured Args and Returns sections. Every sentence serves a purpose, and the example aids understanding without redundancy.
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 simple one-parameter batch-quote tool with an output schema, the description covers the essential semantics. It lacks potential limit or fallback details, but the core usage is adequately specified. Given the sibling list, a brief pointer to get_stock_info for detailed single-stock info would improve 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 schema only defines 'symbols' as an array of strings with no description. The description compensates by explaining these are stock ticker symbols and gives a concrete example (['AAPL','GOOGL','MSFT']), making the parameter fully clear.
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 opens with 'Get current quotes for multiple stocks at once' – a clear verb+object+scope. The 'multiple' qualifier distinguishes it from sibling tools like get_stock_info and get_historical_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?
The description implies a batch use case ('at once') but does not explicitly state when to prefer it over single-symbol tools or provide exclusion criteria. It lacks guidance on alternatives, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent news for a stock.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL') count: Number of news articles to return (default: 10)
Returns: Dictionary containing news articles
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| symbol | Yes |
| 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 only states that it returns a dictionary of news articles and leaves count as a default, but does not mention rate limits, error behavior, authentication requirements, or what 'recent' means. The description provides minimal behavioral context 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 concise and well-structured: a one-line purpose statement, followed by a clean Args section and a Returns section. Every sentence earns its place with no padding or redundancy.
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 is relatively simple with two parameters and an output schema, which reduces the need to explain return structure. However, the description omits any usage guidance or caveats (e.g., no mention of when to use this vs. search_stocks or get_stock_info). For a standalone news retrieval tool, it is adequate but has clear gaps in context.
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% description coverage, so the description must add meaning. It does this effectively by explaining 'symbol' as a stock ticker with examples ('AAPL', 'GOOGL') and clarifying 'count' as the number of articles with a default value. This adds significant value beyond the schema's raw type definitions.
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 'Get recent news for a stock' using a specific verb and resource. It distinguishes itself from sibling tools like get_stock_info, get_historical_data, and get_dividends by focusing specifically on news, making its purpose unambiguous.
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?
Usage context is implied: the tool is for retrieving recent news about a stock, which is clear from the description and sibling names. However, there are no explicit instructions on when to prefer this tool over alternatives, nor any exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analyst recommendations for a stock.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Dictionary containing analyst recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| 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. It includes a 'Returns' line indicating a dictionary of analyst recommendations, which adds some output context. However, it does not disclose whether the operation is read-only (beyond the verb 'Get'), any authentication needs, rate limits, or data quality characteristics, leaving room for more 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 brief and well-structured: a clear one-line purpose, followed by an Args section and a Returns section. Every sentence provides necessary information without redundancy, making it easy to scan.
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 single-parameter tool with an output schema, the description covers the essential elements: what it does, what input it expects, and what type of output it returns. Since the output schema exists, detailed return values are not required in the description. The simplicity of the tool makes this description sufficient.
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 no description for the 'symbol' parameter, but the tool description provides an 'Args' section explaining it as a 'Stock ticker symbol' with examples 'AAPL' and 'GOOGL'. This fully compensates for the missing schema description and clarifies the expected input format.
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 uses a specific verb 'Get' with resource 'analyst recommendations for a stock', clearly stating the tool's function. It distinguishes itself from sibling tools like get_stock_info and get_financials by focusing on 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 does not explicitly state when to use this tool versus alternatives. The purpose is clear enough to imply usage for analyst recommendations, but there is no mention of exclusions or comparisons to sibling tools, making it implied rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock split history for a stock.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Dictionary containing split history
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| 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 only mentions the return type ('Dictionary containing split history') and does not disclose data format, date range, adjustment types, or error handling.
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 compact and well-structured, with clear sections for Args and Returns. It front-loads the purpose and avoids unnecessary details; every sentence earns its place.
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 simple one-parameter getter with an output schema present, the description covers the essential purpose and parameter. However, it omits potential caveats like split adjustment types or date range behavior, which would be useful for full 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 Args section adds crucial meaning beyond the bare schema by explaining that 'symbol' is a stock ticker and providing examples ('AAPL', 'GOOGL'). With 0% schema description coverage, this fully compensates for missing schema 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 uses a specific verb+resource ('Get stock split history') and clearly distinguishes from sibling tools like get_dividends or get_historical_data by naming the exact data domain. It is unambiguous and immediately actionable.
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. The description simply states the function without contextual usage, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basic stock information including current price, market cap, and key metrics.
Args: symbol: Stock ticker symbol (e.g., 'AAPL', 'GOOGL')
Returns: Dictionary containing stock information
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| 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. It only states that the tool returns a dictionary, without disclosing data freshness, error behavior, rate limits, or whether the operation is read-only. This is minimal transparency for an information 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 brief and front-loaded with the primary purpose. The Args/Returns structure is clean and every sentence adds value, with no wasted words or irrelevant details.
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 simple one-parameter tool with an output schema, the description covers the essential aspects: what it does and what it returns. However, it could be more explicit about the full set of 'key metrics' and how this tool differs from siblings like get_financials, so an agent might not fully understand scope.
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 provides no description for the 'symbol' parameter (0% coverage), but the description compensates fully by explaining the parameter's meaning and providing examples ('AAPL', 'GOOGL'). This gives the agent clear guidance on what to pass.
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 ('basic stock information'), with explicit examples of included data (current price, market cap, key metrics). This distinguishes it from sibling tools like get_historical_data or get_financials, which cover more specific 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?
The word 'basic' suggests a contrast with more specialized sibling tools, but no explicit guidance is given on when to use this tool versus alternatives. The description doesn't mention when-not-to-use or name other tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stocks by company name or ticker symbol.
This tool searches Yahoo Finance's database for stocks matching your query. Works best with specific company names or partial ticker symbols.
Examples of effective queries:
"Microsoft" (company name)
"AAPL" (ticker symbol)
"Tesla" (company name)
"JPM" (partial ticker)
Note: Complex multi-word queries may return fewer results. For best results, search for one company at a time.
Args: query: Search query - company name or ticker symbol (e.g., 'Microsoft', 'AAPL') limit: Maximum number of results to return (default: 10, max recommended: 25)
Returns: Dictionary containing search results with symbol, name, type, exchange, sector, industry, relevance score, and other metadata
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the data source (Yahoo Finance), query behavior (works best with partial tickers), a limit recommendation, and the fields returned. It does not disclose rate limits or error handling, but covers the key behavioral aspects for a search 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?
Well-structured with a clear purpose, examples, a usage note, and an Args section. There is slight redundancy between the first two sentences ('Search for stocks' vs 'searches Yahoo Finance's database'), but the overall length is appropriate and content-rich.
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 description is complete for a search tool: it explains parameters, usage, and return content. An output schema exists so return values are presumably defined, reducing the need for further detail. Minor gaps like error handling or case sensitivity do not significantly hinder an agent's ability to invoke the tool 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?
Schema coverage is 0%, and the description compensates by explaining the query parameter (company name or ticker, with examples) and limit parameter (default 10, max recommended 25). This adds meaningful guidance beyond the bare schema definitions.
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 'Search for stocks by company name or ticker symbol' with a specific verb and resource. It distinguishes from sibling tools (get_stock_info, get_historical_data, etc.) by focusing on the search/discovery use case rather than retrieving specific data for a known symbol.
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 explicit examples of effective queries and notes that complex multi-word queries may return fewer results, advising one company at a time. However, it does not directly compare with sibling tools or state when to prefer other tools over this search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct data types, but get_stock_info and get_multiple_quotes both provide current quote data, and get_earnings overlaps with get_financials by design. The descriptions help clarify the intended usage, making confusion unlikely in practice.
All tools follow a consistent snake_case verb_noun pattern, with get_ as the dominant prefix for data retrieval and search_stocks as a logical exception for the search action. This is a predictable and uniform naming convention.
10 tools is well within the ideal 3-15 range for a specialized data provider, and each tool covers a distinct aspect of stock market data without unnecessary duplication.
The server covers the core financial data needs: current quotes, historical prices, dividends, splits, financials, earnings, news, recommendations, search, and batch quotes. As a read-only stock data API, it has no significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Unlock the power of real-time financial data with our Finance MCP. Easily retrieve the latest
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
SEC & financial-data MCP: filings, financials, ownership, factors, fund letters, prompts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/barvhaim/yfinance-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
