StockFlow MCP Server
StockFlow MCP Server
Сервер Model Context Protocol (MCP), предоставляющий данные о акциях в реальном времени и анализ опционов через Yahoo Finance. Позволяет LLM получать доступ к рыночным данным, анализировать акции и оценивать опционные стратегии.
Возможности
Данные по акциям
Цены акций в реальном времени и ключевые показатели
Исторические данные о ценах с значениями OHLC
Фундаментальные показатели компании и финансовая отчетность
Рыночные индикаторы и коэффициенты
Анализ опционов
Полные данные по цепочке опционов
Греки (дельта, гамма, тета, вега)
Отслеживание объема и открытого интереса
Анализ опционных стратегий
Related MCP server: MCP Yahoo Finance
Установка
# Install dependencies
pip install mcp yfinance
# Clone the repository
git clone https://github.com/twolven/stockflow
cd stockflowИспользование
Клонируйте репозиторий:
git clone https://github.com/twolven/mcp-stockflow.git
cd mcp-stockflowУстановите зависимости:
pip install -r requirements.txtДобавьте в конфигурацию Claude: В вашем
claude-desktop-config.jsonдобавьте следующее в разделmcpServers:
{
"mcpServers": {
"stockflow": {
"command": "python",
"args": ["path/to/stockflow.py"]
}
}
}Замените "path/to/stockflow.py" на полный путь к файлу stockflow.py, который вы сохранили.
Подсказка для использования с Claude
При работе с Claude вы можете использовать эту подсказку, чтобы помочь ему понять доступные инструменты:
"Я включил инструменты stockflow, которые дают вам доступ к данным фондового рынка. Вы можете использовать эти три основные функции:
get_stock_data- Получить полную информацию об акциях:
{
"symbol": "AAPL",
"include_financials": true, # optional
"include_analysis": true, # optional
"include_calendar": true # optional
}get_historical_data- Получить историю цен и технические индикаторы:
{
"symbol": "AAPL",
"period": "1y", # 1d, 5d, 1mo, 3mo, 6mo, 1y, 2y, 5y, 10y, ytd, max
"interval": "1d", # 1m, 2m, 5m, 15m, 30m, 60m, 90m, 1h, 1d, 5d, 1wk, 1mo, 3mo
"prepost": false # optional - include pre/post market data
}get_options_chain- Получить данные по опционам:
{
"symbol": "AAPL",
"expiration_date": "2024-12-20", # optional - uses nearest date if not specified
"include_greeks": true # optional
}Все ответы включают текущие данные о ценах, обработку ошибок и полную рыночную информацию."
Запуск сервера
python stockflow.pyИспользование с MCP-клиентом
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
server_params = StdioServerParameters(
command="python",
args=["stockflow.py"]
)
async def run():
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# Get current stock data
result = await session.call_tool(
"get-stock-data",
arguments={"symbol": "AAPL"}
)
# Get options chain
options = await session.call_tool(
"get-options-chain",
arguments={
"symbol": "AAPL",
"expiration_date": "2024-12-20"
}
)
if __name__ == "__main__":
import asyncio
asyncio.run(run())Доступные инструменты
get-stock-dataТекущая цена и объем
Рыночная капитализация и коэффициент P/E
Максимум/минимум за 52 недели
get-historical-dataЦены OHLC
Настраиваемые временные периоды
Данные об объеме
get-options-chainКоллы и путы
Цены страйк
Греки и IV
Объем и открытый интерес
Доступные ресурсы
company-info://{symbol}Описание компании
Сектор и отрасль
Количество сотрудников
Веб-сайт
financials://{symbol}Отчет о прибылях и убытках
Балансовый отчет
Отчет о движении денежных средств
Промпты
analyze-optionsАнализ опционных стратегий
Оценка риска/доходности
Оценка рыночных условий
Требования
Python 3.12+
mcp
yfinance
Ограничения
Данные получены из Yahoo Finance и могут иметь задержки
Доступность данных по опционам зависит от торговых часов
Применяются ограничения скорости в зависимости от ограничений API Yahoo Finance
Вклад
Вклад приветствуется! Пожалуйста, не стесняйтесь отправлять Pull Request.
Лицензия
Этот проект лицензирован под лицензией MIT — см. файл LICENSE для подробностей.
Автор
Todd Wolven — ведущий AI-разработчик ПО и инженер GenAI с открытым исходным кодом
Благодарности
Создано с использованием Model Context Protocol (MCP) от Anthropic
Данные предоставлены Yahoo Finance
Разработано для использования с Claude от Anthropic
Available Tools
3 toolsget_historical_data_v2C
Get unadjusted/repaired price history and technical indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | Yahoo Finance history period | |
| symbol | Yes | Yahoo Finance ticker symbol | |
| prepost | No | ||
| interval | No | History sampling interval | 1d |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| success | Yes | |
| provider | Yes | |
| warnings | Yes | |
| timestamp | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It does not explain what 'unadjusted/repaired' means, whether data is adjusted for splits/dividends, whether any access restrictions or rate limits apply, or what side effects exist. The operation appears read-only based on 'Get,' but this is not explicitly confirmed.
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 single sentence with no filler or repetition. It directly states the core function. The slight ambiguity of 'unadjusted/repaired' costs some clarity but does not add unnecessary length.
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?
Although an output schema exists, the description is too thin for a tool with four parameters and two sibling tools. It omits usage context, clarifies neither 'unadjusted/repaired' nor 'prepost,' and gives no indication about which technical indicators are included. An agent would have to infer too much from the schema alone.
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 75%, with symbol, period, and interval documented directly in the schema. The tool description adds no parameter-level meaning and does not clarify the undocumented 'prepost' parameter. However, the schema's enums and descriptions carry most of the semantic weight, so the description's lack of contribution is only a moderate 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?
The description uses a specific verb 'Get' and names a clear resource: 'unadjusted/repaired price history and technical indicators.' This distinguishes it from get_options_chain_v2, which is clearly for options data. However, it does not explicitly differentiate from get_stock_data_v2, which could plausibly also return price-related 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?
There is no guidance on when to choose this tool over get_stock_data_v2 or get_options_chain_v2. The phrase 'price history' implies past data, but no explicit context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_options_chain_v2B
Get an option chain and optionally add theoretical European Black-Scholes Greeks.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Yahoo Finance ticker symbol | |
| include_greeks | No | ||
| expiration_date | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| success | Yes | |
| provider | Yes | |
| warnings | Yes | |
| timestamp | Yes |
TDQS
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 adds the useful detail that Greeks are theoretical European Black-Scholes, but it does not explain defaults for expiration_date, whether the chain covers all expirations when null, what 'option chain' includes (calls/puts/strikes), or any limitations or side effects. This falls short of transparent behavioral disclosure.
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?
A single, front-loaded sentence that states the primary action and the optional enhancement with zero filler. Every word earns its place; it is 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?
For a 3-parameter tool with no annotations and only 33% schema coverage, the description is too thin. It does not clarify the meaning of expiration_date, the default behavior when it is null, the scope of the returned chain, or any caller expectations. The output schema exists, but key input semantics and usage context are missing.
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 only 33% — only the symbol parameter is described. The description helps clarify include_greeks by tying it to theoretical European Black-Scholes Greeks, but expiration_date receives no semantic explanation beyond the schema's type/format. With low schema coverage, the description should compensate more 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 uses a specific verb and resource — "Get an option chain" — and clearly distinguishes this tool from its siblings, which cover stock and historical data. The optional Greeks clause adds further precision without ambiguity.
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 by the domain: use this tool when you need option chain data, versus stock data or historical data for the siblings. However, there is no explicit when-to-use guidance, no mention of when to set include_greeks versus leave it false, and no stated exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_data_v2B
Get stock metadata and optional statements, analysis and calendar data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Yahoo Finance ticker symbol | |
| include_analysis | No | ||
| include_calendar | No | ||
| include_financials | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| success | Yes | |
| provider | Yes | |
| warnings | Yes | |
| timestamp | Yes |
TDQS
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 disclosing behavior. It conveys a read operation and hints at optional inclusions, but it does not mention output structure, side effects, rate limits, or behavior when flags are false. The output schema helps with return shape but not with 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 a single front-loaded sentence that leads with the core purpose and then lists optional variations. There is no filler, repetition, or unnecessary context.
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 presence of an output schema, return-value details are covered elsewhere. However, the description lacks usage guidance and sufficient elaboration on the optional data categories, making it minimally adequate but not fully self-sufficient for an agent deciding between this and sibling tools.
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 low at 25%, with only 'symbol' documented. The description adds some meaning by mapping the boolean flags to 'statements, analysis and calendar data,' which helps associate include_financials, include_analysis, and include_calendar, but it stops short of explaining what each included dataset contains.
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 a clear verb and resource: 'Get stock metadata' plus optional statements, analysis, and calendar data. It is specific enough to distinguish the tool from historical-data and options-chain siblings by resource type, though it does not explicitly name those alternatives.
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?
There is no guidance on when to use this tool versus get_historical_data_v2 or get_options_chain_v2. The phrase 'stock metadata' implies a use case, but the description does not state selection criteria or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v2.1.0- First observed
get_historical_data_v2 - First observed
get_options_chain_v2 - First observed
get_stock_data_v2
TDQS
Scored across 3 tools
Each tool targets a clearly distinct data domain: metadata/statements, historical prices/indicators, and options chains. There is no functional overlap between the three tools, so an agent can reliably select the correct one.
All tool names follow the exact same get_<resource>_v2 pattern, with consistent snake_case and a uniform version suffix. This makes the naming scheme highly predictable and easy to navigate.
Three tools is a modest but reasonable scope for a focused stock data server. The count is on the lower end, but each tool covers a substantial area, so it does not feel overly thin.
The main investment data workflows—current company data, historical prices, and options—are all covered. Minor gaps such as ticker search or news endpoints exist, but they are not critical dead ends for typical stock analysis use cases.
Maintenance
Related MCP Connectors
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
Production MCP server for US equity and options intelligence: real-time IV radar, Monte Carlo simulation, options pressure, strategy backtesting, AI prediction, pre-trade risk analysis, and automated stock research reports.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseBqualityBmaintenanceA Model Context Protocol server that enables LLMs to analyze options chains, calculate Greeks, and evaluate basic options strategies through Yahoo Finance data.140MIT
- AlicenseBqualityAmaintenanceA Model Context Protocol server that enables interaction with Yahoo Finance to retrieve stock pricing, company information, and historical financial data through natural language queries.21576 PyPI28MIT
- AlicenseCqualityNot gradedmaintenanceA Model Context Protocol server that provides tools for interacting with Yahoo Finance, allowing users to retrieve stock prices, company information, and perform financial data comparisons.11MIT
- AlicenseCqualityDmaintenanceA Model Context Protocol server providing comprehensive financial data from Yahoo Finance, allowing users to retrieve detailed stock information, financial statements, options data, and market news.34MIT
Appeared in Searches
- Real-Time Stock Options Data for All NASDAQ Stocks
- Yahoo Finance MCP (Model Context Protocol) Server
- A server for exploring business analysis, market research, and idea validation techniques
- A guide to investing in managed funds and equities
- A platform for live probability option trading with indicators across multiple markets