Skip to main content
Glama
deenesjakoruzh
Yeom

yummy-research-mcp

by Yeom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

yummy-research-mcp

해외·국내 거시/시장 통계를 도구로 노출하는 MCP server. 첫 번째 데이터 셋은 시장 심리/밸류에이션 지표지만, 향후 KRX·DART·한국은행 ECOS·FRED 등을 같은 패턴으로 추가하도록 설계.

현재 도구

name

설명

get_cnn_fear_greed

CNN Fear & Greed Index (US) — 현재값 + 일별 히스토리

get_kospi_fear_greed

인덱서고 코스피 공포탐욕지수 (idxDetail=24501, 일간)

get_kospi_buffett

코스피 버핏지수 = 시가총액(20104,D) / 직전 4Q GDP 합(09140,Q) × 100

get_all_indices

위 셋을 한 번에 반환

각 도구는 { name, source, latest, series, ... } 형태의 JSON을 반환.

Related MCP server: rays-mcp

개발 환경

uv 기반.

cd ~/workspace/yummy-research-mcp

uv sync                          # 의존성 설치 (.venv 자동 생성)
uv run yummy-research-mcp        # MCP stdio 서버 실행
uv run python -m yummy_research_mcp.sources.cnn        # 단독 페치 디버깅
uv run pytest                    # 오프라인 단위 테스트

Codex 등록

yummy-agent/.codex/config.toml에 프로젝트 설정이 있다. 자동 실행하는 yummy_research/yummy_codex/runner.py도 동일 서버를 명시적으로 등록한다. 기존 Claude 플러그인 manifest는 사용하지 않는다.

[mcp_servers.yummy-research]
command = "/Users/yeom/workspace/yummy-research-mcp/.venv/bin/python"
args = ["-m", "yummy_research_mcp.server"]

가상 환경이 없으면 먼저 이 프로젝트에서 uv sync로 설치한다. 서버 도구 목록에 나타나는 것과 외부 데이터 소스가 정상 응답하는 것은 별도로 검증한다.

새 데이터 소스 추가

  1. src/yummy_research_mcp/sources/<source>.py에 페처 작성 — 순수 함수, JSON-직렬화 가능한 dict 반환.

  2. src/yummy_research_mcp/server.py의 TOOLS 레지스트리에 Tool + 콜러블 추가.

  3. tests/에 라이브 스모크 테스트 추가.

디렉토리

src/yummy_research_mcp/
  __init__.py
  http.py                # 공통 urllib 래퍼 (browser-like UA / Accept-Language)
  server.py              # MCP stdio 서버 + 도구 레지스트리
  sources/
    cnn.py               # CNN Fear & Greed (production.dataviz.cnn.io)
    indexergo.py         # indexergo.com (인라인 ECharts JSON 파싱)
tests/
  test_fetchers.py

데이터 소스 메모

  • CNN F&G: production.dataviz.cnn.io/index/fearandgreed/graphdata JSON API. 브라우저 UA + Origin: edition.cnn.com + Referer 필수 (없으면 418).

  • indexergo: 페이지 인라인 ECharts option JSON에서 첫 series.data를 균형 괄호 스캔으로 추출. 사이트의 /ajaxMakeChart POST 엔드포인트보다 정적 HTML 파싱이 안정적이라 그쪽 채택.

확장 설계

지표·공시·뉴스 MCP 확장 설계는 금리·미국채·원유, 시점별 관측 저장, 관심기업 공시, 데이터 품질과 신규 도구 계약을 정의한다. 전체 목표 설계이며 현재 구현 범위는 아래 구현 상태 문서와 구분한다.

오전·오후 브리핑용 데이터 (구현)

cp .env.example .env 후 키를 입력한다. .env는 Git에서 제외된다. FRED 키가 있으면 공식 JSON API, 없으면 공개 CSV 경로를 사용한다. 키는 서비스 내부에서만 읽고 MCP 응답이나 차트에 포함하지 않는다.

uv sync
uv run python -m yummy_research_mcp.collect collect
uv run python -m yummy_research_mcp.collect snapshot --as-of 2026-09-11T11:00:00Z
uv run python -m yummy_research_mcp.collect chart --snapshot-id SNAPSHOT_ID --out state/chart.png
uv run pytest
# 기존 외부 사이트 접속 시험은 선택 실행
YUMMY_LIVE_TESTS=1 uv run pytest tests/test_fetchers.py

