Skip to main content
Glama
deenesjakoruzh
twolven

StockFlow MCP Server

by twolven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

StockFlow MCP Server

Un servidor de Model Context Protocol (MCP) que proporciona datos bursátiles en tiempo real y análisis de opciones a través de Yahoo Finance. Permite a los LLM acceder a datos de mercado, analizar acciones y evaluar estrategias de opciones.

Características

Datos de acciones

  • Precios de acciones en tiempo real y métricas clave

  • Datos históricos de precios con valores OHLC

  • Fundamentos de la empresa y estados financieros

  • Indicadores de mercado y ratios

Análisis de opciones

  • Datos completos de la cadena de opciones

  • Griegas (delta, gamma, theta, vega)

  • Seguimiento de volumen e interés abierto

  • Análisis de estrategias de opciones

Related MCP server: MCP Yahoo Finance

Instalación

# Install dependencies
pip install mcp yfinance

# Clone the repository
git clone https://github.com/twolven/stockflow
cd stockflow

Uso

  1. Clona el repositorio:

git clone https://github.com/twolven/mcp-stockflow.git
cd mcp-stockflow

  1. Instala las dependencias:

pip install -r requirements.txt

  1. Añade a tu configuración de Claude: En tu claude-desktop-config.json, añade lo siguiente a la sección mcpServers:

{
    "mcpServers": {
        "stockflow": {
            "command": "python",
            "args": ["path/to/stockflow.py"]
        }
    }
}

Reemplaza "path/to/stockflow.py" con la ruta completa donde guardaste el archivo stockflow.py.

Prompt de uso para Claude

Cuando trabajes con Claude, puedes usar este prompt para ayudarle a entender las herramientas disponibles:

"He habilitado las herramientas de stockflow que te dan acceso a los datos del mercado de valores. Puedes usar estas tres funciones principales:

  1. get_stock_data - Obtén información completa de la acción:

{
    "symbol": "AAPL",
    "include_financials": true,  # optional
    "include_analysis": true,    # optional
    "include_calendar": true     # optional
}

  1. get_historical_data - Obtén historial de precios e indicadores técnicos:

{
    "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
}

  1. get_options_chain - Obtén datos de opciones:

{
    "symbol": "AAPL",
    "expiration_date": "2024-12-20",  # optional - uses nearest date if not specified
    "include_greeks": true            # optional
}

Todas las respuestas incluyen datos de precios actuales, manejo de errores e información completa del mercado."

Ejecutando el servidor

python stockflow.py

Usando con el cliente 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())

Herramientas disponibles

  1. get-stock-data

    • Precio y volumen actuales

    • Capitalización de mercado y ratio P/E

    • Máximo/mínimo de 52 semanas

  2. get-historical-data

    • Precios OHLC

    • Períodos de tiempo configurables

    • Datos de volumen

  3. get-options-chain

    • Calls y puts

    • Precios de ejercicio

    • Griegas e IV

    • Volumen e interés abierto

Recursos disponibles

  1. company-info://{symbol}

    • Descripción de la empresa

    • Sector e industria

    • Número de empleados

    • Sitio web

  2. financials://{symbol}

    • Estado de resultados

    • Balance general

    • Estado de flujo de efectivo

Prompts

  1. analyze-options

    • Análisis de estrategias de opciones

    • Evaluación de riesgo/recompensa

    • Evaluación de condiciones del mercado

Requisitos

  • Python 3.12+

  • mcp

  • yfinance

Limitaciones

  • Los datos provienen de Yahoo Finance y pueden tener retrasos

  • La disponibilidad de datos de opciones depende del horario del mercado

  • Se aplican límites de velocidad según las restricciones de la API de Yahoo Finance

Contribuciones

¡Las contribuciones son bienvenidas! No dudes en enviar un Pull Request.

Licencia

Este proyecto está licenciado bajo la Licencia MIT - consulta el archivo LICENSE para más detalles.

Autor

Todd Wolven - Desarrollador principal de software de IA e ingeniero de GenAI de código abierto

Agradecimientos

  • Construido con el Model Context Protocol (MCP) de Anthropic

  • Datos proporcionados por Yahoo Finance

  • Desarrollado para su uso con Claude de Anthropic

Available Tools

3 tools
get_historical_data_v2C

Get unadjusted/repaired price history and technical indicators.

ParametersJSON Schema
NameRequiredDescriptionDefault
periodYesYahoo Finance history period
symbolYesYahoo Finance ticker symbol
prepostNo
intervalNoHistory sampling interval1d

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes
successYes
providerYes
warningsYes
timestampYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesYahoo Finance ticker symbol
include_greeksNo
expiration_dateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes
successYes
providerYes
warningsYes
timestampYes

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesYahoo Finance ticker symbol
include_analysisNo
include_calendarNo
include_financialsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes
successYes
providerYes
warningsYes
timestampYes

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv2.1.0
    • First observedget_historical_data_v2
    • First observedget_options_chain_v2
    • First observedget_stock_data_v2
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • OptionsFlow MCP Server

    twolven
    A
    license
    B
    quality
    B
    maintenance
    A Model Context Protocol server that enables LLMs to analyze options chains, calculate Greeks, and evaluate basic options strategies through Yahoo Finance data.
    1
    40
    MIT

  • MCP Yahoo Finance

    maxscheijen
    A
    license
    B
    quality
    A
    maintenance
    A Model Context Protocol server that enables interaction with Yahoo Finance to retrieve stock pricing, company information, and historical financial data through natural language queries.
    21
    576 PyPI
    28
    MIT

  • MCP Yahoo Finance

    marckwei
    A
    license
    C
    quality
    Not graded
    maintenance
    A 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.
    11
    MIT

  • Yahoo Finance MCP Server

    16Coffee
    A
    license
    C
    quality
    D
    maintenance
    A 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.
    34
    MIT

Appeared in Searches