Skip to main content
Glama
Yeom

yummy-research-mcp

by Yeom

yummy-research-mcp

An MCP server that exposes overseas and domestic macro/market statistics as tools. The first data set consists of market sentiment/valuation indices, but it is designed to add KRX, DART, Bank of Korea ECOS, FRED, etc., in the same pattern in the future.

Current Tools

name

description

get_cnn_fear_greed

CNN Fear & Greed Index (US) — current value + daily history

get_kospi_fear_greed

Indexergo KOSPI Fear & Greed Index (idxDetail=24501, daily)

get_kospi_buffett

KOSPI Buffett Index = Market Cap (20104,D) / Sum of previous 4Q GDP (09140,Q) × 100

get_all_indices

Returns all three of the above at once

Each tool returns a JSON in the format { name, source, latest, series, ... }.

Related MCP server: rays-mcp

Development Environment

Based on 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                    # 라이브 엔드포인트 스모크 테스트

Claude Code / Claude Desktop Registration

{
  "mcpServers": {
    "yummy-research": {
      "command": "uv",
      "args": [
        "--directory",
        "/Users/yeom/workspace/yummy-research-mcp",
        "run",
        "yummy-research-mcp"
      ]
    }
  }
}

Adding New Data Sources

  1. Write a fetcher in src/yummy_research_mcp/sources/<source>.py — pure function, returns a JSON-serializable dict.

  2. Add Tool + callable to the TOOLS registry in src/yummy_research_mcp/server.py.

  3. Add live smoke tests in tests/.

Directory

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

Data Source Notes

  • CNN F&G: production.dataviz.cnn.io/index/fearandgreed/graphdata JSON API. Browser UA + Origin: edition.cnn.com + Referer are required (returns 418 if missing).

  • indexergo: Extract the first series.data from the page's inline ECharts option JSON using balanced bracket scanning. Static HTML parsing was adopted as it is more stable than the site's /ajaxMakeChart POST endpoint.

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

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

Related MCP Connectors

Related MCP Servers

  • 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
  • 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.
    -
  • 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
  • A
    license
    Not graded
    quality
    B
    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