Stock MCP Server
📈 股票 MCP 服务器
这是一个提供韩国/美国股票技术分析和基于策略筛选的 Model Context Protocol (MCP) 服务器。 您可以在 Claude Desktop、Claude Code 等兼容 MCP 的客户端中,通过自然语言进行图表分析和股票筛选。
✨ 功能特点
🇰🇷 韩国股票分析 — 基于
pykrx的 KOSPI/KOSDAQ 全品种 OHLCV + 技术指标🇺🇸 美国股票分析 — 基于
yfinance的 NYSE/NASDAQ 品种 + 市值/PER/52周高低价🔍 股票搜索 — 通过股票名称查找股票代码(韩国股票)
📊 10种动量策略 + 7种突破策略 — 从金叉到 VCP
🎯 两种筛选哲学 — 🐎 追逐奔跑的马 vs 🌱 寻找即将奔跑的马
🔎 多级预筛选 — 成交量激增、趋势模板 (Trend Template)、RS、52周区间等
Related MCP server: KIS MCP Server
🛠️ 工具
工具 | 说明 | 输入示例 |
| 韩国股票技术分析 |
|
| 美国股票技术分析 |
|
| 股票名称 → 股票代码搜索 |
|
| 🐎 韩国 追逐奔跑的马 (第二阶段趋势) |
|
| 🐎 美国 追逐奔跑的马 |
|
| 🌱 韩国 寻找即将奔跑的马 (VCP·吸筹·第一阶段末期) |
|
| 🌱 美国 寻找即将奔跑的马 |
|
| 特定股票策略诊断 |
|
🎯 筛选:两种哲学
🐎 动量 (Momentum) — 追逐奔跑的马
捕捉已进入上升趋势的股票的 趋势持续 (Stage 2 continuation)。 基于 O'Neil 的 CANSLIM 和 Minervini 的趋势模板理论。
流水线
시드 (네이버 거래량/상승률/급등 | Yahoo most_actives/day_gainers/small_cap_gainers)
↓
① min_trade_value — 유동성
② 당일 과열 제외 +10% 이상 — 추격매수 방지
③ 20일 내 거래량 급증 ≥ 3x — 자금 유입 시그널
④ Minervini Trend Template — Stage 2 6조건 (ON)
⑤ 52주 고점 근접 — OFF (Trend Template과 중복)
⑥ RS vs 지수 — OFF (opt-in, 강한 종목만 보고 싶을 때)
↓
10가지 Momentum 전략 적용应用策略 (10)
现有 4:金叉+成交量、回调买入、动量突破、成交量爆发
新增 6:RSI 背离、MACD 背离、随机指标 (Stochastic)、布林带挤压 (BB Squeeze)、一目均衡表突破、3线多头排列
🌱 突破 (Breakout) — 寻找即将奔跑的马
捕捉尚未大幅波动、处于 吸筹阶段 / 突破前夕 的股票。 基于 Mark Minervini 的 VCP 形态和 Wyckoff 吸筹理论。
流水线
시드 (Momentum과 동일 — 매집도 거래량에 반영됨)
↓
① min_trade_value
② 당일 과열 제외 +10% 이상
③ 누적 상승 한도: 최근 30일 +30% 이상 제외 ← Breakout 전용
④ 52주 밴드: 고점 × 0.85 이하 AND 저점 × 1.20 이상 ← 전용 (중간권만)
⑤ 20일 내 거래량 급증 ≥ 2x (momentum의 3x보다 완화)
↓
Breakout 7전략 적용 (Trend Template / 52w 근접 / RS 모두 off)应用策略 (7)
复用 4:回调买入、成交量爆发、MACD 背离、布林带挤压
新增 3:VCP 波动率收缩、静默吸筹、第一阶段末期转换
🧪 两种模式对比
🐎 动量 (Momentum) | 🌱 突破 (Breakout) | |
哲学 | 趋势持续 | 吸筹 → 突破初期 |
累计涨幅 | 无限制 | 排除 30 日内涨幅超过 +30% 的股票 |
52周位置 | 建议接近高点 | 52周高点 85% 以下 + 低点 120% 以上区间 |
趋势模板 | 开启 (要求均线多头排列) | 关闭 |
成交量激增 | 3.0x | 2.0x (吸筹阶段波动较小) |
策略数量 | 10 个 | 7 个 (含新增 3 个) |
适用时机 | 市场强势期、趋势跟踪 | 调整后重新入场、底部反转 |
实战结果对比示例
以同一市场 (KOSPI) 为准:
动量: 퍼스텍 (满足 6 个策略) — 已经在奔跑的股票
突破: 대원전선 30日 -20.32%,在 52 周高点 72% 位置出现回调+VCP — 典型的吸筹形态
📊 新增突破策略说明
VCP (波动率收缩形态)
将最近 15 天分为 3 个 5 天区间,判断各区间的高低价差 (%) 是否 依次收缩。 线圈弹簧形态 → 突破在即。(Mark Minervini)
静默吸筹 (Silent Accumulation)
最近 20 天成交量均值较前 20 天 增加 且存在激增日, 但同期的 20 天价格波动幅度在 ±8% 以内 → 市场未察觉的主力吸筹。
第一阶段末期转换
从底部箱体 (Stage 1) 向平缓上升 (Stage 2 初期) 过渡的区间。
MA60 斜率较 1 个月前上升
MA20 > MA60 (短期向上转换)
收盘价 > MA60 (获得支撑)
布林带宽度 ≤ 20 日均值 (波动率尚未扩张)
🔎 预筛选参数速查表
动量筛选器通用
参数 | 默认 | 用途 |
| 10.0 | 排除今日涨幅超过 +10% 的股票。若为 |
| 3.0 | 成交量激增倍数 |
| True | Minervini 趋势模板 |
| False | RS 过滤器 (仅在想看强势股时开启) |
| 0.0 | 超额收益 (pp) 阈值 |
突破筛选器通用
参数 | 默认 | 用途 |
| 30.0 | 最近 N 日累计涨幅上限 (%) |
| 30 | 累计计算区间 |
| 0.85 | 仅通过 52 周高点 × 该值以下的股票 |
| 1.20 | 仅通过 52 周低点 × 该值以上的股票 |
| 2.0 | 成交量激增 (吸筹阶段倍数较低) |
📦 安装
前置条件
Python 3.13+
uv (推荐)
设置
git clone https://github.com/Juuuuuuni/stock-mcp-server.git
cd stock-mcp-server
uv sync🚀 使用方法
Claude Desktop 联动
在 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
或 %APPDATA%\Claude\claude_desktop_config.json (Windows) 中添加以下内容:
{
"mcpServers": {
"stock-analyzer": {
"command": "uv",
"args": [
"--directory",
"/절대/경로/stock-mcp-server",
"run",
"python",
"server.py"
]
}
}
}直接运行
uv run python server.py💬 对话示例
个股分析
👤 삼성전자 최근 분석해줘
🤖 [get_stock_analysis("005930")] → 현재가 / RSI / MACD / 추세 해석
👤 NVDA 한 달 차트 분석
🤖 [get_us_stock_analysis("NVDA", days=30)]
👤 알체라 종목코드가 뭐야?
🤖 [search_stock("알체라")] → 347860筛选 (奔跑的马)
👤 지금 코스피에서 뜨는 종목 찾아줘
🤖 [screen_kr_momentum(market="KOSPI")]
→ Stage 2 추세 + 거래량 급증 종목. 퍼스텍(6전략), 대우건설(3전략) …
👤 미국 주식에서 강세 종목만 (RS 10pp 이상)
🤖 [screen_us_momentum(enable_rs_filter=True, min_rs_outperformance=10.0)]筛选 (即将奔跑的马)
👤 코스닥에서 매집 단계 종목 스크리닝
🤖 [screen_kr_breakout(market="KOSDAQ")]
→ 누적 상승 30% 미만 + 52주 중간권 + VCP/매집 패턴
👤 아직 안 오른 바닥 종목만 (최근 30일 +10% 이내)
🤖 [screen_kr_breakout(max_cumulative_return_pct=10.0)]个股策略诊断
👤 알체라 지금 어떤 단계야?
🤖 [diagnose_stock(ticker="347860", market="KR")]
→ 10전략 중 어느 조건 통과했는지 상세 진단📋 输出示例
动量筛选结果 (摘要)
{
"스크리닝일": "20260413",
"대상시장": "KOSPI",
"시드후보수": 80,
"필터링_단계별_통과": {
"당일과열제외": 64,
"거래량급증": 31,
"Trend_Template": 8,
"52주고점근접": 0,
"RS": 0
},
"필터링결과수": 26,
"결과": [
{
"종목코드": "010820",
"종목명": "퍼스텍",
"전략": "모멘텀 돌파",
"점수": "5/5",
"현재가": 2340,
"등락률": "+4.23%",
"RSI": 68.4,
"거래량비": "2.1x",
"20일내_최대거래량배율": "8.7x",
"복수전략": true
}
]
}突破筛选结果 (摘要)
{
"스크리닝일": "20260413",
"모드": "Breakout (곧 달릴 말)",
"대상시장": "KOSPI",
"시드후보수": 80,
"필터링_단계별_통과": {
"당일과열제외": 64,
"누적상승한도": 55,
"52주밴드": 22,
"거래량급증": 12
},
"필터링결과수": 28,
"결과": [
{
"종목코드": "006340",
"종목명": "대원전선",
"전략": "눌림목 매수",
"점수": "5/5",
"현재가": 1245,
"30일누적": "-20.32%",
"52주고점대비": "72.2%",
"52주저점대비": "128.4%",
"복수전략": true
}
]
}🧩 技术栈
FastMCP — MCP 服务器框架
pykrx — 韩国交易所数据
yfinance — Yahoo Finance 数据
ta — 技术分析指标
BeautifulSoup + lxml — Naver 金融 / Yahoo 筛选器 HTML 解析
pandas — 数据处理
📚 参考资料
William J. O'Neil — How to Make Money in Stocks (CANSLIM)
Mark Minervini — Trade Like a Stock Market Wizard (Trend Template, VCP)
Richard Wyckoff — 价格-成交量吸筹/派发理论
Stan Weinstein — Secrets for Profiting in Bull and Bear Markets (Stage Analysis)
📄 许可证
MIT
Available Tools
8 toolsdiagnose_stockA
특정 종목이 10가지 단기 전략 중 어떤 조건에 해당하는지 상세 진단합니다.
■ 기존 전략: 골든크로스+거래량, 눌림목 매수, 모멘텀 돌파, 거래량 폭발 ■ 신규 전략: RSI 다이버전스, MACD 다이버전스, 스토캐스틱 과매수/과매도, BB 스퀴즈, 일목균형표 구름대 돌파, 3선 정배열/역배열
Args: ticker: 종목코드 (한국) 또는 티커심볼 (미국). 예: '005930', 'AAPL' market: 'KR' 또는 'US'. 기본 'KR'
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| market | No | KR |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the diagnosis purpose without disclosing behavioral traits like read-only nature, rate limits, or side effects. The agent cannot infer safety or performance characteristics.
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?
The description is well-structured with a clear purpose statement, enumerated strategy lists, and parameter documentation. It is front-loaded and avoids redundancy, though it could be slightly shorter by consolidating the list format.
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?
Given the presence of an output schema to describe return values, the description adequately covers the tool's logic (10 strategies) and input parameters. No critical gaps are apparent for a diagnostic tool with simple inputs.
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?
With 0% schema description coverage, the description compensates by providing clear examples and defaults for both parameters (ticker and market), adding practical meaning beyond the schema's type-only definitions.
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?
The description clearly identifies the tool as diagnosing a stock against 10 specific short-term strategies, with a detailed list of those strategies. This distinguishes it from sibling tools like screen_kr_breakout or get_stock_analysis, which focus on screening or broader analysis.
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?
The description implies usage when checking strategy conditions for a specific stock, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Guidance is present only through context and inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_analysisA
종목코드를 입력하면 OHLCV + 기술적 지표를 분석합니다.
Args: ticker: 종목코드 (예: '347860' for 알체라, '005930' for 삼성전자) days: 조회 기간 (일수, 기본 120일)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behaviors. It states the tool analyzes OHLCV + technical indicators but does not disclose specific indicators, error handling, or data source. Output schema exists, reducing need for return details, but some traits remain opaque.
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?
The description is extremely concise: two sentences plus a compact Args list. Every sentence serves a purpose, with no fluff. The main action is front-loaded.
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?
Given the presence of an output schema (which covers return structure), the description sufficiently explains input parameters and core functionality. It could mention error handling or data freshness, but overall it is complete for a straightforward analysis tool.
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?
Schema description coverage is 0%, and the description compensates with clear explanations: ticker with examples (e.g., '347860' for Alchera) and days with default value (120). This adds meaning beyond the schema's basic type/title.
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?
The description clearly states it analyzes OHLCV and technical indicators for a given stock code. It provides specific ticker examples for Korean stocks, distinguishing it from sibling tools like get_us_stock_analysis for US stocks.
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?
The description implies usage for Korean stocks via examples (e.g., '005930' for Samsung) and sibling names suggest alternatives, but it does not explicitly state when to use this tool versus others or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_us_stock_analysisC
미국 주식 종목을 분석합니다.
Args: symbol: 티커 심볼 (예: 'AAPL', 'TSLA', 'NVDA', 'GOOGL') days: 조회 기간 (일수, 기본 120일)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 only states 'analyzes' without clarifying whether it is read-only, what side effects exist, or any behavioral traits beyond basic analysis. It does not describe the nature of the analysis or error conditions.
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?
The description is very concise with two sentences plus a parameter list. Every piece of information is essential, and it is front-loaded with the main purpose.
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?
Despite having an output schema, the description does not explain what the tool returns or how to interpret results. It also fails to mention any usage context relative to siblings, making it incomplete for a tool with multiple similar alternatives.
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?
Schema description coverage is 0%, but the description adds value by providing examples for 'symbol' (e.g., 'AAPL') and clarifying 'days' as the inquiry period in days with default 120. This is adequate but not extensive; no constraints or allowed values are given.
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?
The description clearly states it analyzes US stock tickers, using the verb 'analyzes' and specifying 'US stock'. This distinguishes it from the sibling 'get_stock_analysis' which likely covers other markets, though 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_stock_analysis' or 'screen_us_momentum'. No when-not scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_kr_breakoutA
한국 주식에서 '곧 달릴 말' — 매집/돌파 직전 단계 종목을 필터링합니다.
screen_kr_momentum과 반대 컨셉. 이미 크게 오른 종목을 배제하고
중간권에서 매집 중인 종목 / 변동성 수축 국면 / Stage 1 말기 종목을 찾습니다.
[시드] 네이버 거래량상위 + 상승률상위 + 급등 합집합
[사전필터] 순차 적용:
· 거래대금
· 당일 과열 제외 (exclude_if_up_pct)
· 최근 N일 누적 상승률 < max_cumulative_return_pct (아직 안 달림)
· 52주 밴드 (고점 × high_ceiling 이하 AND 저점 × low_floor 이상)
· 거래량 급증 (기본 2x — momentum의 3x보다 약해도 매집 시그널로 인정)
[전략] Breakout 전용 7개
재사용: 눌림목 매수 · 거래량 폭발 · MACD 다이버전스 · BB 스퀴즈
신규: VCP 변동성 수축 · 조용한 매집 · Stage 1 말기 전환
Args: market: 'KOSPI' | 'KOSDAQ' | 'ALL' top_n: 시드 후보 상한 min_trade_value: 최소 거래대금(원) exclude_if_up_pct: 오늘 이 % 이상 오른 종목 제외 (None 미적용) max_cumulative_return_pct: 최근 N일 누적 상승률 상한(%) (기본 30) cumulative_return_days: 누적 상승률 계산 기간 (기본 30) high_ceiling: 52주 고점 대비 상한 비율 (0.85 = 고점의 85% 이하) low_floor: 52주 저점 대비 하한 비율 (1.20 = 저점의 120% 이상) lookback_days: 거래량 급증 룩백 spike_threshold: 거래량 급증 배율 (기본 2.0) baseline_days: 비교 기준 기간
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | ALL | |
| top_n | No | ||
| min_trade_value | No | ||
| exclude_if_up_pct | No | ||
| max_cumulative_return_pct | No | ||
| cumulative_return_days | No | ||
| high_ceiling | No | ||
| low_floor | No | ||
| lookback_days | No | ||
| spike_threshold | No | ||
| baseline_days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It details the filtering pipeline and logic extensively, but does not explicitly state that the tool is read-only, nor mention any rate limits or side effects. Adequate but not fully covering runtime behavior.
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?
The description is quite long due to detailed logic and parameter explanations. It is well-structured with sections (seed, pre-filters, strategy) and bullet points, but could be slightly more concise. Still, every sentence earns its place given the tool's complexity.
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?
Given 11 optional parameters, no annotations, and presence of output schema, the description is comprehensive. It covers input purpose, filtering steps, strategy types, and sibling differentiation. The output schema is present so return values need not be described.
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?
Schema description coverage is 0%, so the description compensates fully. Every parameter, including market, top_n, thresholds, and periods, is explained with typical values and purpose in the 'Args' section, adding significant meaning beyond the bare schema.
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?
The description clearly states it filters Korean stocks in the 'breakout-ready' phase, contrasting with screen_kr_momentum. It details the seed sources, pre-filters, and strategies, making the purpose specific and distinct from siblings.
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?
Explicitly contrasts with screen_kr_momentum ('반대 컨셉'), explicitly excludes already-strong stocks, and lists dedicated breakout strategies. Provides clear context for when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_kr_momentumA
한국 주식에서 '최근 N일 내 거래량 급증 + 추세 정합' 종목을 필터링합니다.
[시드] 네이버 거래량상위 + 상승률상위 + 급등 합집합
[사전필터] 순차 적용:
· 거래대금: min_trade_value 이상
· 당일 과열 제외: 오늘 등락률이 exclude_if_up_pct 이상이면 제외 (추격 매수 방지)
· 거래량 급증: max(최근 lookback일) / 이전 baseline일 평균 ≥ spike_threshold
· Minervini Trend Template (옵션): Stage 2 상승추세 6조건
· 52주 고점 근접 (옵션): 현재가 ≥ 52주고점 × high_proximity
· RS vs KODEX 200 (옵션): 3개월 초과수익률 ≥ min_rs_outperformance (pp)
[전략] 10가지 기술적 전략 적용
Args: market: 'KOSPI' | 'KOSDAQ' | 'ALL' top_n: 시드 후보 상한 min_trade_value: 최소 거래대금 필터(원) exclude_if_up_pct: 오늘 등락률이 이 값(%) 이상이면 제외. None이면 미적용 (기본 10.0) lookback_days: 거래량 급증 룩백 (기본 20) spike_threshold: 급증 배율 (기본 3.0) baseline_days: 비교 기준 기간 (기본 40) enable_trend_template: Minervini Trend Template 사용 여부 enable_near_52w_high: 52주 고점 근접 필터 사용 여부 high_proximity: 52주 고점 대비 허용 비율 (0.75 = 고점의 75% 이상) enable_rs_filter: KODEX 200 대비 RS 필터 사용 여부 rs_period_days: RS 수익률 계산 기간 (기본 63 ≈ 3개월) min_rs_outperformance: 벤치마크 초과수익 하한 (pp)
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | ALL | |
| top_n | No | ||
| min_trade_value | No | ||
| exclude_if_up_pct | No | ||
| lookback_days | No | ||
| spike_threshold | No | ||
| baseline_days | No | ||
| enable_trend_template | No | ||
| enable_near_52w_high | No | ||
| high_proximity | No | ||
| enable_rs_filter | No | ||
| rs_period_days | No | ||
| min_rs_outperformance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 specifies filtering logic and optional filters, but does not explicitly state side effects (e.g., read-only, no modifications), rate limits, or error conditions. The phrase '추격 매수 방지' hints at safety but is not fully transparent. The output schema exists, so return value details are covered, but behavior beyond filtering is unclear.
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?
The description is detailed but well-structured with section headers ([시드], [사전필터], etc.) and a bulleted list for parameters. It is slightly lengthy but every section contributes to understanding. The front-loading could be improved by placing the main purpose more prominently, but overall it is organized and efficient.
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?
Given the complexity (13 parameters, multi-step filtering) and presence of an output schema, the description provides strong context. It explains the algorithm flow and option details. However, it mentions '10가지 기술적 전략' without elaboration, leaving a gap. No mention of error handling or performance considerations. Still, it is largely complete for an experienced agent.
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?
The input schema has 13 parameters with 0% description coverage, so the description fully compensates. It provides Korean explanations for each parameter, including allowed values for 'market', defaults, and purpose (e.g., 'top_n: 시드 후보 상한'). This adds significant meaning beyond the bare schema properties, making parameter semantics very clear.
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?
The description clearly states the tool filters Korean stocks for volume surge and trend alignment over recent N days. It uses specific verbs and resource description ('필터링합니다') and is distinct from siblings like 'screen_kr_breakout' which focuses on breakouts. The purpose is unambiguous and specific.
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?
The description details a step-by-step filtering pipeline with seed, pre-filters, and optional filters, providing clear context on how the tool operates. However, it does not explicitly compare with sibling tools (e.g., when to use this over screen_kr_breakout or screen_us_momentum) or state when not to use it. The sequential logic is well explained, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_us_breakoutA
미국 주식에서 '곧 달릴 말' — 매집/돌파 직전 단계 종목을 필터링합니다.
screen_us_momentum과 반대 컨셉. 이미 크게 오른 종목을 배제하고
중간권에서 매집 중인 종목 / 변동성 수축 국면 / Stage 1 말기 종목을 찾습니다.
[시드] symbols 미지정 시 Yahoo most_actives + day_gainers + small_cap_gainers
[사전필터] KR breakout과 동일 구조
[전략] Breakout 전용 7개
Args: symbols: 스크리닝할 티커 목록. None이면 Yahoo 스크리너에서 시드 수집 top_n: 시드 후보 상한 exclude_if_up_pct: 오늘 이 % 이상 오른 종목 제외 max_cumulative_return_pct: 최근 N일 누적 상승률 상한 cumulative_return_days: 누적 상승률 계산 기간 high_ceiling: 52주 고점 대비 상한 (0.85 = 고점의 85% 이하) low_floor: 52주 저점 대비 하한 (1.20 = 저점의 120% 이상) lookback_days: 거래량 급증 룩백 spike_threshold: 거래량 급증 배율 (기본 2.0) baseline_days: 비교 기준 기간
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | ||
| top_n | No | ||
| exclude_if_up_pct | No | ||
| max_cumulative_return_pct | No | ||
| cumulative_return_days | No | ||
| high_ceiling | No | ||
| low_floor | No | ||
| lookback_days | No | ||
| spike_threshold | No | ||
| baseline_days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 the data sources (Yahoo screeners), pre-filter, and strategy (7 breakout-specific). However, it does not mention any limitations, rate limits, or mutation behavior; the tool appears read-only but this is not confirmed.
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?
The description is well-structured with a clear purpose statement, technical details, and an Args section. It is moderately long but avoids fluff. Every sentence adds value, though some minor redundancy could be trimmed.
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?
Given the tool's complexity (10 parameters, no annotations, output schema exists), the description adequately covers purpose, usage, seed logic, and parameter meanings. It references a sibling for comparison, but does not elaborate on output fields (acceptable since output schema exists).
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?
The input schema has 0% description coverage, but the description lists all 10 parameters with concise explanations (e.g., 'symbols: None uses Yahoo', 'exclude_if_up_pct: exclude stocks up more than this % today'). This fully compensates for the schema's lack of descriptions.
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?
The description clearly states the tool filters US stocks about to break out, explicitly differentiating itself from the sibling 'screen_us_momentum' by stating it is the opposite concept. It provides specific verbs and resource identification.
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?
The description specifies when to use this tool (for accumulation/breakout stocks) and contrasts it with 'screen_us_momentum' for momentum stocks. It also explains default seed behavior, but does not explicitly state when not to use it beyond this comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_us_momentumA
미국 주식에서 '최근 N일 내 거래량 급증 + 추세 정합' 종목을 필터링합니다.
[시드] symbols 미지정 시 Yahoo most_actives + day_gainers + small_cap_gainers
[사전필터] 순차 적용:
· 당일 과열 제외: 오늘 등락률이 exclude_if_up_pct 이상이면 제외 (추격 매수 방지)
· 거래량 급증: max(최근 lookback일) / 이전 baseline일 평균 ≥ spike_threshold
· Minervini Trend Template (옵션): Stage 2 상승추세 6조건
· 52주 고점 근접 (옵션): 현재가 ≥ 52주고점 × high_proximity
· RS vs SPY (옵션): 3개월 초과수익률 ≥ min_rs_outperformance (pp)
[전략] 10가지 기술적 전략 적용
Args: symbols: 스크리닝할 티커 목록. None이면 Yahoo 스크리너에서 시드 수집 top_n: 시드 후보 상한 exclude_if_up_pct: 오늘 등락률이 이 값(%) 이상이면 제외. None이면 미적용 (기본 10.0) lookback_days: 거래량 급증 룩백 spike_threshold: 급증 배율 baseline_days: 비교 기준 기간 enable_trend_template: Minervini Trend Template 사용 여부 enable_near_52w_high: 52주 고점 근접 필터 사용 여부 high_proximity: 52주 고점 대비 허용 비율 (0.75 = 고점의 75% 이상) enable_rs_filter: SPY 대비 RS 필터 사용 여부 rs_period_days: RS 수익률 계산 기간 (기본 63 ≈ 3개월) min_rs_outperformance: 벤치마크 초과수익 하한 (pp)
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | ||
| top_n | No | ||
| exclude_if_up_pct | No | ||
| lookback_days | No | ||
| spike_threshold | No | ||
| baseline_days | No | ||
| enable_trend_template | No | ||
| enable_near_52w_high | No | ||
| high_proximity | No | ||
| enable_rs_filter | No | ||
| rs_period_days | No | ||
| min_rs_outperformance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the step-by-step filtering logic (exclusion, volume spike, trend template, etc.) and mentions 10 technical strategies, but omits specifics about the strategies and does not disclose if the tool has any side effects (e.g., 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, subsections, and parameter list. It is fairly long but every section adds value. Could be slightly more concise without losing info.
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?
Covers the filtering logic and all 12 parameters comprehensively. Output is not described but output schema exists. Missing details on the 10 technical strategies, but overall adequate for the complexity.
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?
Schema coverage is 0%, but the description thoroughly explains each parameter with defaults and meaning (e.g., exclude_if_up_pct, spike_threshold). This adds substantial value beyond the raw schema.
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?
The description explicitly states it filters US stocks based on volume surge and trend alignment, with specific references to Yahoo data sources. It clearly differentiates from sibling tools like screen_kr_momentum and screen_us_breakout by specifying 'US' and 'momentum' criteria.
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?
Provides clear context on when to use (filtering momentum stocks from Yahoo) and details the sequential pre-filters. However, lacks explicit 'when not to use' or direct comparison to siblings like diagnose_stock.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_stockA
종목명으로 종목코드를 검색합니다.
Args: keyword: 검색할 종목명 (예: '삼성전자', '알체라')
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the basic operation but lacks details on error handling, rate limits, or whether it is a read-only operation.
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?
The description is very concise, with two sentences and an args block. It is front-loaded and contains no unnecessary information.
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?
Given the tool has an output schema, return values need not be explained. However, the description lacks details on search behavior (e.g., partial matches, case sensitivity) and error conditions, making it marginally adequate.
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?
Schema description coverage is 0%, so the description adds necessary meaning for the keyword parameter with examples. It improves understanding beyond the raw schema.
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?
The description clearly states the tool's function: searching for a stock code by stock name. It provides examples and distinguishes from sibling tools that focus on analysis and screening.
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?
The description implies usage when needing a stock code from a name, but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.
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.
8 tool updates
v0.1.0- First observed
diagnose_stock - First observed
get_stock_analysis - First observed
get_us_stock_analysis - First observed
screen_kr_breakout - First observed
screen_kr_momentum - First observed
screen_us_breakout - First observed
screen_us_momentum - First observed
search_stock
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: diagnosis, analysis (KR/US), screening by strategy and market, and ticker search. There is no overlap between tools; even the screening tools are differentiated by market and strategy type.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., diagnose_stock, get_stock_analysis, screen_kr_breakout). The naming scheme is predictable and uniform across all tools.
With 8 tools, the server is well-scoped for stock analysis and screening. It covers core functionalities without being overly numerous or too sparse, providing a focused yet comprehensive set.
The tool set covers analysis, diagnosis, screening for both markets, and ticker search. Minor gaps exist, such as the absence of a dedicated quote tool, but the analysis tools include OHLCV. Overall, the surface is thorough for its domain.
Maintenance
Related MCP Connectors
Market analyst tools + AI agent: crypto, US equities, options, Korea, fundamentals, macro, backtests
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Screen 11,000+ stocks using natural language and detect chart patterns via MCP.
Technical analysis (RSI, MA, signal score) for 9,400+ global stocks, by ticker or name.
Related MCP Servers
AlicenseNot gradedqualityCmaintenanceProvides Korean stock market data (KOSPI, KOSDAQ, KONEX) including prices, fundamentals, investor trading, short selling, and indices via MCP protocol, enabling natural language queries from AI agents like ChatGPT and Claude.65 PyPI3MIT- FlicenseAqualityDmaintenanceEnables Claude to trade Korean and overseas stocks, check balances, and search stock information through the Korea Investment & Securities Open API.12-
- AlicenseNot gradedqualityAmaintenanceProvides 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.163 npm22MIT
- AlicenseNot gradedqualityFmaintenanceProvides 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.5Apache 2.0