Which integrations are available for this server?

Uses OpenAI's API to generate AI analyst reports streamed via MCP progress notifications.

How do I use MarketMind MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MarketMind MCP Research NVDA stock" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MarketMind MCP

by mfarhan0304

Overview Schema Related Servers Score Discussions

Python

Remote

MarketMind MCP

A financial research MCP server built with FastMCP, Pydantic v2, and LangGraph.

Exposes 4 tools over the Model Context Protocol that any MCP-compatible client (Claude Desktop, Cursor, etc.) can call. Includes a LangGraph workflow that chains the tools into a multi-step research pipeline.

Tools

Tool	Description
`get_stock_quote`	Latest price, change %, and volume for a ticker
`get_historical_prices`	OHLC price history for a given period
`compute_rsi`	RSI indicator with overbought/oversold classification
`generate_research_report`	Streams an AI analyst report token-by-token via MCP progress notifications

Related MCP server: Finance MCP Server

Prerequisites

Python 3.11+
uv
OpenAI API key (for generate_research_report)

Setup

git clone https://github.com/your-username/marketmind-mcp
cd marketmind-mcp
uv sync
cp .env.example .env
# Add your OPENAI_API_KEY to .env

Usage

Run as MCP server (connect to Claude Desktop)

uv run marketmind

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "marketmind": {
      "command": "uv",
      "args": ["run", "marketmind"],
      "cwd": "/path/to/marketmind-mcp"
    }
  }
}

Once connected, Claude Desktop can call all 4 tools. generate_research_report streams the analyst report token-by-token via MCP progress notifications — the report appears in real-time as it is written.

Run the LangGraph workflow directly (CLI)

uv run python -m marketmind.workflow NVDA

Example output:

Researching NVDA...

[market_node]  NVDA  $924.18  (+2.51%)
[market_node]  RSI(14): 55.61  → neutral
[news_node]    5 headlines fetched

========================================================
  RESEARCH REPORT: NVDA
  Generated: 2026-03-16 05:57 UTC
========================================================

Summary
  NVIDIA continues to exhibit strong bullish momentum, driven by accelerating
  data centre GPU demand and positive earnings revisions.

Price Action
  NVDA is up 2.51% today at $924.18, breaking above the 20-day moving average
  on above-average volume.

Momentum
  RSI(14) at 55.6 signals healthy momentum without approaching overbought territory.

News Context
  Recent headlines highlight record Blackwell GPU shipments and expanded
  hyperscaler contracts.

Outlook: BULLISH

For informational purposes only. Not financial advice.

Inspect tools interactively

uv run fastmcp inspect src/marketmind/server.py

Opens the FastMCP inspector in your browser — lets you call any tool manually and inspect inputs, outputs, and schemas.

Run Tests

uv run pytest -v

45 tests covering business correctness, input security, and workflow resilience.

Stack

Layer	Technology
MCP server	`fastmcp` 3.x
Schema validation	`pydantic` v2
Orchestration	`langgraph`
LLM	`openai` (GPT-4o)
Market data	`yfinance`
News	Yahoo Finance RSS via `feedparser` + `httpx`

Available Tools

4 tools

compute_rsiA

Compute the Relative Strength Index (RSI) for a stock.

Returns the RSI value (0–100) and a signal:

overbought: RSI ≥ 70 (potential sell pressure)
oversold: RSI ≤ 30 (potential buy opportunity)
neutral: RSI between 30 and 70

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	RSI lookback period in days (default 14)
`symbol`	Yes	Stock ticker symbol

Output Schema

ParametersJSON Schema

Name	Required	Description
`rsi`	Yes	RSI value (0–100)
`period`	Yes
`signal`	Yes	overbought ≥ 70 \| oversold ≤ 30 \| neutral otherwise
`symbol`	Yes

TDQS

