How do I use Stock Market MCP Server?

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., "@Stock Market MCP Server What's the current price of AAPL?" 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.

Stock Market MCP Server

by sverze

Overview Schema Related Servers Score Discussions

Python

Remote

Stock Market MCP Server

A Machine Conversation Protocol (MCP) server that provides stock market data and analysis tools using the Finnhub API.

Features

Stock symbol lookup
Real-time stock prices
Basic financial metrics
Market and company news
Historical price data (candles)
Pre-built prompts for common analysis tasks

Related MCP server: Stock Research MCP Server

Prerequisites

Python 3.8 or higher
uv - Fast Python package installer and resolver
Finnhub API key (get one for free at finnhub.io)
Claude Desktop (for using the MCP server with Claude)

Setup Instructions

1. Clone the Repository

git clone https://github.com/yourusername/stock-market-mcp-server.git
cd stock-market-mcp-server

2. Set Up Environment with uv

uv is a fast, reliable Python package installer and virtual environment manager. Here's how to set up your environment:

# Install uv if you don't have it already
pip install uv

# Create a virtual environment
uv venv

# Activate the virtual environment
# On macOS/Linux:
source .venv/bin/activate
# On Windows:
# .venv\Scripts\activate

# Install dependencies
uv add -r requirements.txt

3. Configure Environment Variables

Create a .env.local file in the project root with your Finnhub API key:

FINNHUB_API_KEY=your_api_key_here

Replace your_api_key_here with your actual Finnhub API key.

Running the MCP Server

To start the MCP server:

uv run stock-market-server.py

The server runs in stdio mode by default, which means it reads from standard input and writes to standard output.

Using with Claude Desktop

To use this MCP server with Claude Desktop:

Start Claude Desktop
Go to Settings > Developer
Enable "Developer Mode"
Click "Add Tool"
Select "Local MCP Server"
Configure the tool:
- Name: Stock Market
- Command: The full path to your Python executable and the script
  - Example: /Users/username/.venv/bin/python /Users/username/stock-market-mcp-server/stock-market-server.py
- Working Directory: The full path to your project directory
Click "Save"

Now you can use the stock market tools in your conversations with Claude!

Alternatively, you can add the tool to your Claude Desktop tools list manually. You can find the configuration file in the installation directory of Claude Desktop. On a MacBook Pro, it's located at ~/Library/Application\ Support/Claude/claude_desktop_config.json. Add the following JSON to the tools array, note modify the path to suite your environment:

"stock-market": {
   "command": "uv",
   "args": [
     "--directory",
     "<YOUR_PATH_GOES_HERE>/stock-market-mcp-server",
     "run",
     "stock_market_server.py"
   ]
 }

Using with Stock Market Client

To use the MCP server with the Stock Market Client, follow these steps:

You will need an Anthropic API key. You can get one for free at Anthropic.
Update the .env file with your API key. ANTHROPIC_API_KEY=your_api_key_here
Start the MCP Client with the following command: uv run stock_market_client.py

Available Tools

The MCP server provides the following tools:

get_stock_symbol_lookup: Search for stock symbols by company name
get_stock_price: Get the latest price for a stock
get_basic_financials: Get key financial metrics for a company
get_market_news: Get the latest market news by category
get_company_news: Get news for a specific company over a date range
get_stock_candles: Get historical price data for a stock

Available Prompts

The server includes these pre-built prompts:

stock_analysis: Analyze a stock for potential investment
market_overview: Get a comprehensive market overview
stock_price_history: Analyze historical price movements
company_news_analysis: Analyze news and its impact on stock price

Example Usage Prompts

Here are some examples of how to use the tools with Claude:

Looking up a stock symbol: "Can you look up the stock symbol for Apple?"
Getting current stock price: "What's the current price of AAPL?"
Using a prompt: "I'd like to analyze Tesla stock as a potential investment."
Combining multiple tools: "Give me a market overview with the latest news and the current prices for AAPL, MSFT, and TSLA."

