Korean equity research, analyst revisions, kimchi premium and news via x402.
Scored across 16 tools
Most tools have clearly distinct purposes (live ticker vs. history vs. distribution stats vs. snapshot; Korean vs. English news; per-ticker vs. consensus vs. latest research). The main overlaps are the free preview_* endpoints duplicating paid counterparts and korea_market_snapshot bundling kimchi_premium + crypto_krw_markets + fx_usdkrw, but descriptions clearly flag these relationships.
All tools use consistent snake_case with predictable domain prefixes (crypto_, kimchi_, news_, research_, preview_, fx_). Names are readable and follow a stable noun/verb-noun convention throughout.
16 tools is slightly above the typical sweet spot but justified by the server spanning two product lines (crypto/FX market data and equity research) plus a deliberate free-preview tier. Each tool maps to a distinct endpoint; no filler.
Covers live quotes, history, stats, snapshots, bilingual news, and per-ticker/consensus/latest research, which is solid lifecycle coverage for the stated purpose. Minor gaps exist (e.g., no equity index/OHLC history, no search by brokerage/analyst, no historical FX series), but core workflows are complete.
Snapshot of all Upbit KRW crypto markets: top by 24h traded value, top gainers, top losers. Optional ?limit=30 (max 100) for the volume ranking. Costs $0.01 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many top-volume markets to return (default 30, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait: the $0.01 USDC cost and x402 settlement mechanism. However, it does not explicitly state that this is a read-only snapshot, nor does it mention rate limits, data freshness, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the purpose and output categories; the second concisely covers the parameter and cost. Every sentence earns its place.
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 single-parameter snapshot tool, the description covers what it returns, the parameter bounds, and the cost. It lacks explicit output schema details, but the categories (top traded value, gainers, losers) provide reasonable expectations. Minor omissions around error behavior and freshness do not prevent correct invocation.
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%, and the schema already documents the 'limit' parameter with default and max. The description adds marginal context that the limit applies to the volume ranking, but this is largely redundant with the schema's 'top-volume markets' phrasing.
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 provides a snapshot of all Upbit KRW crypto markets, listing specific output categories: top by 24h traded value, top gainers, and top losers. This distinguishes it from likely single-market tools like crypto_krw_ticker, though it does not explicitly name differences.
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 purpose strongly implies usage for broad market overviews rather than individual tickers or derived metrics, but no explicit when-to-use or alternative routing is provided. Sibling tools are not referenced, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live quote for one Upbit KRW market by ticker symbol (e.g. BTC, ETH, XRP): price, 24h change, 24h high/low, 24h traded value in KRW. Costs $0.005 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Coin ticker symbol, e.g. BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It discloses a key behavioral trait: each call costs $0.005 in USDC settled via x402. It also states what data will be returned. It does not cover invalid-ticker behavior, but for a read-only quote tool the important transparency is present.
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 tight sentences: the first front-loads the tool's purpose, scope, and output fields; the second provides the critical cost and settlement detail. Every clause earns its place.
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 single-parameter tool with no output schema, the description covers the returned fields, market scope, and pricing—enough for an agent to invoke it correctly. Minor gaps are the lack of guidance for discovering valid tickers and behavior on invalid symbols, but these do not block correct use.
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 single parameter is already fully documented in the schema ('Coin ticker symbol, e.g. BTC') with 100% coverage. The description adds examples and market context, but no new semantic constraints, formatting rules, or enumeration, so the baseline of 3 applies.
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 a specific verb ('Live quote') and a precise resource ('one Upbit KRW market by ticker symbol'), with concrete examples and the exact data fields returned. This clearly distinguishes it from siblings like crypto_krw_markets, which lists markets, and fx_usdkrw, which covers USD/KRW FX rates.
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 clearly establishes the context: use this tool for a single Upbit KRW market quote identified by ticker. However, it does not explicitly state when not to use it or point to crypto_krw_markets as the way to discover valid tickers, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current USD/KRW exchange rate (ECB reference via Frankfurter, fallback open.er-api.com). Costs $0.005 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that each call costs $0.005 in USDC, settles via x402, and uses a fallback source. It does not mention response format or rate limits, but the cost and fallback behavior are valuable beyond the schema.
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 and front-loaded with the core behavior. The source/fallback and cost details are appended without redundancy or filler.
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 tool, the description is nearly complete: it states the rate being fetched, the data sources, and the cost. It stops short of describing the exact return structure, but the simple nature of the tool makes the expected output reasonably inferable.
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 tool has zero parameters, so the schema already fully covers the input surface. The description does not need to add parameter-level detail, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: the current USD/KRW exchange rate. It does not use an explicit verb, but it is specific and easily distinguished from the crypto-focused sibling tools. It could be stronger by explicitly differentiating itself from siblings like crypto_krw_ticker.
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 use when a current USD/KRW fiat exchange rate is needed. It does not explicitly state when to use this tool over the crypto/KRW siblings or when not to use it, but the purpose is clear enough to infer typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call Korea briefing: dual-basis kimchi premium + top Upbit KRW markets + USD/KRW + latest economy headlines translated to English. Everything needed for a Korea market read in a single paid request. Costs $0.08 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it delivers meaningful disclosures: the call is paid (costs $0.08 in USDC, settled via x402) and the headlines are translated to English. This goes beyond what the empty schema provides. It stops short of a 5 because it does not mention data freshness, caching, latency, or what happens if an upstream source fails.
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?
Three sentences with no waste: the value proposition is front-loaded, the content list is structured with a colon and plus-separated items, and the cost/payment detail is isolated in the final sentence. Every sentence earns its place.
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-parameter aggregator with no output schema, the description is complete enough: it enumerates all content components and discloses the cost and settlement mechanism. Minor gaps remain around the response format and data freshness, but these are not critical for an agent deciding to invoke this 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?
The tool has zero parameters and the schema already documents that completely, so the baseline of 4 applies. The description correctly focuses on what the tool returns rather than parameters, and there is nothing missing for an agent to invoke it correctly.
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 what the tool delivers: a composite Korea briefing with specific enumerated components (dual-basis kimchi premium, top Upbit KRW markets, USD/KRW, translated economy headlines). It implicitly differentiates from the granular sibling tools by framing itself as the 'one-call' aggregator, though it never names a sibling or states a concrete verb.
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 phrase 'Everything needed for a Korea market read in a single paid request' gives clear context for when to choose this tool: when the agent wants a complete Korea overview without issuing multiple calls to siblings. The explicit cost and settlement disclosure ($0.08 USDC via x402) also signals a paid-versus-free trade-off against the sibling tools, though no alternative names or when-not-to-use exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest Korean headlines from Yonhap, Maeil Business and Hankyung, deduplicated and newest-first. Titles stay in Korean — use /api/news/headlines/en for English. Optional ?category=top|economy|tech|politics and ?limit=30 (max 100). Costs $0.01 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (default 30, max 100) | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions deduplication, newest-first ordering, the Korean-only language constraint, and the $0.01 USDC cost settled via x402. It could additionally state that this is a read-only operation or describe error/rate-limit behavior, but the disclosed traits are meaningful and useful.
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 compact: three sentences cover purpose, language caveat, alternative route, parameters, and cost. Information is front-loaded with the core purpose before auxiliary details. There is no fluff or redundant phrasing.
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 optional-parameter headline fetcher with no output schema, the description is nearly complete: it covers sources, ordering, deduplication, language, the sibling alternative, parameter constraints, and cost. It does not describe the response shape or pagination beyond limit, but that is a minor gap for this low-complexity 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?
The input schema already documents both parameters with 100% coverage, including the enum values and the max/default for limit. The description largely repeats this information rather than adding new semantic detail. It does restate the category options and default limit, which is harmless but not a significant value-add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching the latest Korean headlines from three named sources. It also differentiates itself from the sibling tool by explicitly stating that titles stay in Korean and pointing to the English alternative. Deduplication and newest-first ordering add further precision.
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 gives explicit guidance on when to use this tool versus the English alternative: use this for Korean-only headlines, use the English endpoint when English titles are needed. It also states the optional category and limit parameters, giving an agent enough context to decide whether this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest Korean headlines with English translations attached (title_en), from Yonhap, Maeil Business and Hankyung — deduplicated, newest first. Use this instead of the Korean-only route when the consuming agent does not read Korean. Optional ?category=top|economy|tech|politics and ?limit=20 (max 50). Costs $0.05 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (default 20, max 50) | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses sources, deduplication, ordering, English translation behavior, per-call cost in USDC, and x402 settlement. It leaves a few minor details unstated, such as exact response shape, but the core behavioral transparency is strong.
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 compact and each clause earns its place: core purpose, usage guidance, parameters, and cost. The most important differentiator, English translations, is front-loaded immediately.
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 annotations and no output schema, the description provides enough operational detail to use the tool correctly: sources, language, ordering, dedup, optional parameters, and cost/settlement. Nothing essential is missing.
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 covers both parameters with descriptions and enum values, so schema coverage is 100%. The description restates the limit default/max and category values but adds little semantic meaning beyond confirming that both are optional.
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 identifies the resource (Korean headlines), the key differentiator (English translations as title_en), and distinguishes this from the Korean-only sibling news_headlines. The purpose is immediately clear: fetch an English-translated, deduplicated, newest-first headline feed.
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 explicitly says 'Use this instead of the Korean-only route when the consuming agent does not read Korean.' This gives the agent a clear decision rule and names the alternative route without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, date-stamped archive-depth check for one 6-digit KRX ticker. Shows report and brokerage counts, not report content or consensus.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | 6-digit KRX code, e.g. 005930 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by saying the check is free, date-stamped, archive-depth, and limited to counts rather than content. However, it does not disclose whether authentication is needed, what the response shape looks like, or any limits/side effects. For a read-only preview tool this is acceptable but not comprehensive.
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, tightly packed sentence with no filler. It front-loads the key facts (free, date-stamped, archive-depth, single ticker) and immediately clarifies the output scope and exclusions. Every clause earns its place.
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 tool with one parameter, no output schema, and no nested objects, the description is largely complete: it states the input, what the output contains, and what it does not contain. A minor gap is the lack of any mention of response shape or error behavior, but that is less critical for such a simple preview check.
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 schema already documents the single parameter as a 6-digit KRX code with an example, so schema coverage is 100%. The description reinforces this by mentioning 'one 6-digit KRX ticker' but adds no additional semantic detail beyond what the schema provides. The baseline of 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 a specific action (preview/check), a specific resource (archive-depth for one 6-digit KRX ticker), and the output (report and brokerage counts). It also usefully excludes report content and consensus, clarifying what the tool is not. However, it does not explicitly differentiate itself from the likely sibling preview_research_coverage, which may have an overlapping scope.
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 when to use the tool: for a quick, free, date-stamped count of reports and brokerages for a single ticker. 'Not report content or consensus' hints at what this tool is not for, but it does not explicitly name alternatives or state when to prefer another sibling tool. The guidance is present but left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, date-stamped KRX research coverage. Lists the most-covered tickers with report count, brokerage count, and archive date range; it does not reveal report content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many tickers to show (default 25, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing that the tool is free, date-stamped, lists only coverage metadata, and explicitly does not reveal report content. It could add ordering or freshness details, but this is a simple read-only list and the disclosed boundaries are useful.
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 tightly written sentences with no filler. The main scope is front-loaded, and the exclusion of report content is stated in the same breath, making the definition quick 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?
For a simple one-parameter list tool with no output schema, the description provides the key return concepts: tickers, report counts, brokerage counts, and archive date range. It also sets expectations about what is not included. Exact field names and data freshness are absent but not critical for invocation.
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 only parameter, limit, is already fully documented in the schema with a default and max, so schema coverage is 100%. The description adds no extra parameter-level detail, which earns the baseline score of 3.
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 uses a specific verb ('Lists') and a specific resource ('the most-covered tickers') while enumerating output components (report count, brokerage count, archive date range). The explicit statement that it does not reveal report content clearly separates it from content-focused sibling research tools.
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 'preview' framing and the 'does not reveal report content' disclaimer imply this is for coverage-level reconnaissance rather than report content retrieval. However, it never names sibling tools or states explicit conditions such as 'use research_latest for report content,' so guidance remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every archived Korean brokerage report for one KRX ticker, newest first: target price, rating, brokerage, analyst, the Korean title with its English translation, and a one-line English summary. Params: ?limit=20 (max 50). Costs $0.05 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reports (default 20, max 50) | |
| ticker | Yes | 6-digit KRX code, e.g. 005930 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering, returned fields, the limit cap, and the $0.05 USDC fee settled via x402. It does not mention pagination or error cases, but for a read-only data retrieval tool this is solid coverage.
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 with no wasted words. The primary purpose and ordering are front-loaded, and the cost and limit details are concise and relevant.
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 list tool with two documented parameters and no output schema, the description covers the returned fields, ordering, limit, and cost. Missing details like pagination and explicit alternative tool comparisons are minor 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 description coverage is 100%, so the schema already documents both parameters. The description adds the default limit and cost context, but does not add significant semantic meaning beyond what the schema provides.
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 and resource: it returns every archived Korean brokerage report for one KRX ticker. It also lists the exact fields returned, making it easy to distinguish from other research tools.
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 conveys clear usage context: use this tool when you need per-ticker brokerage reports, newest first. It does not explicitly name alternatives or state when not to use it, but the one-ticker scope and sibling tool names make the intended use reasonably evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyst consensus for one KRX ticker, built from the archived research history: mean/median/min/max target price across brokerages, the spread between them, the rating distribution, and a revision log of every target-price and rating change each house has made. Consensus uses each house's latest view, so a weekly publisher does not outvote a quarterly one. Params: ?window=30d|90d|180d|365d (default 90d). Costs $0.12 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | 6-digit KRX code, e.g. 005930 | |
| window | No | Lookback window (default 90d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the calculation methodology, the lookback window semantics, the revision log behavior, and the $0.12 USDC cost settled via x402. It does not cover error handling or exact response structure, but it goes well beyond a minimal description.
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 four sentences, each carrying distinct value: scope, returned content, methodology, and parameters/cost. It is slightly dense but not wasteful, and it front-loads the core purpose before details.
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 tool with no output schema, the description lists the main result categories and the pricing model, and the schema fully handles parameters. It lacks exact JSON field names and any notes on empty results or error behavior, but an agent has enough to decide and invoke correctly.
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 documented including the 6-digit ticker format, the window enum, and default. The description adds the cost and restates the window options, but otherwise does not add meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as analyst consensus for a single KRX ticker and enumerates the exact metrics returned (mean/median/min/max target price, spread, rating distribution, revision log). It distinguishes itself from broad research_latest by scoping to one ticker, though it does not explicitly name any sibling alternative.
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 conveys the core use case—get consensus across brokerages for one KRX ticker—and explains the methodology (each house's latest view, so weekly publishers don't outvote quarterly ones). However, it does not explicitly state when not to use it or contrast it with siblings like research_company_ticker or research_latest, leaving some selection reasoning to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest Korean brokerage equity research across all covered companies, newest first — company and KRX ticker, target price, rating, brokerage, analyst, and a one-line English summary of each report. Facts and summaries only; the report PDF stays with its publisher and source_url links back to it. Optional ?limit=20 (max 50). Costs $0.02 in USDC per call, settled via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reports (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well. It discloses the output ordering, the fact that only facts and summaries are returned, that the PDF stays with the publisher, that source_url links back to the report, and the exact cost and settlement method.
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 dense but not bloated; every clause contributes scope, return fields, behavioral caveats, or cost. The sentence listing fields is a bit long, but it remains readable and front-loads the core purpose before the caveats and cost.
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 one-parameter list tool with no output schema, the description covers the return fields, ordering, link behavior, and cost. It does not specify pagination beyond the limit, but the tool is simple enough that nothing essential is missing for a correct invocation.
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 schema already documents the only parameter, limit, with a description and max value. The tool description restates this as 'Optional ?limit=20 (max 50)', adding only the default value and query-string form. Since schema coverage is 100%, a baseline of 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 identifies the resource: latest Korean brokerage equity research across all covered companies, ordered newest first. It enumerates the exact fields returned, which distinguishes it from ticker-specific or consensus siblings by scope and ordering.
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 phrase 'across all covered companies, newest first' establishes a clear context for when to use this tool: to get a broad, chronological feed of the latest research. It does not explicitly name alternatives or state when not to use it, but the all-companies scope makes the intended use evident.
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.
kimchi_premium_history1 field changedInput schema / properties / beforeAdded value: +{
+ "description": "Unix-second cursor from next_before; returns older rows strictly before it",
+ "type": "integer"
+}preview_kimchi_premiumpreview_premium_coveragepreview_researchpreview_research_coveragekimchi_premium_history1 field changedInput schema / properties / beforeRemoved value: -{
- "description": "Unix-second cursor from next_before; returns older rows strictly before it",
- "type": "integer"
-}preview_kimchi_premiumpreview_researchpreview_research_coveragecrypto_krw_marketscrypto_krw_tickerfx_usdkrwkimchi_premiumkimchi_premium_historykimchi_premium_statskorea_market_snapshotnews_headlinesnews_headlines_enpreview_kimchi_premiumpreview_researchpreview_research_coverageresearch_company_tickerresearch_consensus_tickerresearch_latestKorean equities in English: DART filings, activist & foreign-holder classification, KRX news.
Korea stock (KOSPI/KOSDAQ) bottom/top signals: verdict + score, scans. Pay-per-call x402.
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
SEC filings, insider trades, 13F, IPO calendar, macro & FX MCP tools via x402.
Add one secure layer between your agents and this server.