A3.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 full burden. It discloses the output structure (RSI value, signal with thresholds: overbought, oversold, neutral) and implies it is a read-only computation. It does not mention potential side effects or auth, but for a stateless computation this is acceptable.

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 (4 lines) and front-loaded with the key action. The formatting with blank lines is slightly wasteful but does not hinder readability. Every sentence adds value.

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 2-parameter tool with an output schema, the description adequately explains the return value structure (RSI value and signal classification). It is complete enough for an AI agent to understand the tool's function and outputs.

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% with descriptions for both parameters (symbol, period). The description does not add any new parameter semantics beyond the schema, but it is not required to. Baseline 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 states 'Compute the Relative Strength Index (RSI) for a stock,' which is a specific verb+resource. It clearly distinguishes this tool from siblings like get_historical_prices or generate_research_report by focusing on a single technical indicator.

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?

No explicit guidance is provided on when to use this tool vs alternatives (e.g., when to use RSI over other indicators, or when to use this tool instead of generating a full research report). The description only explains the output signal thresholds, not the broader decision context.

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

generate_research_reportA

Generate a streaming AI research report for a stock.

Fetches the latest quote, RSI(14), price history, and recent news concurrently, then streams a narrative analyst report token-by-token via MCP progress notifications — so the client sees output as it is written rather than waiting for the full response.

Returns the complete report text when finished.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Stock ticker to research, e.g. NVDA

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/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 transparently describes concurrent fetching, streaming via MCP progress notifications, token-by-token output, and return of complete text. This provides a clear understanding of 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 concise, with the first sentence stating the purpose, followed by details on process and output. No wasted words; structured for readability.

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?

With an output schema present, description does not need to detail return values. It covers input (symbol), process (concurrent fetches, streaming), and output (complete report). Adequate for a single-parameter tool with high schema coverage.

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 100% (the schema includes 'Stock ticker to research, e.g. NVDA'). The tool description adds no additional meaning beyond the schema. Baseline 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 'Generate a streaming AI research report for a stock.' The verb 'generate' and resource 'research report' are specific. It distinguishes itself from sibling tools (compute_rsi, get_historical_prices, get_stock_quote) by being a higher-level composite tool.

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 implies usage: for a comprehensive report, use this tool. However, it does not explicitly state when to use it versus siblings or provide exclusion criteria. The context is clear but not explicit.

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

get_historical_pricesA

Retrieve OHLC price history for a stock over a given period.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	How far back to retrieve data (default 1mo)	1mo
`symbol`	Yes	Stock ticker symbol
`interval`	No	Bar interval (default 1d)	1d

Output Schema

ParametersJSON Schema

Name	Required	Description
`bars`	Yes
`period`	Yes
`symbol`	Yes
`interval`	Yes

TDQS

A3.6/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 correctly implies a read operation ('Retrieve'), but does not disclose other behavioral traits such as authentication requirements, rate limits, or whether the data is cached. For a simple historical data tool, this is adequate but not comprehensive.

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, concise sentence with no unnecessary words. It is front-loaded and efficient.

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 that an output schema exists, the description does not need to explain return values. It covers the core action and scope. However, it could mention that the data is historical and that interval is optional, but the schema handles that. Overall, it is complete for a tool of this complexity.

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%, so the baseline is 3. The description adds no additional meaning beyond the schema; it mentions 'OHLC price history' but does not elaborate on the specific fields returned. The schema already documents parameters with enums and defaults, so the description is sufficient but not exemplary.

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 action ('Retrieve'), the resource ('OHLC price history'), and the scope ('for a stock over a given period'). It effectively distinguishes from siblings like get_stock_quote (current price) and compute_rsi (derived indicator).

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it, such as for current prices (use get_stock_quote) or for technical indicators (use compute_rsi).

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

get_stock_quoteB

Get the latest price, daily change %, and trading volume for a stock.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Stock ticker symbol, e.g. NVDA

Output Schema

ParametersJSON Schema