추가 도구: list_metrics, get_market_snapshot, get_metric_series, get_source_health, get_company_filings, search_company_news. 기존 4개 도구도 유지한다. 지표 일괄 갱신·차트 파일 작성은 운영 CLI에서 수행한다.

  • 기본 수집·브리핑: 미국채 3·10·30년, 실질 10년, 정책금리 상·하단/실효금리, WTI 현물 등 8개 지표. Brent·광의 달러지수는 정기 수집과 차트에서 제외하며 기존 이력의 명시적 조회만 지원한다.

  • 지표 SQLite: state/market_data.db. observations는 수정값을 수집 시각별 보관, snapshots는 보고서 사용 시점의 고정 결과, health는 수집 성공·실패 이력의 최신 상태.

  • 과거 날짜 값을 오늘 처음 수집했다면 오늘부터 알려진 값으로 처리한다. 완전한 과거 시점 복원이나 ALFRED 전체 빈티지 구축은 아니다.

  • 금리 변화는 bp, 양수 가격 변화는 %. 비교 날짜를 반환한다. 일간 변동의 과거 분포 최소 120개가 있어야 주의 수준을 산출하며, 예측·매매 신호가 아니다.

  • 일별 값은 발표 지연이 있다. 관측일·최초 수집 시각을 구분하고 5일 초과 관측은 stale로 표시한다.

  • DART는 키 필요, SEC는 연락처 포함 User-Agent 필요. DART의 날짜 단위 검색은 장중 정확한 시각 필터를 보장하지 않는다.

  • 뉴스는 Google News RSS 제목 발견 기능. 기사 원문 검증·기업 식별·테마 인과 확인은 분석 단계에서 필요하며 전수 수집을 보장하지 않는다.

실제 Telegram 운영 프로그램은 인접한 yummy_research/에서 실행된다. 이 저장소는 데이터 MCP와 수집기만 버전 관리한다. 운영 연동과 남은 범위는 구현 상태를 참고한다.

Available Tools

4 tools
get_all_indicesA

등록된 모든 지표를 한 번에 fetched_at 타임스탬프와 함께 반환.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must disclose behavior. It mentions returning a timestamp, implying a snapshot, but does not explicitly state that it is read-only, idempotent, or free of side effects. Adequate for a simple retrieval tool.

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 in Korean with no redundant words. Every part contributes to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (no parameters, no output schema), the description adequately covers what the tool does and hints at the response format (timestamp). However, it could be more explicit about output structure.

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?

There are zero parameters, so schema coverage is 100%. The description adds no parameter information, which is acceptable since none exist. Baseline 4 for 0 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 returns all registered indicators with a fetched_at timestamp. The name 'get_all_indices' and sibling tools like 'get_cnn_fear_greed' imply this is an aggregate, but explicit differentiation is missing.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, exclusions, or when not to use it.

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

get_cnn_fear_greedA

CNN Fear & Greed Index — 미국 시장 심리 (0=공포, 100=탐욕). 현재값(이전 종가/1주/1개월/1년 비교 포함) + 일별 히스토리(약 254 영업일).

ParametersJSON Schema
NameRequiredDescriptionDefault
max_historyNo히스토리 시계열을 최근 N개로 자르기. 생략 시 전체.

TDQS

A4.2/5.0
Behavior4/5

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

Without annotations, the description carries full burden. It details data returned (current value with comparisons, ~254 business days of history) and the range meaning. No side effects or auth needs are mentioned, but for a read-only data tool, coverage is sufficient.

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 two sentences, front-loaded with the index name and scale, fitting essential information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple data retrieval tool with one optional parameter and no output schema, the description covers the index meaning, data components, and history length. Minor missing detail is the exact history format, but it's adequate.

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?

Schema coverage is 100% for the single optional parameter, so baseline is 3. The description does not add extra meaning beyond the schema's description of max_history (cutting history length), but it provides output context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly names the tool as CNN Fear & Greed Index for US market sentiment, defines the scale (0=fear, 100=greed), and lists specific components (current value with comparisons, daily history). This distinguishes it from sibling tools like get_kospi_fear_greed.

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

