Skip to main content
Glama
deenesjakoruzh
twolven

StockFlow MCP Server

by twolven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

StockFlow MCP Server

Ein Model Context Protocol (MCP)-Server, der Echtzeit-Aktiendaten und Optionsanalysen über Yahoo Finance bereitstellt. Ermöglicht LLMs den Zugriff auf Marktdaten, die Analyse von Aktien und die Bewertung von Optionsstrategien.

Funktionen

Aktiendaten

  • Echtzeit-Aktienkurse und wichtige Kennzahlen

  • Historische Kursdaten mit OHLC-Werten

  • Unternehmenskennzahlen und Finanzberichte

  • Marktindikatoren und Kennzahlen

Optionsanalyse

  • Vollständige Optionskettendaten

  • Griechen (Delta, Gamma, Theta, Vega)

  • Verfolgung von Volumen und offenem Interesse

  • Analyse von Optionsstrategien

Related MCP server: MCP Yahoo Finance

Installation

# Install dependencies
pip install mcp yfinance

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

Verwendung

  1. Klonen Sie das Repository:

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

  1. Installieren Sie die Abhängigkeiten:

pip install -r requirements.txt

  1. Fügen Sie zu Ihrer Claude-Konfiguration hinzu: Fügen Sie in Ihrer claude-desktop-config.json Folgendes zum Abschnitt mcpServers hinzu:

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

Ersetzen Sie "path/to/stockflow.py" durch den vollständigen Pfad zu der Stelle, an der Sie die Datei stockflow.py gespeichert haben.

Verwendungshinweis für Claude

Wenn Sie mit Claude arbeiten, können Sie diesen Hinweis verwenden, um ihm die verfügbaren Tools zu erklären:

"Ich habe die stockflow-Tools aktiviert, die Ihnen Zugriff auf Aktienmarktdaten geben. Sie können diese drei Hauptfunktionen verwenden:

  1. get_stock_data – Umfassende Aktieninformationen abrufen:

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

  1. get_historical_data – Kursverlauf und technische Indikatoren abrufen:

{
    "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 – Optionsdaten abrufen:

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

Alle Antworten enthalten aktuelle Kursdaten, Fehlerbehandlung und umfassende Marktinformationen."

Server ausführen

python stockflow.py

Verwendung mit MCP-Client

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())

Verfügbare Tools

  1. get-stock-data

    • Aktueller Preis und Volumen

    • Marktkapitalisierung und KGV

    • 52-Wochen-Hoch/Tief

  2. get-historical-data

    • OHLC-Kurse

    • Konfigurierbare Zeiträume

    • Volumendaten

  3. get-options-chain

    • Calls und Puts

    • Ausübungspreise

    • Griechen und IV

    • Volumen und offenes Interesse

Verfügbare Ressourcen

  1. company-info://{symbol}

    • Unternehmensbeschreibung

    • Sektor und Branche

    • Mitarbeiterzahl

    • Website

  2. financials://{symbol}

    • Gewinn- und Verlustrechnung

    • Bilanz

    • Kapitalflussrechnung

Prompts

  1. analyze-options

    • Analyse von Optionsstrategien

    • Risiko-/Ertragsbewertung

    • Bewertung der Marktbedingungen

Anforderungen

  • Python 3.12+

  • mcp

  • yfinance

Einschränkungen

  • Die Daten stammen von Yahoo Finance und können Verzögerungen aufweisen.

  • Die Verfügbarkeit von Optionsdaten hängt von den Marktzeiten ab.

  • Es gelten Ratenbegrenzungen basierend auf den Einschränkungen der Yahoo-Finance-API.

Mitwirken

Beiträge sind willkommen! Sie können gerne einen Pull Request einreichen.

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert – siehe die Datei LICENSE für Details.

Autor

Todd Wolven – Leitender KI-Softwareentwickler und Open-Source-GenAI-Ingenieur

Danksagungen

  • Erstellt mit dem Model Context Protocol (MCP) von Anthropic

  • Daten bereitgestellt von Yahoo Finance

  • Entwickelt für die Verwendung mit Claude von 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