Name	Required	Description
`price`	Yes	Latest trade price (USD)
`symbol`	Yes	Ticker symbol
`volume`	Yes	Most recent trading volume
`timestamp`	Yes	Time the quote was fetched (UTC)
`change_pct`	Yes	Daily change as a percentage

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It only states the data obtained (price, change, volume) but omits critical details such as data freshness (real-time vs delayed), error handling for invalid symbols, rate limits, or whether the data is from a live or simulated source. This is insufficient for reliable agent decision-making.

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 sentence that front-loads the key outputs. Every word is informative; no fluff or repetition. It achieves maximum conciseness while conveying essential functionality.

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 (one parameter, clear output), and the presence of an output schema (context signal), the description is mostly complete. It covers what the tool returns. However, it lacks information about data sources or freshness, which slightly reduces completeness. Still, it is adequate for a straightforward stock quote lookup.

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 description coverage is 100% for the single parameter 'symbol'. The description adds no additional meaning beyond the schema's 'Stock ticker symbol, e.g. NVDA'. Per guidelines, with high coverage, baseline is 3. No extra value provided.

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 verb 'Get' and the resource 'latest price, daily change %, and trading volume for a stock'. It distinguishes from sibling tools: compute_rsi (RSI indicator), get_historical_prices (historical data), and generate_research_report (research). The purpose is specific and unambiguous.

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?

The description provides no guidance on when to use this tool versus its siblings. It does not mention that this is for current data vs historical data (get_historical_prices) or technical analysis (compute_rsi). The agent must infer usage from the tool names alone.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 6, 2026
- First observedcompute_rsi
- First observedgenerate_research_report
- First observedget_historical_prices
- First observedget_stock_quote

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct aspect of stock research: current quote, historical prices, RSI indicator, and a comprehensive research report. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (compute_rsi, generate_research_report, get_historical_prices, get_stock_quote), making the set predictable and easy to navigate.

Tool Count4/5

With 4 tools, the server is focused and each tool serves a clear purpose. While slightly lean for a research domain, the number is appropriate for the stated scope.

Completeness4/5

The tool set covers core stock research needs: quote, history, RSI, and a report that aggregates data and news. Missing standalone news or fundamental data, but the report compensates, so only minor gaps exist.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Drillr — The financial MCP for AI agents A
ai.drillr
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Finance Research & Data Data Platforms
1036
profitability-market A
io.finance-tools.market
Deterministic profitability and market-value analysis tools for AI agents — margins, ROA, ROE, ROCE, ROIC, EPS, P/E, P/B, dividend yield and payout ratio via Model Context Protocol. Useful for corporate finance, equity analysis, financial analysis, quantitative analysis, financial formulas and financial modeling.
Finance Research & Data
121
ShinobiDataOAuth
com.shinobidata
Portfolio analytics + US-equity market research for AI clients. ChatGPT deep-research compat.
Finance Research & Data
2
Bullrun A
org.bull-run
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Finance AI & Machine Learning Research & Data
303

Related MCP Servers

MCP Yahoo Finance
Finance Search
leoncuhk
F
license
B
quality
D
maintenance
Provides tools to get financial data (stock prices, company information) and generate financial visualizations through the Model Context Protocol.
Updated a year ago (2025-04-28 02:10 UTC)
10
11
-
Finance MCP Server
Finance RAG Systems
dino65-dev
A
license
Not graded
quality
D
maintenance
Provides real-time financial data from Yahoo Finance to Large Language Models through the Model Context Protocol, enabling AI models to access stock prices, historical data, and company information.
Updated a year ago (2025-04-18 07:41 UTC)
1
MIT
Stock Analysis MCP Server
Finance Search
TanayPhatak
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides stock technical analysis tools (moving averages, RSI, trade recommendations) for AI assistants to analyze stocks and offer trading signals.
Updated a year ago (2025-07-29 05:47 UTC)
-
Yahoo Finance MCP Server
Finance Search
laxmimerit
A
license
A
quality
C
maintenance
Provides access to real-time stock prices, financial statements, news, and options data via the Model Context Protocol. It enables AI assistants to retrieve comprehensive market data, including historical prices and analyst recommendations, through a standardized interface.
Updated 9 months ago (2025-12-11 09:09 UTC)
6
9
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mfarhan0304/MCP-MarketMind'

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