Skip to main content
Glama
jon-fox

Agentic-Investor

by jon-fox
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Agentic-Investor: A Financial Analysis MCP Server

Overview

The Agentic-Investor is a Model Context Protocol (MCP) server that provides comprehensive financial insights and analysis to Large Language Models. It leverages real-time market data, fundamental and technical analysis to deliver:

  • Market Movers: Top gainers, losers, and most active stocks with support for different market sessions

  • Ticker Analysis: Company overview, news, metrics, analyst recommendations, and upgrades/downgrades

  • Options Data: Filtered options chains with customizable parameters

  • Historical Data: Price trends and earnings history

  • Financial Statements: Income, balance sheet, and cash flow statements

  • Ownership Analysis: Institutional holders and insider trading activity

  • Earnings Calendar: Upcoming earnings announcements with date filtering

  • Market Sentiment: CNN Fear & Greed Index, Crypto Fear & Greed Index, and Google Trends sentiment analysis

  • Technical Analysis: SMA, EMA, RSI, MACD, BBANDS indicators (optional)

  • Intraday Data: 15-minute historical stock bars via Alpaca API (optional)

The server integrates with yfinance for market data and automatically optimizes data volume for better performance.

Related MCP server: StockMCP

Architecture & Performance

Robust Caching & Error Handling Strategy:

  1. yfinance[nospam] → Built-in smart caching + rate limiting for Yahoo Finance API

  2. hishel → HTTP response caching for external APIs (CNN, crypto, earnings data)

  3. tenacity → Retry logic with exponential backoff for transient failures

This multi-layered approach ensures reliable data delivery while respecting API rate limits and minimizing redundant requests.

Prerequisites

  • Python: 3.12 or higher

  • Package Manager: uv. Install if needed:

    curl -LsSf https://astral.sh/uv/install.sh | sh

Optional Dependencies

Installation

Quick Start

# Core features only
uvx agentic-investor

# With technical indicators (requires TA-Lib)
uvx "agentic-investor[ta]"

# With Alpaca intraday data (requires Alpaca API keys)
uvx "agentic-investor[alpaca]"

# With all optional features
uvx "agentic-investor[ta,alpaca]"

Tools

Market Data

  • get_market_movers(category="most-active", count=25, market_session="regular") - Market movers data including top gainers, losers, or most active stocks. Supports different market sessions (regular/pre-market/after-hours) for most-active category. Returns up to 100 stocks with cleaned percentage changes, volume, and market cap data

  • get_ticker_data(ticker, max_news=5, max_recommendations=5, max_upgrades=5) - Comprehensive ticker report with essential field filtering and configurable limits for news, analyst recommendations, and upgrades/downgrades

  • get_options(ticker_symbol, num_options=10, start_date=None, end_date=None, strike_lower=None, strike_upper=None, option_type=None) - Options data with advanced filtering by date range (YYYY-MM-DD), strike price bounds, and option type (C=calls, P=puts)

  • get_price_history(ticker, period="1mo") - Historical OHLCV data with intelligent interval selection: daily intervals for periods ≤1y, monthly intervals for periods ≥2y to optimize data volume

  • get_financial_statements(ticker, statement_types=["income"], frequency="quarterly", max_periods=8) - Financial statements with parallel fetching support. Returns dict with statement type as key

  • get_institutional_holders(ticker, top_n=20) - Major institutional and mutual fund holders data

  • get_earnings_history(ticker, max_entries=8) - Historical earnings data with configurable entry limits

  • get_insider_trades(ticker, max_trades=20) - Recent insider trading activity with configurable trade limits

  • get_nasdaq_earnings_calendar(date=None, limit=100) - Upcoming earnings announcements using Nasdaq API (YYYY-MM-DD format, defaults to today).

  • fetch_intraday_data(stock, window=200) - Fetch 15-minute historical stock bars using Alpaca API. Returns CSV string with timestamp and close price data in EST timezone. Requires agentic-investor[alpaca] installation and ALPACA_API_KEY/ALPACA_API_SECRET environment variables.

