Este es un servidor del Protocolo de Contexto de Modelo (MCP) que proporciona análisis técnico y cribado basado en estrategias para acciones de Corea y EE. UU. Puede realizar análisis de gráficos y cribado de acciones mediante lenguaje natural en clientes compatibles con MCP como Claude Desktop y Claude Code.
🇰🇷 Análisis de acciones coreanas — OHLCV + indicadores técnicos para todas las acciones de KOSPI/KOSDAQ basado en pykrx
🇺🇸 Análisis de acciones estadounidenses — Acciones de NYSE/NASDAQ + capitalización de mercado/PER/máximos y mínimos de 52 semanas basado en yfinance
🔍 Búsqueda de acciones — Encontrar códigos de acciones por nombre (acciones coreanas)
📊 10 estrategias de Momentum + 7 estrategias de Breakout — Desde cruces dorados hasta VCP
🎯 Dos filosofías de cribado — 🐎 Atrapar caballos en carrera vs 🌱 Encontrar caballos que pronto correrán
🔎 Prefiltros multietapa — Aumento de volumen, Trend Template, RS, bandas de 52 semanas, etc.
Related MCP server: KIS MCP Server
Herramienta | Descripción | Ejemplo de entrada |
| Análisis técnico de acciones coreanas |
|
| Análisis técnico de acciones estadounidenses |
|
| Búsqueda de nombre de acción → código |
|
| 🐎 Atrapar caballos en carrera coreanos (Tendencia Etapa 2) |
|
| 🐎 Atrapar caballos en carrera estadounidenses |
|
| 🌱 Encontrar caballos que pronto correrán coreanos (VCP, acumulación, final Etapa 1) |
|
| 🌱 Encontrar caballos que pronto correrán estadounidenses |
|
| Diagnóstico de estrategia para una acción específica |
|
Captura la continuación de la tendencia (Etapa 2) de acciones que ya han entrado en una tendencia alcista. Basado en las teorías CANSLIM de O'Neil y Trend Template de Minervini.
Pipeline
시드 (네이버 거래량/상승률/급등 | 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 전략 적용Estrategias aplicadas (10)
4 existentes: Cruce dorado + volumen, compra en retroceso, ruptura de momentum, explosión de volumen
6 nuevas: Divergencia RSI, divergencia MACD, estocástico, BB Squeeze, ruptura de Ichimoku, alineación de 3 medias móviles
Captura acciones en fase de acumulación / justo antes de la ruptura que aún no se han movido significativamente. Basado en el patrón VCP de Mark Minervini y la teoría de acumulación de Wyckoff.
Pipeline
시드 (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)Estrategias aplicadas (7)
4 reutilizadas: Compra en retroceso, explosión de volumen, divergencia MACD, BB Squeeze
3 nuevas: Contracción de volatilidad VCP, acumulación silenciosa, transición al final de la Etapa 1
🐎 Momentum | 🌱 Breakout | |
Filosofía | Continuación de tendencia | Acumulación → Inicio de ruptura |
Retorno acumulado | Sin límite | Excluye > +30% en 30 días |
Posición 52 semanas | Se recomienda cerca de máximos | Máximo 85% + Mínimo 120% de banda |
Trend Template | ON (Requiere alineación de MA) | OFF |
Aumento de volumen | 3.0x | 2.0x (la acumulación es menos explosiva) |
Número de estrategias | 10 | 7 (incluye 3 nuevas) |
Timing adecuado | Mercado fuerte, seguimiento de tendencia | Reingreso tras ajuste, reversión de suelo |
Basado en el mismo mercado (KOSPI):
Momentum: Perspect (cumple 6 estrategias) — Acción que ya está corriendo
Breakout: Daewon Cable -20.32% en 30 días, retroceso + VCP en el 72% del máximo de 52 semanas — Típico de acumulación
Divide los últimos 15 días en 3 segmentos de 5 días y determina si el rango de máximo-mínimo (%) se contrae secuencialmente. Forma de resorte de bobinado → Ruptura inminente. (Mark Minervini)
El promedio de volumen de los últimos 20 días aumenta en comparación con los 20 días anteriores y hay días de aumento repentino, pero el rango de variación de precio en los mismos 20 días es dentro de ±8% → Acumulación de manos fuertes no revelada al mercado.
Segmento que pasa de un rango lateral de suelo (Etapa 1) a un ascenso suave (inicio de Etapa 2).
Pendiente de MA60 superior a la de hace 1 mes
MA20 > MA60 (transición alcista a corto plazo)
Precio de cierre > MA60 (soporte asegurado)
Ancho de BB ≤ promedio de 20 días (volatilidad aún no expandida)
Parámetro | Predeterminado | Uso |
| 10.0 | Excluye si sube +10% hoy. |
| 3.0 | Multiplicador de aumento de volumen |
| True | Minervini Trend Template |
| False | Filtro RS (activar para ver solo acciones fuertes) |
| 0.0 | Umbral de exceso de retorno sobre benchmark (pp) |
Parámetro | Predeterminado | Uso |
| 30.0 | Límite superior de retorno acumulado en N días (%) |
| 30 | Período de cálculo acumulado |
| 0.85 | Solo pasa si es menor que Máximo 52 semanas × este valor |
| 1.20 | Solo pasa si es mayor que Mínimo 52 semanas × este valor |
| 2.0 | Aumento de volumen (multiplicador relajado para acumulación) |
Python 3.13+
uv (recomendado)
git clone https://github.com/Juuuuuuni/stock-mcp-server.git
cd stock-mcp-server
uv syncAgregue lo siguiente a ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %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 — Framework de servidor MCP
pykrx — Datos de la Bolsa de Corea
yfinance — Datos de Yahoo Finance
ta — Indicadores de análisis técnico
BeautifulSoup + lxml — Parsing HTML de Naver Finance / Yahoo Screener
pandas — Procesamiento de datos
William J. O'Neil — How to Make Money in Stocks (CANSLIM)
Mark Minervini — Trade Like a Stock Market Wizard (Trend Template, VCP)
Richard Wyckoff — Teoría de acumulación/distribución de precio-volumen
Stan Weinstein — Secrets for Profiting in Bull and Bear Markets (Análisis de Etapas)
MIT
특정 종목이 10가지 단기 전략 중 어떤 조건에 해당하는지 상세 진단합니다.
■ 기존 전략: 골든크로스+거래량, 눌림목 매수, 모멘텀 돌파, 거래량 폭발 ■ 신규 전략: RSI 다이버전스, MACD 다이버전스, 스토캐스틱 과매수/과매도, BB 스퀴즈, 일목균형표 구름대 돌파, 3선 정배열/역배열
Args: ticker: 종목코드 (한국) 또는 티커심볼 (미국). 예: '005930', 'AAPL' market: 'KR' 또는 'US'. 기본 'KR'
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| market | No | KR |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
종목코드를 입력하면 OHLCV + 기술적 지표를 분석합니다.
Args: ticker: 종목코드 (예: '347860' for 알체라, '005930' for 삼성전자) days: 조회 기간 (일수, 기본 120일)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
미국 주식 종목을 분석합니다.
Args: symbol: 티커 심볼 (예: 'AAPL', 'TSLA', 'NVDA', 'GOOGL') days: 조회 기간 (일수, 기본 120일)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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_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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
한국 주식에서 '최근 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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_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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
미국 주식에서 '최근 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
종목명으로 종목코드를 검색합니다.
Args: keyword: 검색할 종목명 (예: '삼성전자', '알체라')
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0diagnose_stockget_stock_analysisget_us_stock_analysisscreen_kr_breakoutscreen_kr_momentumscreen_us_breakoutscreen_us_momentumsearch_stockScored 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.
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.
