@qubaomingg/stock-mcp
알파 밴티지 스톡 MCP 서버
Alpha Vantage API에서 주식 시장 데이터를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. Claude를 비롯한 MCP 클라이언트는 이를 통해 실시간 및 과거 주식 데이터에 접근할 수 있습니다.
특징
사용자 정의 가능한 간격으로 일중 주식 데이터를 얻으세요
매일 주식 데이터를 받으세요
가격 변동에 따라 주식 알림 생성
주식 데이터를 리소스로 접근하세요
Related MCP server: Stock Market MCP Server
필수 조건
Node.js 16 이상
Alpha Vantage API 키( Alpha Vantage 에서 무료로 받으세요)
설치
이 저장소를 복제하세요
종속성 설치:
지엑스피1
루트 디렉토리에
.env파일을 만들고 Alpha Vantage API 키를 추가하세요.ALPHA_VANTAGE_API_KEY=your_api_key_here
건물과 운영
TypeScript 코드를 작성합니다.
npm run build서버를 실행합니다:
npm start자동 재로딩을 이용한 개발의 경우:
npm run devAPI 클라이언트 테스트:
npm testClaude와 함께 데스크톱 사용
Claude for Desktop과 함께 이 MCP 서버를 사용하려면:
데스크톱용 Open Claude
설정 > 개발자 > 구성 편집으로 이동하세요.
claude_desktop_config.json에 다음을 추가하세요.
{
"mcpServers": {
"alpha-vantage": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js"],
"env": {
"ALPHA_VANTAGE_API_KEY": "YOUR_API_KEY"
}
}
}
}/absolute/path/to/dist/index.js 빌드된 index.js 파일의 절대 경로로 바꿉니다.
데스크톱용 Claude 재시작
사용 가능한 도구
주식 데이터 가져오기
특정 종목에 대한 일중 주식 데이터를 가져옵니다.
매개변수:
symbol(필수): 주식 기호(예: IBM, AAPL)interval(선택 사항): 데이터 포인트 간 시간 간격(1분, 5분, 15분, 30분, 60분). 기본값: 5분outputsize(선택 사항): 반환할 데이터 양(compact: 최근 100개 데이터 포인트, full: 최대 20년 분의 데이터). 기본값: compact
매일 주식 데이터 가져오기
특정 종목에 대한 일일 주가 데이터를 가져옵니다.
매개변수:
symbol(필수): 주식 기호(예: IBM, AAPL)outputsize(선택 사항): 반환할 데이터 양(compact: 최근 100개 데이터 포인트, full: 최대 20년 분의 데이터). 기본값: compact
주식 알림 받기
가격 변동에 따라 알림을 생성하기 위해 주식 데이터를 분석합니다.
매개변수:
symbol(필수): 주식 기호(예: IBM, AAPL)threshold(선택 사항): 가격 변동 알림에 대한 백분율 임계값입니다. 기본값: 5
사용 가능한 리소스
주식 데이터
주식 데이터를 리소스로 직접 접근하세요.
URI 템플릿: stock://{symbol}/{interval}
매개변수:
symbol: 주식 기호(예: IBM, AAPL)interval: 시간 간격(매일, 1분, 5분, 15분, 30분, 60분). 기본값: 매일
Claude에서의 사용 예:
"stock://AAPL/daily의 주식 데이터를 분석해 주실 수 있나요?"
"이 데이터에 대해 어떻게 생각하십니까: stock://MSFT/5min"
특허
아이에스씨
Available Tools
3 toolsget-daily-stock-dataD
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol (e.g., IBM, AAPL) | |
| outputsize | No | Amount of data to return (compact: latest 100 data points, full: up to 20 years of data) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-stock-alertsD
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol (e.g., IBM, AAPL) | |
| threshold | No | Percentage threshold for price movement alerts (default: 5) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-stock-dataD
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol (e.g., IBM, AAPL) | |
| interval | No | Time interval between data points (default: 5min) | |
| outputsize | No | Amount of data to return (compact: latest 100 data points, full: up to 20 years of data) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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.
3 tool updates
v1.0.0- Changed
get-daily-stock-data2 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false
- Changed
get-stock-alerts2 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false
- Changed
get-stock-data2 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false
3 tool updates
- First observed
get-daily-stock-data - First observed
get-stock-alerts - First observed
get-stock-data
TDQS
Scored across 3 tools
The tools are highly ambiguous and overlapping. 'get-daily-stock-data' and 'get-stock-data' appear to serve nearly identical purposes, with no description to clarify their differences. 'get-stock-alerts' might be distinct but lacks context, making the overall set confusing and prone to misselection.
The naming is perfectly consistent, using a kebab-case pattern with a 'get-' prefix followed by a noun phrase. All three tools follow this exact convention, making them predictable and easy to parse.
With only 3 tools, the set feels thin and under-scoped for a stock data server. It lacks essential operations like search, update, or delete, and the limited coverage suggests it may not support comprehensive agent workflows in this domain.
The tool surface is severely incomplete for a stock data domain. It only provides 'get' operations with no ability to set, modify, or manage data (e.g., no create, update, delete, or search tools). This will cause significant agent failures in handling stock-related tasks.
Maintenance
Related MCP Connectors
MCP server for stocksense-ai documentation, generated by doc2mcp.
Alpha Vantage MCP — Stock market data, fundamentals, and earnings
- FensoryOAuthcom.fensory
Trading MCP server for AI agents, with live market data, account reads and controlled execution.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
Related MCP Servers
- AlicenseBqualityDmaintenanceThis is an MCP server that provides access to the Alpha Vantage API, allowing stock data retrieval to be used as context to LLMs.223 npm9MIT
- FlicenseBqualityDmaintenanceA TypeScript-based MCP server that fetches real-time stock market data and company financial information through the Alpha Vantage API.46-
- MIT
- AlicenseBqualityDmaintenanceThis is an MCP server that provides access to the Alpha Vantage API, allowing stock data retrieval to be used as context to LLMs.223 npmMIT