Skip to main content
Glama
venkatk1801

market-pulse

by venkatk1801
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mcp-market-pulse

A Model Context Protocol server that gives Claude live market-data superpowers — plus a Claude-powered CLI client that answers natural-language questions about stocks.

Ask things like "is AAPL trending up? check the RSI" and watch Claude call real tools, read real prices, and reason over them.

You: is AAPL trending up? check the RSI
  [tool] indicator({"symbol": "AAPL", "kind": "rsi"})
  [tool] get_history({"symbol": "AAPL", "days": 30})
AAPL's RSI(14) is 62.4 — bullish momentum but not overbought (overbought is 70+).
Over the last 30 trading days it closed at $239.80, up from $219.00, with higher
highs through the window. Trend: up, momentum: strong but not extreme.

Tools

Tool

What it does

get_quote(symbol)

Latest price, day change vs previous close, OHLC, volume

get_history(symbol, days=30)

Daily OHLCV bars (up to 365 trading days)

indicator(symbol, kind)

rsi (RSI-14), sma (SMA-20), ema (EMA-20) — math implemented from scratch in indicators.py

market_status()

Whether the NYSE is open right now (ET, weekends + 2026 holidays)

Symbol handling: bare US tickers (AAPL), index aliases (^GSPC, DJI, ^IXIC), and crypto (BTC, ETH) all resolve to the right Stooq ticker.

Related MCP server: Yahoo Finance MCP Server

Architecture

┌──────────┐   tool calls    ┌────────────┐   JSON-RPC    ┌────────────┐   HTTPS   ┌───────┐
│  Claude  │ ◄─────────────► │ MCP client │ ◄───────────► │ MCP server │ ◄───────► │ Stooq │
│ (Sonnet) │  Messages API   │ (client.py)│     stdio     │ (server.py)│   CSV API │       │
└──────────┘                 └────────────┘               └────────────┘           └───────┘

The server speaks MCP over stdio (any MCP host — Claude Desktop, Claude Code — can use it). The bundled CLI client spawns the server itself and runs an agentic loop: Claude decides which tools to call, reads the results, and answers.

Install

Requires Python 3.10+.

git clone https://github.com/venkatk1801/mcp-market-pulse
cd mcp-market-pulse
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

Use with Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "market-pulse": {
      "command": "/absolute/path/to/mcp-market-pulse/.venv/bin/market-pulse-server"
    }
  }
}

Restart Claude Desktop and the four tools appear in the 🔌 menu.

Use the CLI client

The client needs an Anthropic API key:

cp .env.example .env   # then put your key in .env
# or: export ANTHROPIC_API_KEY=sk-ant-...
market-pulse "is NVDA overbought right now?"
market-pulse --interactive          # REPL mode
market-pulse --model claude-sonnet-4-5 "compare AAPL and MSFT this month"

Example session

$ market-pulse "is AAPL trending up? check RSI"
  [tool] indicator({'symbol': 'AAPL', 'kind': 'rsi'})
  [tool] get_quote({'symbol': 'AAPL'})
  [tool] market_status({})
AAPL is at $239.80 (+2.3% on the day) with RSI(14) at 62.4. The market is
currently open. Price is above its 20-day average and momentum is bullish
without being overbought — the trend is up.

Development

pytest            # 28 tests, no network (httpx is mocked)

Project layout:

src/market_pulse/
  server.py       MCP server (MCPServer from the official MCP Python SDK, stdio)
  client.py       agentic CLI client (Messages API tool-use loop over stdio)
  indicators.py   SMA / EMA / Wilder RSI, from scratch
  market_hours.py NYSE hours in America/New_York
tests/            indicator math, CSV parsing (mocked), market-hours logic

Data source & limits

  • Prices come from Stooq's free CSV endpoints — real market data, no API key. Quotes may be delayed ~15 minutes; daily bars are end-of-day.

  • get_quote uses Stooq's quote endpoint and falls back to the latest daily bar if it's unreachable (the source field tells you which served the data).

  • Change is measured against the previous daily close; after-hours quotes may look "stale" — that's the last print, not a bug.

  • market_status covers regular NYSE hours 09:30–16:00 ET, weekends, and a static 2026 holiday list. Early closes (e.g. day after Thanksgiving) are not modeled.

  • Not investment advice. This is a data pipe with a chatbot on top — do your own diligence.

License

MIT — see LICENSE.

Available Tools

4 tools
get_historyA

Daily OHLCV bars for a symbol, most recent days trading days.