Market Sentiment

  • get_cnn_fear_greed_index(indicators=None) - CNN Fear & Greed Index with selective indicator filtering. Available indicators: fear_and_greed, fear_and_greed_historical, put_call_options, market_volatility_vix, market_volatility_vix_50, junk_bond_demand, safe_haven_demand

  • get_crypto_fear_greed_index() - Current Crypto Fear & Greed Index with value, classification, and timestamp

  • get_google_trends(keywords, period_days=7) - Google Trends relative search interest for market-related keywords. Requires a list of keywords to track (e.g., ["stock market crash", "bull market", "recession", "inflation"]). Returns relative search interest scores that can be used as sentiment indicators.

Technical Analysis

  • calculate_technical_indicator(ticker, indicator, period="1y", timeperiod=14, fastperiod=12, slowperiod=26, signalperiod=9, nbdev=2, matype=0, num_results=100) - Calculate technical indicators (SMA, EMA, RSI, MACD, BBANDS) with configurable parameters and result limiting. Returns dictionary with price_data and indicator_data as CSV strings. matype values: 0=SMA, 1=EMA, 2=WMA, 3=DEMA, 4=TEMA, 5=TRIMA, 6=KAMA, 7=MAMA, 8=T3. Requires TA-Lib library.

Usage with MCP Clients locally

Install mcp-remote

https://www.npmjs.com/package/mcp-remote

npm i mcp-remote

Start the server and add to your claude_desktop_config.json:

uv run python -m agentic_investor.server
{
  "mcpServers": {
    "Agentic-Investor": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://0.0.0.0:8000/mcp",
        "--allow-http"
      ]
    }
  }
}

Local Testing

For local development and testing, use the included chat.py script:

# Install dev dependencies
uv sync --group dev

# Set up your API key
export OPENAI_API_KEY="your-api-key"  # or ANTHROPIC_API_KEY, GEMINI_API_KEY, etc.

# Optional: Set custom model (defaults to openai:gpt-5-mini)
export MODEL_IDENTIFIER="your-preferred-model"

# Run the chat interface
python chat.py

For available model providers and identifiers, see the pydantic-ai documentation.

Debugging

MCP Inspector

npx @modelcontextprotocol/inspector uvx agentic-investor

Debug Logging

Enable detailed debug logging for development and troubleshooting:

# Enable debug logging
export DEBUG_LOGGING=true

# Run with debug logging
DEBUG_LOGGING=true python -m agentic_investor.server

See DEBUG_LOGGING.md for more details on what gets logged and how to use it.

License

MIT License. See LICENSE file for details.

Available Tools

14 tools
calculate_technical_indicatorA

Calculate professional technical analysis indicators using TA-Lib including: Simple Moving Average (SMA), Exponential Moving Average (EMA), Relative Strength Index (RSI), Moving Average Convergence Divergence (MACD with signal line and histogram), and Bollinger Bands (upper/middle/lower bands with standard deviation). Use this when asked about technical analysis, chart indicators, overbought/oversold conditions (RSI), trend identification (moving averages), momentum signals (MACD), volatility analysis (Bollinger Bands), support/resistance levels, crossover signals, or trading indicators. Supports customizable time periods (5-200 periods), lookback windows (1 month to 5 years), and moving average types. Returns up to 1000 data points. Example: "Calculate RSI for AAPL" or "Show me 50-day and 200-day moving averages for SPY".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses use of TA-Lib, customizable periods, lookback windows, and a return limit of 1000 data points. It lacks details on error handling and data source reliance, but is transparent about its core behavior.

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 informative but slightly verbose. It is well-structured with a clear hierarchy: purpose, list of indicators, use cases, customization, and examples. Could be more concise without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of output schema, the description covers purpose, parameters, and return limit but fails to specify the return format (e.g., data points with dates and values). This gap reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema parameter descriptions cover all parameters, giving a baseline of 3. The description adds value by explaining usage context, providing examples, and grouping parameters by indicator, enhancing understanding beyond the schema.

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 clearly states the tool calculates technical indicators using TA-Lib and lists specific indicators (SMA, EMA, RSI, MACD, BBANDS). It differentiates from sibling tools like get_price_history by specifying use cases for technical analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool, such as for overbought/oversold conditions, trend identification, and momentum signals. It also hints at alternatives by listing sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_intraday_dataA