Troubleshooting

API Key Issues: Make sure your Finnhub API key is correctly set in the .env.local file
Module Not Found Errors: Ensure you've activated the virtual environment and installed all dependencies
Connection Issues: Check your internet connection and Finnhub API status

License

MIT License

Available Tools

6 tools

get_basic_financialsA

Get basic financial information for a company.

Args:
    symbol: The stock symbol to look up (e.g., AAPL for Apple Inc.)

Returns:
    str: Basic financial metrics in JSON format including P/E ratio, market cap, etc.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses the return format ('str: Basic financial metrics in JSON format') and provides example metrics, which is useful. However, it doesn't mention error behavior, symbol validity requirements, or any other side effects beyond the read-only nature implied by 'get'.

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 and well-structured, with a one-sentence purpose, an Args section, and a Returns section. Every sentence adds information and nothing is redundant.

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 one-parameter tool with no output schema, the description adequately explains the purpose, parameter, and return format. It lists example metrics (P/E, market cap) but could mention edge cases or limitations. Overall, it's complete for the tool's complexity.

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

Parameters5/5

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

The schema provides no description for the symbol parameter, but the description fully compensates with a clear explanation: 'The stock symbol to look up (e.g., AAPL for Apple Inc.)'. This adds meaning and a concrete example, making the parameter's purpose unmistakable.

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 states 'Get basic financial information for a company' with a specific verb and resource. It distinguishes from siblings by mentioning metrics like P/E ratio and market cap, but it doesn't fully articulate the boundary relative to get_stock_price or get_stock_candles.

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 when basic financial metrics are needed, but it doesn't explicitly state when to prefer this over sibling tools or provide exclusions. The example symbol (AAPL) gives a concrete use case, but no alternative guidance is offered.

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

get_company_newsA

Get news for a specific company over a date range.

Args:
    symbol: The stock symbol (e.g., AAPL for Apple Inc.)
    from_date: Start date in YYYY-MM-DD format
    to_date: End date in YYYY-MM-DD format

Returns:
    str: Company-specific news in JSON format with headlines, summaries, and URLs.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`to_date`	Yes
`from_date`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations provided, the description alone must convey behavioral context. It details the return format (JSON string with headlines, summaries, URLs), but does not disclose limitations, error conditions, rate limits, or explicit read-only guarantees. For a simple news retrieval, 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 concise and well-structured. It front-loads the primary purpose, then lists parameters with clear formatting and finally describes the return value. 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?

For a simple tool with 3 string parameters and no output schema, the description covers all essential aspects: purpose, parameter meanings, and return value format. It is complete enough for an agent to select and invoke the tool correctly without additional clues.

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

Parameters5/5

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

The input schema has zero description coverage, but the description fully compensates by explaining each parameter: symbol with an example (AAPL), and from_date/to_date with format guidance (YYYY-MM-DD). This adds significant meaning beyond the bare 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's function: 'Get news for a specific company over a date range.' It uses a specific verb (Get), identifies the resource (company news), and differentiates from sibling tools like get_market_news by emphasizing company-specificity.

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 context is clear: use when you need news for a particular stock symbol over a date range. It implicitly distinguishes from get_market_news, but lacks explicit guidance on when not to use or alternative tool references.

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

get_market_newsA

Get the latest market news.

Args:
    category: News category. Available values: general, forex, crypto, merger.
    min_id: Use this to get only news after this ID.

Returns:
    str: Latest market news in JSON format with headlines, summaries, and URLs.

ParametersJSON Schema

Name	Required	Description	Default
`min_id`	No
`category`	No		general

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the return format (JSON with headlines, summaries, URLs) and the min_id pagination behavior, but does not mention ordering, result limits, or any side effects. The 'Get' verb implies read-only, but this is not explicitly stated.

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 extremely concise, with a one-line purpose followed by structured Args and Returns sections. Every sentence adds value, and there is no redundant or filler content.

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 read-only tool with two optional parameters, the description covers purpose, parameters, and return format sufficiently. Minor gaps include no mention of news time window, result limits, or ordering, but these are not critical for basic usage.

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