days is clamped to 1-365.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
symbolYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description discloses one useful behavioral detail: days is clamped to 1-365. It does not describe ordering, timezone, or error handling behavior, but for a simple read-only historical-data tool this is reasonable transparency, though not rich.

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 compact, with the core purpose front-loaded and the clamping constraint in a short second sentence. There is no filler or repetition of schema fields.

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 two-parameter historical data tool with no output schema, the description covers the core behavior and the only non-obvious parameter constraint. It omits minor details like return formatting, but nothing essential to invoking it successfully is clearly missing.

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%, so the description must add meaning to parameters. It does clarify days as trading days clamped to 1-365, but the symbol parameter's semantics are not described beyond its name; overall the description partially compensates for the schema's lack of parameter documentation.

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 clearly identifies the tool as returning daily OHLCV bars for a symbol, which clearly distinguishes it from siblings like get_quote and market_status. It lacks an explicit verb like 'retrieves' or 'returns,' but the intended function is unambiguous.

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?

The description implies usage for historical daily price data by specifying OHLCV bars and a trailing window of trading days. However, it does not explicitly contrast this tool with get_quote or indicator or state when the agent should choose this over a sibling, so the guidance is only implied.

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

get_quoteA

Latest quote for a symbol: price, day change, OHLC and volume.

Accepts US tickers (AAPL), index aliases (^GSPC, DJI, ^IXIC) and crypto pairs (BTC, ETH). Change is measured against the previous daily close. If Stooq's live quote endpoint is unreachable, falls back to the latest daily bar (noted in the source field).

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYes

TDQS

A3.9/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 behavioral burden. It discloses accepted symbol classes, defines change against the previous daily close, and reveals the fallback to the latest daily bar with a source field when the live endpoint is unreachable. This goes well beyond a generic 'get quote' statement.

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 three concise sentences, front-loaded with a one-line summary followed by supporting details. Every sentence adds factual constraints—accepted symbols, change basis, and fallback behavior—with no filler or repetition.

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 lightweight single-parameter tool, the description covers accepted symbols, returned metrics, change reference, and fallback behavior. With no output schema, the first sentence's field enumeration helps, but the absence of explicit sibling routing leaves a small completeness gap.

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 schema has one required parameter, 'symbol', with no description, so the description is the only source of semantic detail. It provides concrete accepted forms (AAPL, ^GSPC, DJI, ^IXIC, BTC, ETH), which compensates for the 0% schema coverage. It doesn't specify exhaustive formats or case sensitivity, so it stops short of a 5.

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 opens with a specific verb and resource: 'Latest quote for a symbol' and lists the included fields (price, day change, OHLC, volume), so an agent knows exactly what is returned. It is distinguishable from siblings like get_history and market_status by the 'latest quote' framing, though it doesn't explicitly name alternatives.

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?

The description gives clear context for when to use the tool: to fetch a current quote with OHLC and volume. However, it never explicitly states when to prefer get_history or market_status instead, so the usage boundary is implied rather than stated.

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

indicatorB

Technical indicator for a symbol.

kind: "rsi" (RSI-14), "sma" (SMA-20) or "ema" (EMA-20). Returns the latest value plus the data window used.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNorsi
symbolYes

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations on the tool, the description is the only behavioral disclosure. It does state the output behavior 'Returns the latest value plus the data window used,' but it does not clarify the window's size or meaning, response format, error handling, or data source.

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 compact, front-loaded with the tool's purpose, and uses clear formatting for the kind values. It contains no redundant or filler content; each clause contributes.

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?

For a simple two-parameter tool with no output schema or annotations, the description covers the core purpose, parameter options, and return summary. However, it leaves important context undefined, such as what the data window contains, the symbol format, and how invalid values are handled.

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%, so the description must compensate for both parameters. It thoroughly defines kind with its allowed values and period meanings, but symbol is only referred to generically as 'a symbol' with no format or example.

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 clearly identifies a technical-indicator tool that returns the latest computed value and the data window used, and it names the supported kinds (rsi, sma, ema). This is enough to differentiate it from quote, history, and market-status siblings, though the sibling distinction is not explicitly stated.

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 usage conditions or exclusions are given; the description never tells an agent when to choose this tool over get_quote, get_history, or market_status. It only implies that indicator requests like RSI/SMA/EMA belong here, which is not explicit guidance.

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

market_statusA

Whether the US stock market (NYSE) is open right now, in ET.

Returns open/closed plus the reason (regular session 09:30-16:00 ET, pre-market, after-hours, weekend or market holiday).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/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 what the tool returns ('open/closed plus the reason') and enumerates possible reasons (regular session, pre-market, after-hours, weekend, holiday). This is transparent for a simple read-only query, though it does not explicitly state it has no side effects, which is implied.

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, front-loaded with the core purpose, and every phrase adds value. It is concise without sacrificing necessary detail.

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 that the tool has no parameters and no output schema, the description fully covers what the agent needs: it states the output format (open/closed plus reason) and the possible reason categories. There is nothing missing for correct invocation.

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 tool has zero parameters, so the baseline is 4. The description correctly omits parameter details because there are none. No additional semantic explanation is needed.

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 a specific verb+resource: 'Whether the US stock market (NYSE) is open right now, in ET.' It clearly identifies the market and the timezone, and it is distinct from siblings like get_quote, get_history, and indicator, which cover different data. The purpose is unambiguous.

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 implicitly communicates when to use this tool: when an agent needs to know the current market status. It does not explicitly mention alternatives, but since the sibling tools serve different purposes (quotes, history, indicators), no exclusions are necessary. The reason categories also help the agent understand the output context.

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. 4 tool updatesv0.1.0
    • First observedget_history
    • First observedget_quote
    • First observedindicator
    • First observedmarket_status
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