Usage Guidelines4/5

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

The description implies usage for retrieving US market sentiment data, contrasting with KOSPI-focused siblings. However, it lacks explicit when-to-use or when-not-to-use guidance.

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

get_kospi_buffettA

코스피 버핏지수 = 코스피 시가총액 / 직전 4Q GDP 합 × 100 (%). 원시 시총·GDP 시계열 동봉.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

Description explains the computation and included raw data, but without annotations, does not explicitly state that the operation is read-only or disclose data freshness, rate limits, or side effects. Adequate but not thorough.

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?

Single sentence that defines the tool's purpose and output efficiently. No wasted words; front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool, the description covers the essential computation and included data. Slightly lacking in explicit behavioral context (e.g., read-only hint) but otherwise complete.

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?

No parameters in input schema, so description need not explain them. Baseline of 4 applied as per scoring guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the formula and output (KOSPI Buffett index with raw time series). Distinct from siblings like get_cnn_fear_greed and get_kospi_fear_greed which target different indices.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs siblings (e.g., get_all_indices, get_kospi_fear_greed). Context for choosing this over alternatives is missing.

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

get_kospi_fear_greedA

코스피 공포탐욕지수 (인덱서고 idxDetail=24501, 일간) — 현재값 + 영업일 시계열.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It discloses that it returns current value and business day time series but omits details like data source, update frequency, or any behavioral quirks.

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?

Single sentence with all essential information (index name, detail ID, frequency, output) – very concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 0-param, simple read tool, the description is mostly complete. It could mention the time series range or update frequency, but it's acceptable.

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?

No parameters, so baseline 4 applies. Description adds no parameter info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides the KOSPI Fear & Greed Index with current value and daily time series. It distinguishes from sibling tools like get_cnn_fear_greed and get_kospi_buffett.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_cnn_fear_greed or get_kospi_buffett. The description lacks context for selection.

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.

  1. 4 tool updatesv0.1.0
    • First observedget_all_indices
    • First observedget_cnn_fear_greed
    • First observedget_kospi_buffett
    • First observedget_kospi_fear_greed
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a specific index or a combined endpoint. get_all_indices is a meta-tool returning all indices, while the other three are distinct (US fear/greed, KOSPI Buffett, KOSPI fear/greed), with no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_<index_name>. The naming is predictable and descriptive, making it easy for an agent to understand the purpose of each tool.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of providing market sentiment and valuation indices. Each tool serves a clear role without unnecessary bloat or missing essentials.

Completeness4/5

The server covers the core indices it advertises (US fear/greed, KOSPI fear/greed and Buffett index) and provides a combined endpoint. A minor gap is the lack of a dedicated US Buffett index, but the combined endpoint likely includes it, so it's not a dead end.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • OpenKRX MCP Server

    RealYoungk
    A
    license
    B
    quality
    D
    maintenance
    Provides Korean Exchange (KRX) Open API data as MCP tools, supporting 31 APIs for indices, stocks, ETP, bonds, derivatives, commodities, and ESG.
    31
    1
    MIT

  • rays-mcp

    ivyyy0601
    F
    license
    Not graded
    quality
    D
    maintenance
    Exposes global market breadth, volume, RSI, volatility, and sentiment for 12 major equity indices (US + Asia) via 5 tools.
    -

  • openkrx-mcp

    joohyukjung
    A
    license
    B
    quality
    C
    maintenance
    MCP server that provides Korean Exchange (KRX) Open API market data as tools, covering indices, stocks, ETPs, bonds, derivatives, commodities, and ESG.
    31
    MIT

  • aikstockdata

    na77tech-creator
    A
    license
    Not graded
    quality
    A
    maintenance
    Korean stocks (KOSPI/KOSDAQ/KONEX), no signup, no API key. 12 read-only tools, streamable-http. Post-filing price paths BY DART FILING TYPE (market-adjusted median h0/h1/h5, 95% CI) + per-event ledger with receipt times (HH:MM) that public APIs omit. Plus T+1 closes, preliminary earnings, daily close history. Registry: com.aikstockdata/mcp. Updated each trading day ~18:30 KST, not real-time.
    7
    MIT