Parameters5/5

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

Schema description coverage is 0%, so the description fully compensates. It explains the category parameter with allowed values and the min_id parameter for retrieving news after a specific ID, giving clear meaning beyond the raw 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 'Get the latest market news' with a specific verb and resource. The listed categories (general, forex, crypto, merger) distinguish it from stock-specific siblings like get_company_news and get_stock_price.

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 when-to-use or when-not-to-use guidance is provided. It does not mention that company-specific news should use get_company_news or that stock quotes should use get_stock_price. Usage is only implied by the tool's name and categories.

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

get_stock_candlesA

Get historical price data (candles) for a stock.
Note: This is a premium feature, your API key may not have access to this feature.

Args:
    symbol: The stock symbol (e.g., AAPL for Apple Inc.)
    resolution: Time interval between data points. Supported values: 1, 5, 15, 30, 60, D, W, M (minutes, day, week, month)
    from_time: Start time in YYYY-MM-DD format or Unix timestamp
    to_time: End time in YYYY-MM-DD format or Unix timestamp

Returns:
    str: Historical price data in JSON format with open, high, low, close values.

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`to_time`	No
`from_time`	No
`resolution`	No	D

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the premium feature access risk and describes the return format as JSON with open, high, low, close values. This adds meaningful behavioral context beyond schema, though it does not cover error scenarios or rate limits.

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-structured and front-loaded with the purpose, then organized into Args and Returns sections. It is slightly verbose but every line provides needed information, such as the premium warning and parameter details.

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 complexity (4 parameters, no output schema, no annotations), the description is fairly complete: it covers purpose, all parameters, return format, and a caveat. It lacks explicit sibling differentiation and default behavior explanation, but defaults are present in the schema.

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

Parameters5/5

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

Schema description coverage is 0%, so the description fully compensates by explaining all four parameters, including example symbols, supported resolution values, and time formats. This adds significant meaning beyond the bare 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's function with a specific verb and resource: 'Get historical price data (candles) for a stock.' The term 'historical' and 'candles' distinguish it from sibling get_stock_price, which likely provides current price data.

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

Usage Guidelines3/5

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

Usage is implied through the description of historical data, but there is no explicit guidance on when to use this tool versus alternatives like get_stock_price. The premium feature note provides a constraint but does not offer a clear 'when not to use' or point to alternatives.

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

get_stock_priceA

Get the latest stock price and related information for a given symbol.

Args:
    symbol: The stock symbol to look up (e.g., AAPL for Apple Inc.)

Returns:
    str: Current price information in JSON format

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

A4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format (JSON string) but does not disclose potential errors, read-only nature, rate limits, 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 concise, uses clear sections (Args, Returns), and every sentence contributes meaning without filler.

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, no output schema, no annotations), the description covers the essential aspects: purpose, parameter, and return format. However, it lacks error handling or validity notes, leaving a minor 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 description's Args section explains the symbol parameter with an example (e.g., AAPL for Apple Inc.), adding meaning beyond the schema's bare string type and field title.

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 the verb 'Get' and identifies the resource 'latest stock price and related information for a given symbol', clearly distinguishing it from sibling tools like get_stock_symbol_lookup and get_stock_candles.

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 establishes a clear context for retrieving current price, but does not explicitly mention alternatives or when not to use this tool. Sibling names imply distinct use cases, but the description could have been more explicit.

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

get_stock_symbol_lookupA

Stock Symbol Lookup - searches for best-matching symbols based on your query.

Args:
    query: You can input anything from symbol, security's name to ISIN and CUSIP e.g. apple

Returns:
    str: A list of matching symbols with formatted information

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

