A
licenseB
qualityD
maintenanceThis is an MCP server that provides access to the Alpha Vantage API, allowing stock data retrieval to be used as context to LLMs.
2
29
9
MIT
Stock Market MCP Server
by MCP-100
Powers the stock market MCP server, enabling API interactions with Alpha Vantage to fetch real-time stock prices, market reports, and company financial data.
Used as the core programming language for implementing the stock market MCP server's functionality for retrieving financial information from Alpha Vantage API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Stock Market MCP Serverget the current price for 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
一个基于 TypeScript 的 MCP 服务器，用于获取股票市场数据。该服务器通过 Alpha Vantage API 提供实时股票市场信息和公司财务数据。
生成该 MCPServer 的关键信息
1.Plan mode
help me build a stock market mcp server that uses the AlphaVantage public API
I want it to have these tools：
- generate US market report/briefing
- generate financial statement for company
- get ticker price for company
- any other basic tools you think would be helpful
- api key: <you api key>
2. please test all the tools to confirm their functionalityRelated MCP server: @qubaomingg/stock-mcp
功能特点
工具
get_ticker_price- 获取股票实时价格需要提供股票代码作为参数
返回最新的股票价格和时间戳
get_market_report- 获取美国市场报告提供市场整体状况概览
get_financial_statement- 获取公司财务报表支持三种报表类型：收入报表(income)、资产负债表(balance)、现金流量表(cashflow)
需要提供股票代码和报表类型
get_company_overview- 获取公司概览信息需要提供股票代码
返回公司关键指标和基本信息
开发环境配置
安装依赖
npm install构建项目
npm run build开发模式（自动重新构建）
npm run watch安装说明
要在 Claude Desktop 中使用此服务器，需要添加服务器配置：
MacOS
配置文件路径：~/Library/Application Support/Claude/claude_desktop_config.json
Windows
配置文件路径：%APPDATA%/Claude/claude_desktop_config.json
配置示例：
{
"mcpServers": {
"stock-market-server": {
"command": "/path/to/stock-market-server/build/index.js"
}
}
}调试
由于 MCP 服务器通过标准输入输出(stdio)通信，调试可能比较困难。推荐使用 MCP Inspector 工具进行调试：
npm run inspector运行后，Inspector 将提供一个浏览器访问地址，可以通过浏览器使用调试工具。
技术栈
TypeScript
Node.js
Alpha Vantage API
MCP SDK (@modelcontextprotocol/sdk)
注意事项
使用前需要确保有有效的 Alpha Vantage API 密钥
所有 API 响应都以 JSON 格式返回
请注意 Alpha Vantage API 的调用频率限制
许可证
[添加许可证信息]
Available Tools
4 toolsget_company_overviewC
Get company overview and key metrics
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
TDQS
C2.9/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 only states what the tool does ('Get company overview and key metrics') without mentioning any behavioral traits such as read-only status, potential rate limits, authentication needs, or what the output might look like. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'company overview and key metrics' includes, how the data is returned, or any behavioral aspects like error handling. For a tool with no structured data beyond the input schema, this leaves significant gaps in understanding.
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 has 100% description coverage, with the 'symbol' parameter clearly documented as 'Stock ticker symbol'. The description does not add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 the tool's purpose with a specific verb ('Get') and resource ('company overview and key metrics'), making it easy to understand what it does. However, it doesn't distinguish itself from sibling tools like 'get_financial_statement' or 'get_market_report', which might also provide company-related data, so it doesn't reach the highest score.
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 like the sibling tools. It lacks explicit instructions on context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_financial_statementC
Get financial statements for a company
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol | |
| statement | Yes | Type of financial statement |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Get financial statements' but doesn't add any context about what this entails—e.g., whether it's a read-only operation, if it requires authentication, rate limits, or what the output format might be. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse and understand quickly.
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 complexity of financial data retrieval, the description is incomplete. With no annotations and no output schema, it fails to provide necessary context like response format, data scope, or error handling. This leaves gaps that could hinder an AI agent in using the tool effectively.
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%, meaning the input schema already fully documents the parameters (symbol and statement with enum). The description doesn't add any extra meaning or details beyond what the schema provides, such as examples or usage notes, so it meets the baseline score of 3.
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 the tool's purpose with a specific verb ('Get') and resource ('financial statements for a company'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_company_overview' or 'get_market_report', which might also provide financial data, so it doesn't reach the highest score.
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 like the sibling tools. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_reportB
Generate US market report/briefing
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'generates' a report, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns structured or unstructured data, or any other behavioral traits. The description is too minimal for a tool with no annotation support.
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, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized for a zero-parameter tool and front-loads the essential information.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the generated report contains, its format, or any behavioral context. For a tool that 'generates' something, more detail is needed to help the agent understand what to expect.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for this scenario is 4, as the description appropriately doesn't waste space on non-existent parameters.
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 the tool's purpose with a specific verb ('Generate') and resource ('US market report/briefing'), making it immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_company_overview' or 'get_financial_statement', but the scope ('US market') provides some implicit distinction.
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 like 'get_company_overview' or 'get_financial_statement'. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ticker_priceB
Get current price for a stock ticker
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool gets current price, implying a read-only operation, but doesn't disclose any behavioral traits such as data source, refresh rates, error handling, or authentication needs. For a financial data tool with zero annotation coverage, this is a significant gap in transparency.
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, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get current price for a stock ticker'), making it efficient and easy to parse. Every part of the sentence contributes directly to understanding the tool's function.
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 low complexity (single parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose but lacks details on behavioral aspects like data freshness or error cases. Without annotations or output schema, the description should ideally provide more context, but it's adequate for a simple lookup 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?
The input schema has 100% description coverage, with the single parameter 'symbol' documented as 'Stock ticker symbol'. The description doesn't add any meaning beyond this, such as examples (e.g., 'AAPL' for Apple) or constraints (e.g., format requirements). With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 the tool's purpose with a specific verb ('Get') and resource ('current price for a stock ticker'). It distinguishes the tool from siblings like 'get_company_overview' or 'get_financial_statement' by focusing on price data rather than broader company information. However, it doesn't explicitly mention that it's for real-time or current data versus historical, which could slightly limit differentiation.
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 doesn't mention scenarios where price data is needed over other financial information, nor does it reference sibling tools like 'get_market_report' for broader market context. This leaves the agent without explicit usage 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.
4 tool updates
- First observed
get_company_overview - First observed
get_financial_statement - First observed
get_market_report - First observed
get_ticker_price
TDQS
B3.4/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: company overview, financial statements, market report, and stock price. There is no overlap in functionality, making it easy for an agent to select the right tool for each specific need without confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' prefix, using snake_case uniformly. This predictability enhances readability and usability across the tool set.
Tool Count4/5
With 4 tools, the server is well-scoped for basic stock market data retrieval, though it might benefit from additional tools like historical price data or news feeds. The count is reasonable and each tool earns its place in the domain.
Completeness3/5
The tools cover key retrieval operations for company and market data, but there are notable gaps such as lack of update, delete, or analysis tools (e.g., technical indicators, portfolio management). This limits the server to read-only use cases.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Alpha Vantage MCP — Stock market data, fundamentals, and earnings
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
MCP server for stocksense-ai documentation, generated by doc2mcp.
Multi-tenant FastMCP server for Charles Schwab brokerage data, monetized via DPYC Tollbooth
Related MCP Servers
- FlicenseDqualityDmaintenance一个 Alpha Vantage API 查询 股票信息的 MCP server.34-
- AlicenseAqualityDmaintenanceAn MCP server that provides real-time financial data integration with Alpha Vantage's API, enabling access to stock market data, cryptocurrency prices, forex rates, and technical indicators.754MIT
- AlicenseDqualityAmaintenanceA TypeScript-based MCP server that enables users to query financial news, stock data, and index information while managing text notes with creation and summarization capabilities.5408663MIT