The Richgo Finance MCP server provides tools to search and analyze Korean stocks, access market data, screen and rank stocks, retrieve export data, build portfolios, and integrate with Obsidian for reporting.
Stock Search & Analysis
Search stocks by name or ticker (richgo_search_stock), fetch detailed public data including valuation, cash flow, safety metrics, and percentiles (richgo_get_stock_detail), or resolve and analyze in one step (richgo_analyze_stock).
Screening & Rankings
Score ranking tables with filters (richgo_get_scores), undervalued stock screens across multiple modes: total, TTM, gap, composite, analyst, and risky (richgo_get_undervalued), AI-powered rankings with country/market/tier filters (richgo_get_ai_rankings), curated screener buckets like compound quality and income safe (richgo_get_curation), and breakout/special momentum signals (richgo_get_breakout).
Market Data
Bundled market dashboard (richgo_get_market_dashboard), ticker snapshots with freshness metadata (richgo_get_market_ticker), market environment score history, investor flow trends (foreign/institution/pension/individual), PER/PBR valuation history, seasonality, and global market comparisons.
Export Data
Korea export overview with monthly history and sector-stock mappings (richgo_get_exports_overview), country-level export/import series (richgo_get_exports_nations), and regional export rankings (richgo_get_exports_region_ranking).
Portfolio & Consensus
Get consensus picks combining scores, undervaluation, and AI rankings into a ranked candidate list (richgo_get_consensus_picks), build integer-share portfolios by budget and risk profile (richgo_build_portfolio), and use a guided beginner portfolio wizard (richgo_guided_portfolio).
Reporting
Save generated portfolio reports to an Obsidian vault (richgo_save_obsidian_report).
Generic Wrappers & Discovery
Access any public /api/market/... or /api/... endpoint via generic wrappers (richgo_get_market_api, richgo_get_public_api), and list all available services via richgo_service_catalog.
Allows saving portfolio reports and investment analysis to an Obsidian vault as markdown notes.
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., "@Richgo Finance MCP Show me the top undervalued Korean stocks"
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.
Model Context Protocol (MCP) server for public data exposed by
finance.richgo.ai.
It lets MCP clients search Korean stocks, fetch Richgo stock detail data, and use Richgo's ranking, undervaluation, AI ranking, curation, refreshed market dashboard, and Korea export-data screens from an assistant.
This project only calls public Richgo Finance endpoints by default. It does not bypass authentication or scrape private account data.
richgo_search_stock: search by Korean stock name or ticker.
richgo_get_stock_detail: fetch public detail for a ticker.
richgo_analyze_stock: search/alias resolve, then fetch compact analysis.
richgo_get_scores: score ranking table.
richgo_get_undervalued: undervalued stock tabs.
richgo_get_ai_rankings: AI ranking tab.
richgo_get_curation: curated screener buckets.
richgo_get_breakout: breakout/special signal endpoint.
richgo_get_exports_overview: Korea export overview, monthly export/import/trade balance history, sector-stock mappings, and export/employment momentum.
richgo_get_exports_nations: country-level export/import series and trade balances.
richgo_get_exports_region_ranking: regional export rankings and change rates.
richgo_get_market_ticker: headline market ticker snapshot, with freshness metadata for Korean index dates.
richgo_get_market_score_history: market environment score history.
richgo_get_market_investor_trend: foreign/institution/pension/individual investor flow trends.
richgo_get_market_valuation_history: market PER/PBR valuation history.
richgo_get_market_seasonality: market seasonality distribution and trajectory.
richgo_get_market_global_compare: global market comparison trajectories.
richgo_get_market_dashboard: bundled refreshed start/market page data.
richgo_get_market_api: generic /api/market/... wrapper.
richgo_get_public_api: constrained generic /api/... wrapper.
richgo_get_consensus_picks: merge Richgo scores, undervaluation, gap, and AI rankings into one ranked candidate list.
richgo_build_portfolio: build an integer-share portfolio from Richgo consensus signals for a budget and risk profile.
richgo_save_obsidian_report: save a generated portfolio report to a user-provided Obsidian vault path.
richgo_guided_portfolio: beginner-friendly portfolio wizard that uses MCP form elicitation when the client supports it.
richgo_service_catalog: list exposed services.
Related MCP server: Korean Stock MCP
After this package is published to npm, you can run it directly with npx.
Add this to your MCP client config:
{
"mcpServers": {
"richgo-finance": {
"command": "npx",
"args": ["-y", "richgo-finance-mcp"]
}
}
}Restart your MCP client, then ask naturally:
셀트리온 리치고 데이터로 분석해줘git clone https://github.com/reallygood83/rfmcp.git
cd rfmcp
npm install
npm run buildnpm startOn the original author's Mac, Homebrew Node was broken, so this bundled Node path was used:
export PATH=/Users/moon/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin:$PATH
npm run build
npm start{
"mcpServers": {
"richgo-finance": {
"command": "node",
"args": ["/absolute/path/to/rfmcp/dist/index.js"]
}
}
}You do not need to know the MCP tool names. Ask naturally:
아이티센글로벌 리치고 데이터로 분석해줘
/rf 셀트리온 분석해줘
삼성전자와 SK하이닉스 리치고 상세 지표 비교해줘
리치고 저평가 total 상위 10개 보여줘
AI 랭킹 상위 종목을 요약해줘
리치고 시작페이지에 새로 생긴 시장 현황 데이터를 요약해줘
한국 수출 데이터 기준으로 섹터와 관련 종목을 뽑아줘
외국인과 기관 수급 흐름을 리치고 시장 데이터로 보여줘
리치고 컨센서스 기준으로 오늘 투자 매력 높은 종목 10개 뽑아줘
500만원 중립형 포트폴리오 만들어줘
초보자용 리치고 포트폴리오 마법사 시작해줘
나는 잘 모르니까 질문하면서 300만원 투자 전략 만들어줘
오늘 리치고 기준으로 뭐가 제일 좋아?
1000만원이면 몇 종목을 몇 주씩 사면 좋을까?
이 결과를 내 Obsidian 볼트에 보고서로 저장해줘
Most MCP clients choose tools from the descriptions below. These are the intended natural-language routes:
User says | Preferred tool | What happens |
|
| Resolves the stock and returns compact Richgo detail. |
|
| Returns the requested screen. |
|
| Returns export/import/trade-balance history and sector-stock export mappings. |
|
| Returns the refreshed Richgo start/market page data bundle or focused market series. |
|
| Combines scores, undervaluation, gap, and AI ranking into one candidate list. |
|
| Builds an integer-share portfolio with cash balance and risks. |
|
| Uses form elicitation when supported, then builds the portfolio. |
|
| Saves only when a vault path is provided or configured privately. |
richgo_get_market_ticker and the ticker section inside
richgo_get_market_dashboard add a freshness object. Check it before writing
KOSPI/KOSDAQ values as "current" market levels.
status: "verify_before_current_use" means the Korean index ticker date is
older than the estimated latest Korea regular-session close.
expectedLatestKoreaCloseDate is estimated in Asia/Seoul time: after 16:00
KST on weekdays it expects today's close; before then it expects the previous
weekday; weekends roll back to Friday.
Korean public holidays are not modeled, so treat the warning as a guardrail, not as an exchange-calendar substitute.
This repo includes a Claude-style slash command template at commands/rf.md.
Install it as /rf with:
mkdir -p ~/.claude/commands
cp commands/rf.md ~/.claude/commands/rf.mdAfter that, use prompts like:
/rf 셀트리온 분석해줘The /rf command is tuned to produce data-backed Korean reports, not just a
metric dump. It should connect revenue, profitability, cash flow, financial
safety, valuation, and Richgo percentile signals into a concrete story that is
easy to understand.
The portfolio tools intentionally do not hardcode a personal vault path. This keeps the published MCP reusable for other users.
Recommended natural-language flow:
초보자용 리치고 포트폴리오 마법사 시작해줘If your MCP client supports form elicitation, the server asks for budget, risk profile, number of stocks, and whether to save to Obsidian. If the client does not support elicitation, call:
500만원 중립형 포트폴리오 만들어줘To save Obsidian reports, either pass vaultPath in the tool call:
{
"budget": 5000000,
"riskProfile": "balanced",
"vaultPath": "/absolute/path/to/your/vault",
"noteDir": "Richgo"
}Or keep the path in your private shell/MCP environment:
export RICHGO_OBSIDIAN_VAULT_PATH='/absolute/path/to/your/vault'Do not commit personal vault paths to this repository.
Public endpoints work without auth. If you legitimately need login-only Richgo features, set your own cookie:
export RICHGO_COOKIE='...'This server does not bypass authentication.
Richgo Finance data is informational only and is not investment advice. Final investment decisions and responsibility belong to the user.
Resolve a user stock query through Richgo search/local aliases, fetch detail, and return a compact analysis payload.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Stock name or ticker, e.g. 네이버, NAVER, 아이티센글로벌, 124500. | |
| includeRaw | No | Include the full raw Richgo detail payload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the composite workflow (resolve, fetch, return) but does not disclose side effects, idempotency, or behavior for ambiguous queries. Adequate but not detailed.
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 efficiently conveys three actions. Compact and front-loaded, though could benefit from structure to separate the composite steps.
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?
No output schema, so description should explain return payload. Only says 'compact analysis payload' without detailing fields like price, name, or indicators. Incomplete for agent to understand what to expect.
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% with descriptions for both parameters. The description adds minimal value beyond the schema (e.g., 'compact analysis payload' for includeRaw) but does not introduce new semantic 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 specifies the tool resolves a query, fetches detail, and returns a compact analysis payload. It implies combination of search and detail but does not explicitly differentiate from sibling tools like richgo_search_stock or richgo_get_stock_detail.
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. The description does not mention when-not-to-use or provide criteria for choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Richgo AI ranking tab with country, market, sort, top, and tier filters.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | KR | |
| market | No | Market filter, e.g. all, kospi, kosdaq, us. | all |
| sort | No | Sort key accepted by Richgo, e.g. total or health. | total |
| top | No | ||
| tiers | No | Optional tier labels joined for Richgo's tiers parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The term 'fetch' implies a read-only operation, but the description does not disclose any additional behavioral traits such as rate limits, response format, or potential side effects.
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 concise sentence that front-loads the tool's purpose. No wasted words.
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?
The tool has 5 parameters and no output schema or annotations. The description does not explain the return format, pagination, error handling, or any constraints beyond the schema defaults. This leaves significant gaps for an agent to correctly invoke the 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?
With 60% schema coverage (3 of 5 parameters have descriptions), the baseline is 3. The description merely lists the filter names without adding meaning beyond the schema. It does not explain how parameters interact or provide examples.
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 fetches Richgo AI ranking tab and lists the available filters (country, market, sort, top, tier). This verb+resource+scope makes it distinct from sibling tools like richgo_get_scores or richgo_get_undervalued.
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 fetching rankings with filters, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Richgo breakout/special-signal results. The site may return empty arrays for some signal types.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Signal type accepted by Richgo, e.g. all, breakout, confluence. | all |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It mentions that the site may return empty arrays for some signal types, which is a useful behavioral note. However, it does not address other aspects like authentication, rate limits, or side effects.
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 with two sentences. It front-loads the primary purpose and includes a relevant caveat, with no superfluous content.
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 fetch tool with no output schema, the description provides core functionality and a behavioral note. However, it omits details about parameters and return format, leaving some gaps.
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 description does not mention or explain the tool's parameters. The input schema covers only one of two parameters (type) with a description; limit lacks description. The tool description adds no meaning beyond the schema, resulting in inadequate compensation for the 50% schema coverage.
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 that the tool fetches breakout/special-signal results from Richgo, specifying a verb and resource. However, it does not differentiate this tool from siblings like richgo_get_curation or richgo_get_scores.
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. The description lacks context on prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Richgo curated screener bucket such as compound_quality, income_safe, chart_breakout, health_quality, industrial_growth, it_stability, or consumer_margin.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Curation key from the Richgo screener UI. | compound_quality |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Fetch', omitting whether the operation is read-only, what the response contains (e.g., list of stocks, metrics), or any side effects, rate limits, or auth requirements.
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, front-loaded sentence that conveys the purpose efficiently. No redundant or extraneous 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?
The description is too vague for a tool with no output schema. It does not specify the return format (e.g., list of tickers, scores), pagination, or any additional context needed for an agent to correctly interpret and use the output.
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 100% description coverage (one parameter 'key' with a description and default). The description adds example key values, which helps but does not significantly expand on the schema's meaning. Baseline 3 is appropriate.
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 verb 'Fetch' and the resource 'Richgo curated screener bucket', and provides concrete examples of valid keys (e.g., compound_quality). This distinguishes it from sibling tools like richgo_get_scores or richgo_get_breakout, though it could explicitly contrast with them.
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 (e.g., richgo_get_scores, richgo_get_breakout). The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic wrapper for public /api/market/{path} endpoints discovered in the app bundle. Use for market status endpoints not yet promoted to a first-class tool.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path after /api/market/, e.g. KR/combined-score. | |
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only mentions 'public' endpoints, but lacks details on authentication, rate limits, or response structure. Behavioral traits are minimally disclosed.
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?
Two concise sentences with no redundancy. The purpose and usage are front-loaded, making it easy to parse.
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 generic nature and lack of output schema, the description adequately explains its role. However, it omits any mention of error handling, return format, or constraints, which would be helpful for a wrapper 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 coverage is 50%, and the description adds no extra meaning to parameters. The path parameter is only mentioned in a generic example, and the params object is not elaborated. Should compensate for low schema coverage but does not.
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 is a generic wrapper for /api/market/{path} endpoints, and specifies its use for market status endpoints not yet having a dedicated tool, effectively distinguishing it from sibling tools like richgo_get_scores.
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 says 'Use for market status endpoints not yet promoted to a first-class tool,' providing clear guidance on when to choose 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.
Constrained GET wrapper for public /api/... Richgo endpoints. This is useful while mapping newly discovered site services.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | A /api/... path on finance.richgo.ai. | |
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'constrained' but does not explain constraints (e.g., rate limits, authentication, allowed paths). The behavioral traits are vague.
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?
Two sentences with no waste. Front-loaded with core action (constrained GET wrapper) and usage context. However, brevity sacrifices important detail, preventing a higher score.
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 lack of annotations, output schema, and minimal parameter documentation, the description is incomplete. It does not explain return values, error handling, or the full scope of the tool's behavior, leaving critical gaps for an 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?
Schema coverage is 50% (path described, params not). The description does not add meaning for params beyond the schema, failing to compensate for the low coverage. The param structure remains unclear.
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 is a constrained GET wrapper for public /api/... endpoints, which is a specific verb-resource combination. It also mentions its utility for mapping newly discovered site services, but does not explicitly differentiate from sibling tools, which are more specific (e.g., richgo_get_scores).
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 during exploration ('mapping newly discovered site services'), but does not provide explicit when-to-use or when-not-to-use guidance versus siblings. It lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the Richgo score/screener table with optional market, sort, tier, period, and limit filters.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | all | |
| sort | No | Sort key accepted by Richgo, commonly score, undervalue, per, marketCap. | score |
| tier | No | Richgo tier filter such as 대형주, 중형주, 소형주. | |
| period | No | Period key accepted by Richgo, e.g. 1m, 3m, 6m, 1y. | 1y |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosing behavioral traits. It only states 'Fetch,' implying a read operation, but does not mention authentication needs, rate limits, pagination, or the impact of the limit parameter on behavior. This is minimal for a tool that retrieves data.
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 sentence that front-loads the action and resource, listing all optional filter types. Every word contributes without redundancy, making it highly concise and easy to parse.
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 5 optional parameters, no output schema, and no annotations, the description provides the basic purpose but lacks details about return format, error handling, or limitations. It is sufficient for a simple fetch but incomplete for an agent to fully understand the tool's behavior.
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 already provides descriptions for 3 of 5 parameters (sort, tier, period) and enumerates market options. The description merely lists parameter names without adding new semantic detail. Given 60% schema coverage, the description does not need to compensate much, but it could clarify default behaviors or valid values more explicitly.
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 fetches the Richgo score/screener table with optional filters. While it is specific about the resource (score/screener table), it does not explicitly distinguish from sibling tools like richgo_get_ai_rankings or richgo_get_breakout, which serve different data types.
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 discussion of context, prerequisites, or exclusions, leaving the agent without decision support for selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch public Richgo Finance detail for a stock ticker, including valuation, cash flow, safety, percentiles, and reports when available.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker code, e.g. 005930 or 124500. | |
| compact | No | Return a compact summary instead of the full Richgo JSON payload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states 'public' and lists content categories, implying a read-only fetch with typical stock data. However, it does not disclose rate limits, authorization needs, or any edge cases (e.g., what happens for invalid tickers). It adds some context beyond the schema but is not exhaustive.
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 efficiently conveys the tool's purpose and output contents. No redundant words or 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 no output schema and no annotations, the description provides a reasonable overview of the returned data. It lists several categories (valuation, cash flow, safety, percentiles, reports) but omits any mention of error handling, pagination, or response structure. For a simple fetch tool with two parameters, this is nearly 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?
Schema coverage is 100%, with both parameters described adequately (ticker pattern and example, compact as boolean). The description does not add new meaning beyond the schema; it simply states the tool fetches detail. So baseline 3 is appropriate.
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 uses specific verb 'Fetch' and resource 'Richgo Finance detail', listing included data categories (valuation, cash flow, safety, percentiles, reports). Among siblings like richgo_analyze_stock and richgo_get_scores, this definition clearly distinguishes by the scope of data returned.
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 explicit guidance on when to use this tool versus alternatives. With multiple sibling tools (e.g., richgo_analyze_stock, richgo_get_scores), the description does not indicate when to choose this over others or mention conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Richgo undervalued-stock service. Modes mirror the site tabs: total, ttm, gap, composite, analyst, risky.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | total | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states 'Fetch' (implies read) but does not disclose authentication needs, rate limits, or whether the operation is read-only. Minimal behavioral context.
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?
Two concise sentences with no fluff. Every word adds value. Appropriate length for the tool's simplicity.
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 no output schema and no annotations, the description should provide more context about return format, pagination (implied by limit), or usage tips. It only covers modes, leaving gaps.
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%, so description must compensate. It explains the 'mode' parameter with enum values ('total, ttm, gap, composite, analyst, risky'), but the 'limit' parameter is completely ignored. Incomplete coverage.
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 fetches undervalued stocks with modes mirroring site tabs. Specific verb 'Fetch' and resource 'undervalued-stock service'. However, it does not differentiate from sibling tools like richgo_get_breakout or richgo_get_scores.
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 alternatives. Lacks explicit context or exclusions. Only lists mode options without explaining selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Richgo Finance for a stock by Korean name, partial name, or code. Returns matching stock candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Stock name or ticker, e.g. 삼성전자, 아이티센글로벌, 005930. | |
| limit | No |
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 mentions search by Korean names/partial names/codes and returns candidates, but lacks disclosure on behavior like handling non-Korean names, ambiguity, pagination (limit is in schema but not explained), rate limits, or scope (e.g., only Korean markets).
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?
A single, concise sentence that front-loads the action and parameters. Every word adds value; no redundancy or jargon.
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 search tool with two parameters and no output schema, the description is largely complete. It covers what the tool does and the input types. However, it could mention the output format or typical use case (e.g., 'Use to find the correct code before calling detail endpoints').
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 50% (query has a description, limit does not). The description adds context that the query can be a Korean name, partial name, or code, but does not elaborate on 'limit' beyond what the schema provides (default 8, min 1, max 50). This is adequate but not exceptional.
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 action ('Search'), resource ('Richgo Finance stocks'), and input types ('Korean name, partial name, or code'). It also specifies the output ('matching stock candidates'), distinguishing it from siblings like 'richgo_get_stock_detail' which would retrieve details for a specific stock.
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 explicit guidance on when to use this tool versus the many sibling tools (e.g., analyze, detail, rankings). The description implies usage for initial discovery, but does not mention prerequisites, exclusions, or recommended follow-ups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show all Richgo Finance services currently exposed by this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read-only operation ('Show'), but it does not explicitly state safety, authentication needs, or whether it alters state. The behavioral transparency is adequate but could be improved.
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, concise sentence that conveys the tool's purpose without any unnecessary words or repetition.
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 listing tool with no parameters and no output schema, the description is largely complete. It could be enhanced by mentioning the return format or use case, but it suffices for agent understanding.
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 no parameters, so the input schema provides all necessary information. The description adds no param-level details, but the baseline for 0 parameters is 4.
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: listing all Richgo Finance services. The verb 'Show' and resource 'services' are specific, and it distinguishes from sibling tools that focus on individual finance operations.
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 its siblings. Given the many sibling tools, explicit advice (e.g., 'Use this to discover available services before calling specific ones') would be beneficial.
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.
v1.0.0richgo_analyze_stockrichgo_get_ai_rankingsrichgo_get_breakoutrichgo_get_curationrichgo_get_market_apirichgo_get_public_apirichgo_get_scoresrichgo_get_stock_detailrichgo_get_undervaluedrichgo_search_stockrichgo_service_catalogScored across 11 tools
Most tools have distinct purposes (search vs. analysis vs. various screeners), but the generic wrappers (richgo_get_market_api, richgo_get_public_api) and overlap between richgo_analyze_stock and richgo_get_stock_detail (both fetch detail) could cause confusion for an agent.
All tools follow a consistent 'richgo_verb_noun' pattern in snake_case, making it easy to predict the action and resource for each tool.
With 11 tools covering search, analysis, multiple screeners, and generic wrappers, the count is well-scoped for a financial data server—neither too few nor too many.
The server covers essential stock research operations (search, detail, analysis, screeners) and includes generic wrappers for future endpoints. Minor gaps like historical data or news are not explicitly present, but the wrappers mitigate this.
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
Market analyst tools + AI agent: crypto, US equities, options, Korea, fundamentals, macro, backtests
AI-powered stock analysis: nightly ratings, on-demand deep-dives, and watchlist insights.
Fetch current stock prices and key data for symbols across global markets. Look up companies like…