Fetch high-resolution 15-minute interval stock price data (bars) using Alpaca market data API. Returns timestamp and close price for each 15-minute period in EST timezone. Supports up to 1000 bars (roughly 10 trading days of intraday data). Use this when asked about intraday price action, today's trading pattern, minute-by-minute movement, recent price fluctuations, current session behavior, or short-term price trends. Perfect for day trading analysis, identifying intraday support/resistance, or examining recent volatility. Example: "Show me TSLA's price movement today" or "What's the intraday chart for AAPL?".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses behavioral traits: 15-minute resolution, returns timestamp and close price, EST timezone, max 1000 bars (~10 trading days), and data source (Alpaca). It does not cover rate limits or authentication, but provides key 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two paragraphs, front-loaded with the core action, and provides usage guidance without unnecessary words. It is efficient but could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description covers input constraints, output format, and use cases. It lacks data delay or error handling info, but is adequately complete for a straightforward data fetch tool.

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 0% (description doesn't include parameter descriptions), but the schema itself describes parameters well. The description adds context about output (timestamp, close price) and the max bars limit, partially compensating for low coverage. However, it doesn't elaborate on parameter details beyond the schema.

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 clearly states the tool fetches high-resolution 15-minute stock price data, specifying the verb 'fetch', the resource 'intraday stock price data', and distinguishes from siblings like get_price_history by emphasizing intraday granularity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool (e.g., intraday price action, today's trading pattern) and provides example queries. However, it does not mention when not to use it or explicitly reference sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cnn_fear_greed_indexA

Get CNN's Fear & Greed Index showing overall stock market sentiment (0-100 scale) with detailed breakdowns of seven key indicators: VIX volatility levels, put/call option ratios, junk bond demand vs investment grade, safe haven demand (bonds vs stocks), market momentum, stock price strength, and market breadth. Use this when asked about market sentiment, investor psychology, risk appetite, bull/bear market conditions, whether markets are overbought/oversold, or overall market health. Scale: 0=extreme fear, 100=extreme greed.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4/5.0
Behavior3/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. It explains the scale (0=extreme fear, 100=extreme greed) and enumerates the seven indicators, but does not disclose side effects, network dependencies, or caching behavior.

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 two sentences: the first defines the tool and its components, the second provides usage guidance. No redundant words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple data retrieval tool with one parameter and no output schema, the description covers purpose, components, and usage. However, it lacks details about the output format, which would enhance completeness.

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?

The schema already describes the 'indicators' parameter with a clear description and default. The tool description does not add meaning beyond the schema; it mentions the indicators in general but not how to specify them via the parameter.

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 explicitly states the tool retrieves CNN's Fear & Greed Index with a 0-100 scale and lists seven specific indicators. It distinguishes from sibling 'get_crypto_fear_greed_index' by specifying 'stock market sentiment'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a clear directive: 'Use this when asked about...' with specific scenarios like market sentiment and investor psychology. It provides context but does not mention 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_crypto_fear_greed_indexB

Get the current Crypto Fear & Greed Index (0-100 scale) from Alternative.me, indicating cryptocurrency market sentiment where 0 represents extreme fear and 100 represents extreme greed. Use this when asked about crypto market sentiment, investor psychology in digital assets, Bitcoin market mood, altcoin risk appetite, or whether it's a good time to buy/sell cryptocurrencies. Includes historical data and trend analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the scale and indicates historical data and trend analysis are included, but lacks details on data freshness, authentication, or rate limits, which are important for a tool accessing an external API.

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 concise with two sentences. The first defines the tool, the second provides usage context and capabilities. It is efficiently worded, though could benefit from slight restructuring to separate purpose from usage guidance.

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?

Given the simple input (one parameter) and no output schema, the description should fully cover usage. It explains the output but leaves the input parameter entirely undocumented, making the tool incomplete for an agent to invoke correctly without additional knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single required parameter 'input_data' with no defined properties and 0% schema coverage. The description does not explain what this parameter expects, leaving the agent without guidance on how to structure the input, thus failing to add meaning beyond the minimal schema.

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 clearly states the tool retrieves the Crypto Fear & Greed Index from Alternative.me on a 0-100 scale, and distinguishes it from the sibling get_cnn_fear_greed_index by specifying the source. It provides specific verb and resource, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases such as crypto market sentiment, investor psychology, and timing buy/sell decisions, giving clear context for when to invoke. However, it does not specify when not to use or mention alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_earnings_historyA

Get historical quarterly earnings results including EPS estimates (analyst consensus), actual reported EPS, earnings surprise amounts and percentages, and earnings announcement dates. Returns up to 50 historical earnings reports. Use this when asked about earnings beats/misses, earnings surprise history, quarterly results trends, how often a company beats estimates, earnings consistency, EPS growth trajectory, or past earnings performance. Helps identify companies that consistently beat/miss expectations. Example: "Has NVDA been beating earnings?" or "Show me TSLA's earnings surprise history".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.3/5.0
Behavior4/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. It discloses that the tool returns up to 50 reports and includes key data fields. It implies read-only historical access, which is appropriate for a data retrieval tool. Could explicitly state 'read-only' for clarity.

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 concise, front-loaded with purpose, includes usage guidance, and example queries. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description compensates by listing the data fields returned (EPS estimates, actuals, surprises, dates). For a simple data retrieval tool with 1 parameter, this is complete and sufficient.

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?

The input schema provides detailed descriptions for both parameters (ticker, max_entries) with defaults and constraints. The description adds minimal extra meaning beyond noting the 50-entry limit already in the schema. Given schema coverage, a score of 3 is appropriate.

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 clearly states the tool retrieves historical quarterly earnings results with specific data points (EPS estimates, actuals, surprises, dates). It distinguishes this tool from sibling 'get_nasdaq_earnings_calendar' by focusing on historical data rather than upcoming events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists when to use the tool (e.g., earnings beats/misses, consistency, trends) and provides example queries. It does not explicitly state when not to use it, but the context is clear and differentiates from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_financial_statementsA

Get detailed financial statements including income statements (revenue, expenses, net income, EPS), balance sheets (assets, liabilities, equity, cash, debt), and cash flow statements (operating cash flow, investing activities, financing activities, free cash flow). Supports both quarterly and annual reporting frequencies with up to 20 historical periods. Use this when asked about company financials, revenue trends, profitability, cash position, debt levels, financial health, accounting metrics, earnings quality, or fundamental analysis. Essential for DCF models, financial modeling, and deep-dive company research. Returns data in structured format with all line items. Example: "Show me AAPL's last 8 quarters of income statements" or "Get TSLA's annual balance sheets".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses key behaviors: supports quarterly/annual frequencies, up to 20 periods, and returns structured data. It does not mention idempotency, error handling, or data source, but covers main aspects.

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 well-organized and front-loaded with the purpose. It lists many line items which adds verbosity but is helpful. Could be slightly more concise, but overall efficient.

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?

No output schema is provided, so the description should cover return format. It states 'structured format with all line items' which is vague but adequate with the examples. Given the tool's complexity, more detail could be added.

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?

The input schema already contains detailed descriptions and examples for each parameter. The description adds context by explaining what the returned data contains, but does not add new parameter-level meaning beyond what the schema provides.

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 clearly states it retrieves detailed financial statements, listing specific line items like income statements, balance sheets, and cash flow statements. It is distinct from sibling tools which focus on price history, options, or technical indicators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool, e.g., 'when asked about company financials, revenue trends, profitability,' and provides example queries. It does not explicitly state when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_insider_tradesA

Get recent insider trading activity including executive and director transactions: stock purchases, sales, option exercises, and other reportable transactions. Returns up to 100 recent trades with insider name, title, transaction type, share count, price per share, total value, and filing date. Use this when asked about insider buying/selling, whether executives are confident, if insiders are dumping stock, insider sentiment, Form 4 filings, C-suite transactions, or director activity. Heavy insider buying can signal confidence while selling may indicate concerns. Example: "Are AAPL insiders buying?" or "Show me recent insider sales at TSLA".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior. It states the tool 'Returns up to 100 recent trades' and lists output fields. However, it does not specify the recency window, whether data is real-time or delayed, or any access limitations.

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 informative with an example and use cases. Slightly verbose but well-structured, with key information front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description fully enumerates the 7 fields returned (insider name, title, transaction type, share count, price per share, total value, filing date), making the tool's output predictable.

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 coverage is 100% (both parameters described in schema). The description adds examples but does not substantially enhance understanding beyond the schema's own descriptions.

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-resource combination: 'Get recent insider trading activity'. It clearly distinguishes the tool's purpose from sibling tools like get_price_history or get_financial_statements by listing exact transaction types and citing example queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use cases are provided (e.g., 'when asked about insider buying/selling', 'Are AAPL insiders buying?') and interpretive context ('Heavy insider buying can signal confidence while selling may indicate concerns'). However, it does not explicitly state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_institutional_holdersA

Get major institutional shareholders and mutual fund holders including their position sizes, share counts, percentage of total shares owned, and position values. Returns top 20-100 largest holders. Use this when asked about institutional ownership, who owns the most shares, major shareholders, hedge fund positions, mutual fund holdings, institutional support, ownership concentration, or smart money positioning. High institutional ownership often indicates confidence while institutions selling can signal concerns. Example: "Who are the biggest holders of NVDA?" or "Show me institutional ownership of TSLA".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that it returns top 20-100 largest holders and explains output fields. It mentions high institutional ownership as a signal, which adds context. It does not discuss rate limits or authorization, but for a read-only data tool, this is sufficient.

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 front-loaded with the action and includes examples, but it is slightly verbose with multiple clauses. It could be more concise, but the information is well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return fields (position sizes, shares, etc.). It provides use cases and examples. Missing details like error handling or pagination, but the tool is simple and the description covers core aspects.

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?

The input schema already provides descriptions for ticker and top_n, including default and range. The description only adds that top_n returns 20-100 holders, which is already in the schema. It does not add new parameter-specific meaning beyond what the schema offers.

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 clearly states it retrieves major institutional shareholders and mutual fund holders, including specific data fields like position sizes and share counts. It distinguishes itself from sibling tools (e.g., get_insider_trades, get_price_history) by focusing on institutional ownership.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (e.g., 'when asked about institutional ownership') and provides example queries. It does not mention when not to use it or alternative tools, but the provided examples and context are adequate for guiding usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_market_moversA

Identify top gaining stocks (biggest winners), biggest losing stocks (worst performers), and most actively traded securities by volume in real-time or recent trading sessions. Use this when asked about "what's hot", "what's moving", market leaders, volatile stocks, today's biggest movers, stocks making news, pre-market activity, or after-hours trading action. Supports filtering by market session: regular hours, pre-market, and after-hours. Returns up to 100 stocks with price, volume, and percentage change data.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It discloses it returns up to 100 stocks with price, volume, and percentage change, and indicates real-time/recent sessions. No mention of auth needs or rate limits, but adequate for a read tool.

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?

Four sentences, each with clear purpose: function, usage, filtering, output. No redundant information. Front-loaded with purpose and usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description covers return data (price, volume, percentage change). Parameter count is low and explained via schema and description. Slightly lacking in full parameter detail but sufficient for agent use.

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 coverage is 0%, but description adds value by explaining filtering by market session and categories implicitly. The schema itself provides enums and descriptions, but the tool description does not describe the input_data structure directly, relying on the schema.

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?

Clearly states the tool identifies top gainers, losers, and most active securities by volume. Provides specific synonyms like 'what's hot' and 'what's moving', distinguishing it from sibling tools that retrieve other data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists usage scenarios, including phrases like 'what's hot', 'market leaders', and 'pre-market activity'. Supports filtering by market session but doesn't mention when not to use, though context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_nasdaq_earnings_calendarA

Get upcoming earnings announcements for a specific date showing company names, ticker symbols, earnings dates, EPS estimates (high/low/average), revenue estimates, and surprise history. Returns up to 500 companies reporting on the specified date. Use this when asked about earnings calendar, who reports today/tomorrow, upcoming earnings, what companies announce this week, earnings season schedule, or when specific companies report. Defaults to today's date if not specified. Essential for planning trades around earnings events and tracking market-moving announcements. Example: "Who reports earnings today?" or "Show me earnings calendar for next Friday".

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses behavioral traits: 'Returns up to 500 companies' (limit), 'Defaults to today's date if not specified'. It implies read-only and safe operation but could mention lack of side effects explicitly.

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 compact 4-sentence paragraph with no wasted words. It front-loads the main purpose and every sentence adds value: outputs, limit, usage scenarios, examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains return fields (company names, ticker, estimates). It also covers the date default and limit. Could mention error handling or response structure for missing data, but sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the top-level parameter, but the description adds meaning: explains date format, default behavior, and maximum limit. It compensates well, though the nested schema structure is not clarified.

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 clearly specifies the verb 'Get upcoming earnings announcements' and the resource 'for a specific date' with detailed outputs (company names, ticker, EPS estimates, etc.). It distinguishes from siblings like get_earnings_history by focusing on calendar date rather than historical data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios: 'Use this when asked about earnings calendar, who reports today/tomorrow...' and gives example queries. It does not explicitly state when not to use it or alternatives, but the context is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_optionsA

Retrieve options chain data including strike prices, expiration dates, bid/ask spreads, implied volatility, open interest, trading volume, and Greeks (delta, gamma, theta, vega) for both call and put options. Use this when asked about options strategies, checking option premiums, evaluating covered calls, analyzing protective puts, finding strike prices, assessing derivatives positions, volatility trading opportunities, or options expiring soon. Supports flexible filtering by strike price range, expiration date window (start/end dates), and option type (calls only, puts only, or both). Returns up to 1000 contracts per query. Example usage: AAPL calls expiring in 30 days, TSLA puts near current price.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.7/5.0
Behavior4/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. It discloses the return limit (1000 contracts) and filtering options. However, it does not explicitly state idempotency/read-only nature, though it is implied. Nearly complete.

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 well-structured, front-loading purpose, then usage, filtering, limits, and examples. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of options data and lack of output schema, the description covers all essential aspects: return data, filtering, limits, and example queries. It is sufficient for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value beyond the schema by explaining how filtering parameters (strike range, expiration window, option type) work together. While the schema has detailed descriptions for each parameter, the description provides usage context, compensating for the 0% reported coverage (likely a measurement issue).

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 clearly states the tool retrieves options chain data, listing specific data points (strike prices, Greeks, etc.) and filtering capabilities. It uses specific verbs and distinguishes this tool from siblings by focusing exclusively on options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use: 'Use this when asked about options strategies...' and provides concrete examples. Although it doesn't directly contrast with siblings, the sibling list contains no other options tool, and the description covers key usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_price_historyA

Get historical OHLCV (Open, High, Low, Close, Volume) stock price data with smart interval selection based on time period. Returns daily data for longer periods and intraday data for shorter periods. Use this when asked about price history, past performance, stock charts, historical trends, price patterns over time, year-to-date performance, or comparing current prices to historical levels. Supports periods: 1 day, 5 days, 1 month, 3 months, 6 months, 1 year, 2 years, 5 years, 10 years, year-to-date, and maximum available history. Perfect for backtesting, technical analysis, and historical comparisons. Works with any ticker: AAPL, TSLA, SPY, QQQ, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses smart interval selection (daily for longer, intraday for shorter). No annotations, so description carries burden. Sufficient for data retrieval, though lacks rate limits or error info.

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?

Concise, front-loaded with purpose, then usage guidance and details. Every sentence adds value. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers purpose, usage, and data for a simple tool with no output schema. Could include return format, but not essential given clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds meaning beyond schema: explains interval logic and lists periods in readable form. Schema covers basic param descriptions, but description enriches with usage context.

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?

Description clearly states 'Get historical OHLCV stock price data with smart interval selection', specifying verb and resource. It distinguishes from sibling tools like fetch_intraday_data by mentioning intraday for short periods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists scenarios when to use (e.g., 'price history, past performance, stock charts') and supported periods. Lacks explicit 'when not to use' but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ticker_dataA

Get comprehensive stock analysis including current price, daily volume, market capitalization, P/E ratios (trailing and forward), 52-week high/low range, beta, profit margins, revenue/earnings growth, book value, debt levels, and ROE/ROA metrics. Also includes up to 50 recent news headlines with sources and URLs, latest analyst recommendations (strong buy/buy/hold/sell/strong sell distribution), recent upgrades and downgrades from major firms, and upcoming earnings calendar dates with EPS estimates. Use this when asked about stock performance, company valuation, fundamentals, Wall Street sentiment, analyst opinions, recent company news, or financial health. Supports any public company ticker: AAPL, TSLA, MSFT, GOOGL, AMZN, NVDA, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_dataYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It comprehensively lists all returned data points: price, volume, P/E, news, recommendations, upgrades, earnings calendar. It is clearly a read-only operation with no destructive behaviors, though rate limits and authentication are not mentioned.

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 paragraph that front-loads the main purpose and then lists multiple output categories. It is dense but not verbose, with no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and no output schema, the description adequately covers the return values: fundamentals, news, recommendations, upgrades, earnings calendar. It is complete enough for an agent to understand what the tool provides.

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?

The input schema is self-documenting with descriptions for each parameter (e.g., ticker, max_news). The tool description does not add additional parameter semantics beyond what the schema provides. Schema coverage is 0% from the description, but the schema itself is clear.

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 clearly states the tool's purpose: 'Get comprehensive stock analysis including...' with a long list of specific data points. It distinguishes itself from sibling tools like get_earnings_history or get_options by offering a broad overview covering fundamentals, news, recommendations, and more.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this when asked about stock performance, company valuation, fundamentals, Wall Street sentiment, analyst opinions, recent company news, or financial health.' It does not specify when not to use, but the sibling list implies alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct aspect of investing (technical analysis, intraday data, sentiment indices, fundamentals, etc.). While get_price_history and fetch_intraday_data both provide price data, their granularities are clearly different (daily vs 15-min), and get_ticker_data combines current price with fundamentals, avoiding confusion.

Naming Consistency4/5

Most tools follow a 'get_noun' pattern (e.g., get_earnings_history, get_price_history), with exceptions: calculate_technical_indicator and fetch_intraday_data. This slight inconsistency is minor and still clear.

Tool Count5/5

14 tools is well-scoped for an investing research server, covering technical, fundamental, sentiment, and market data without being overwhelming.

Completeness4/5

The tools provide comprehensive coverage for stock and crypto research, including history, fundamentals, options, and sentiment. Minor gaps exist (e.g., no multi-ticker comparison or direct execution), but core workflows are supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Finnhub Server

    NimbleBrainInc
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides comprehensive financial market data and news through the Finnhub API. Enables real-time stock quotes, company profiles, financial metrics, analyst recommendations, and market news access.
    1
    MIT

  • StockMCP

    leogue
    F
    license
    Not graded
    quality
    F
    maintenance
    Provides real-time stock market data and financial analysis through Yahoo Finance integration. Enables users to get quotes, historical prices, fundamentals, dividends, analyst forecasts, and growth projections for any stock symbol.
    4

  • Finance MCP Server

    MCP-Mirror
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Provides real-time financial data from Yahoo Finance, enabling stock price lookups, historical data analysis, company information retrieval, and multi-stock comparisons through natural language queries.

  • Yahoo Finance MCP Server

    atishayjn
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides comprehensive financial data from Yahoo Finance, enabling retrieval of stock prices, company information, financial statements, options data, analyst recommendations, and market news through natural language queries.
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jon-fox/agentic-investor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server