A4.3/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 discloses that the tool searches and returns a list of formatted strings, but omits details on matching behavior (e.g., fuzzy vs exact), potential empty results, error conditions, or any read-only assumption. This is minimal but not misleading, hence a mid-range score.

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 and well-structured: a one-sentence summary, followed by Args and Returns sections. Every element adds value, with no redundant or vague text. It is front-loaded with the purpose and easy to parse.

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 lookup tool with one parameter and no output schema, the description provides essential information: purpose, parameter semantics, and return type. It lacks details on output format specifics or edge cases, but given the low complexity, this is reasonably complete. A score of 4 reflects the slight uncertainty about what 'formatted information' precisely entails.

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

Parameters5/5

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

The schema only specifies 'query' as a required string, but the description adds substantial meaning: it explains what inputs are acceptable (symbol, name, ISIN, CUSIP) and gives a concrete example ('apple'). With schema description coverage at 0%, this description fully compensates and enhances usability.

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 a specific action ('searches for best-matching symbols') on a specific resource (stock symbols), distinguishing it from sibling tools that deal with prices, financials, and news. The inclusion of example query types ('symbol, security's name to ISIN and CUSIP') reinforces the scope.

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 when to use this tool: whenever you have a partial symbol, name, or identifier and need to find the canonical symbol. It provides clear context by listing acceptable inputs, but does not explicitly mention alternatives or when not to use it. Since sibling tools all operate on known symbols, this is adequate context without excluding other tools.

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.2/5.0

Disambiguation5/5

Each tool targets a distinct resource: symbol lookup, latest price, financials, market news, company news, and historical candles. The overlap between market news and company news is clear from their descriptions, so no confusion.

Naming Consistency5/5

All tool names follow the get_ noun pattern in snake_case, e.g., get_stock_price, get_market_news. This is perfectly consistent and predictable.

Tool Count5/5

With 6 tools, the server is well-scoped for stock market data retrieval. Each tool covers a core function without unnecessary bloat.

Completeness4/5

The server covers symbol lookup, real-time price, fundamentals, news, and historical data, which covers most basic stock market needs. A minor gap is the lack of batch quotes or sector/ETF data, but these are not essential for the stated purpose.

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

Finnhub A
io.github.pipeworx-io
Finnhub MCP — wraps Finnhub Stock API (finnhub.io)
Finance Research & Data
352
aicastle-school-openai-api-agent-projectOAuth
ai.smithery
Fetch current stock prices and key data for symbols across global markets. Look up companies like…
Finance Search
211
hollaugo-financial-research-mcp-server
ai.smithery
Analyze stocks with summaries, price targets, and analyst recommendations. Track SEC filings, divi…
Finance Search Research & Data
213
zwldarren-akshare-one-mcp BOAuth
ai.smithery
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
Finance Search Open Data
3225

Related MCP Servers

MCP Finnhub Server
Finance Search
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.
Updated a month ago (2026-07-22 03:24 UTC)
1
MIT
Stock Research MCP Server
Finance Search Research & Data
Sauravmehto
F
license
Not graded
quality
C
maintenance
Provides comprehensive stock intelligence and technical analysis by integrating Alpha Vantage and Finnhub data. It enables users to generate detailed research reports and retrieve real-time market metrics, indicators, and news sentiment.
Updated 7 months ago (2026-02-12 14:14 UTC)
Stock Assistant MCP Server
Finance Research & Data
shwetha-sundar
F
license
Not graded
quality
D
maintenance
Provides real-time stock data, historical analysis, and stock comparisons using the Yahoo Finance API.
Updated a year ago (2025-05-05 01:40 UTC)
mcp-finance
Finance Research & Data
nimitmk7
A
license
A
quality
D
maintenance
Provides financial data tools like stock price, company info, historical data, news, and market indices using yfinance and MarketAux API.
Updated a year ago (2025-04-15 21:37 UTC)
5
4
MIT

Appeared in Searches

A server for finding information about StockFlow

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/sverze/stock-market-mcp-server'

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