A3.8/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct data need: current quote, historical bars, computed indicator, and market hours. No tool's purpose overlaps with another, even though indicator and history both use price data.

Naming Consistency3/5

get_quote and get_history follow a clear get_<noun> pattern, but indicator and market_status are bare nouns without the get_ prefix. The snake_case style is uniform, yet the verb-prefix inconsistency makes the set feel mixed.

Tool Count5/5

Four tools is a compact, purposeful set for a market-data server. Each tool covers a distinct read-only concern without redundancy or bloat.

Completeness4/5

The server covers the core market-data needs: snapshot, historical daily data, derived indicators, and market hours. It lacks batch quotes, intraday bars, or symbol search, but these are optional extras rather than workflow-breaking gaps.

Resources

Related MCP Connectors

  • AIsa FinanceAOAuth
    one.aisa

    Your agent needs markets — prices and fundamentals for listed companies, the filings behind them, crypto, and what the prediction markets put the odds at. **What you can ask for** • "Pull this company's income statement, cash flow and balance sheet for the last 8 quarters." • "What did insiders buy or sell, and when?" • "Snapshot prices for these 50 tickers, then the OHLC history for the three that moved." • "What are the current odds on this event across Kalshi and Polymarket?" • "Screen for companies matching these financial criteria." **How to use it** Point any MCP client at https://mcp.aisa.one/finance/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: prices and snapshots, income statements, balance sheets and cash flows, metrics and ratios, earnings and analyst estimates, filings and line-item search, insider trades, macro interest rates, news, a screener; CoinGecko spot prices, market tables, OHLC, per-venue tickers and trending; Kalshi and Polymarket markets and trades; plus EDINET filings for Japan. **Why this rather than the source** Equities, crypto and event markets behind one account, so a cross-asset question is one conversation. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the number here, then ask the same agent what X is saying about the ticker today — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/marketpulse/mcp · /crypto-market-data/mcp · /prediction-market-data/mcp · /stock-pulse/mcp for one slice each.

    CryptocurrencyFinance
    541
  • BullrunA
    org.bull-run

    Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude

    FinanceAI & Machine LearningResearch & Data
    303
  • Light Horse SecuritiesOAuth
    io.lighthorse

    Agentic brokerage access to a US brokerage account: quotes, orders, positions, cash and documents.

    FinancePayments & Billing
    1
  • AIsa Stock PulseAOAuth
    one.aisa

    Your agent needs the two halves of a move at once — what people are posting about a ticker right now, and what the price and the news actually did. **What you can ask for** • "What is X saying about $NVDA today, and what did the stock do?" • "Show the chatter and the price move for these five tickers side by side." • "Which tickers are being talked about most right now?" • "Pull the news and the snapshot behind this spike." **How to use it** Point any MCP client at https://mcp.aisa.one/stock-pulse/mcp and sign in with OAuth — there is no key to create or paste. 4 tools: a combined stock-pulse call that joins X/Twitter chatter to the tickers mentioned, plus advanced tweet search, price snapshots and financial news. **Why this rather than the source** One call instead of four, with the join already done. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Spot the move here, then ask the same agent for the filings or the fundamentals behind it — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.

    FinanceSocial Media
    91

Related MCP Servers

  • Alpha Vantage Stock Analysis

    ranveer0323
    A
    license
    D
    quality
    D
    maintenance
    Allows Claude and other MCP clients to access real-time and historical stock market data from Alpha Vantage API, including intraday and daily stock data with customizable intervals.
    3
    6 npm
    6
    MIT

  • Yahoo Finance MCP Server

    danishashko
    A
    license
    Not graded
    quality
    A
    maintenance
    Provides real-time stock market data for Claude Desktop and MCP-compatible clients, enabling natural language queries for quotes, historical prices, company profiles, financial statements, analyst ratings, comparisons, news, options, holdings, dividends, estimates, symbol search, and market status.
    168 npm
    21
    MIT

  • Finance MCP Server

    akshatbindal
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides comprehensive stock market data and technical analysis tools via the MCP protocol, enabling real-time quotes, historical data, and professional indicators like RSI and MACD for Claude Desktop and other clients.
    5
    Apache 2.0

  • Financial Data MCP Server

    rajithpr
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI models to access real-time financial market data including stock quotes, fundamentals, daily prices, symbol search, and market status via the Alpha Vantage API. Works with any MCP-compatible client like Claude Desktop for natural language interaction.
    -