yummy-research-mcp
Exposes market sentiment and valuation indicators for US and Korean markets via MCP tools.
get_cnn_fear_greed: Retrieve the CNN Fear & Greed Index with the current value and daily history (up to ~254 trading days); optionally limit the history to the most recent N entries.
get_kospi_fear_greed: Get the KOSPI Fear & Greed Index (daily series) with the current value and business-day history.
get_kospi_buffett: Calculate the KOSPI Buffett indicator (market cap / trailing 4-quarter GDP sum × 100) and return raw market-cap and GDP series.
get_all_indices: Fetch all three indicators in one call, along with a
fetched_attimestamp.
Provides the CNN Fear & Greed Index, a market sentiment indicator for US stocks, including current value and daily history.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@yummy-research-mcpshow me the latest fear and greed index values"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 |
| CNN Fear & Greed Index (US) — current value + daily history |
| Indexergo KOSPI Fear & Greed Index (idxDetail=24501, daily) |
| KOSPI Buffett Index = Market Cap (20104,D) / Sum of previous 4Q GDP (09140,Q) × 100 |
| 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
Write a fetcher in
src/yummy_research_mcp/sources/<source>.py— pure function, returns a JSON-serializable dict.Add
Tool+ callable to theTOOLSregistry insrc/yummy_research_mcp/server.py.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.pyData Source Notes
CNN F&G:
production.dataviz.cnn.io/index/fearandgreed/graphdataJSON API. Browser UA +Origin: edition.cnn.com+Refererare required (returns 418 if missing).indexergo: Extract the first
series.datafrom the page's inline EChartsoptionJSON using balanced bracket scanning. Static HTML parsing was adopted as it is more stable than the site's/ajaxMakeChartPOST endpoint.
Available Tools
4 toolsget_all_indicesA
등록된 모든 지표를 한 번에 fetched_at 타임스탬프와 함께 반환.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 영업일).
| Name | Required | Description | Default |
|---|---|---|---|
| max_history | No | 히스토리 시계열을 최근 N개로 자르기. 생략 시 전체. |
TDQS
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.
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.
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.
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.
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.
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 시계열 동봉.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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, 일간) — 현재값 + 영업일 시계열.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
4 tool updates
v0.1.0- First observed
get_all_indices - First observed
get_cnn_fear_greed - First observed
get_kospi_buffett - First observed
get_kospi_fear_greed
TDQS
Scored across 4 tools
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.
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.
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.
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
Related MCP Connectors
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
Macro indicators from World Bank, FRED, IMF, and OECD via unified query surface.
Market analyst tools + AI agent: crypto, US equities, options, Korea, fundamentals, macro, backtests
Financial data MCP for market, company, news, macro, and US Congress research.
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides Korean Exchange (KRX) Open API data as MCP tools, supporting 31 APIs for indices, stocks, ETP, bonds, derivatives, commodities, and ESG.311MIT
- FlicenseNot gradedqualityDmaintenanceExposes global market breadth, volume, RSI, volatility, and sentiment for 12 major equity indices (US + Asia) via 5 tools.-
- AlicenseBqualityCmaintenanceMCP server that provides Korean Exchange (KRX) Open API market data as tools, covering indices, stocks, ETPs, bonds, derivatives, commodities, and ESG.31MIT
- AlicenseNot gradedqualityBmaintenanceKorean 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.7MIT