K-Data — Korean Sell-Side Research & Market Data

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.

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.

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.

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

With no annotations, the description carries the behavioral burden and does substantial work: it discloses a $0.03 USDC fee, x402 settlement, a 10-symbol cap, and the economic distinction between quoted and realizable premium. It does not mention whether data is live or cached, nor rate limits, so it is not a perfect 5, but it is far above a minimal definition.

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 filler. The conceptual distinction is front-loaded, symbol constraints appear in the middle, and cost/settlement is at the end. Every clause adds information relevant to selecting or invoking the tool.

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 a single optional parameter and no output schema, the description covers the metric definitions, the two field names, symbol syntax, the symbol cap, and the cost. It does not spell out the response container or behavior when symbols are omitted, but the schema covers the default and the named fields are sufficient to interpret results.

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 symbols parameter fully, including format, default, and optionality, so the baseline is 3. The description adds the max-10 constraint and a concrete example, which improves call correctness beyond the schema alone.

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 defines the tool as returning the kimchi premium in two distinct forms, naming the exact fields and their meanings. It stops short of an explicit verb like 'returns' and does not directly compare with history/stats siblings, but the two-basis explanation makes the resource unambiguous.

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 is given for when to use this tool versus kimchi_premium_history, kimchi_premium_stats, or crypto_krw_ticker. The usage context is only implied: an agent needing the two premium rates can infer this tool is appropriate, but exclusions and alternatives are not stated.

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

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

With no annotations to fall back on, the description carries the behavioral burden well: it discloses ordering, cursor-based pagination, archive depth, per-call cost, and x402 settlement. It could also explain the response shape and exactly what 'both bases' means, but the provided behavioral detail is strong for an unannotated 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 dense but every sentence earns its place: result orientation, parameter example, pagination rule, archive depth, and pricing. It is front-loaded with the core purpose and wastes no 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?

Given the moderate complexity and absence of an output schema, the description provides enough operational detail for an agent to invoke the tool correctly, paginate through results, and understand archive limits. The main gap is the exact response field layout, which would be more important if this were a more complex or less self-describing API.

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 all four parameters. The description adds a compact URL-style example and restates defaults, but it does not materially add meaning beyond the schema. 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 identifies the resource (kimchi premium time series), the source (continuous archive), the ordering (newest-last), and coverage (both bases). It stops short of a 5 because it lacks an explicit verb like 'returns' or 'fetches' and does not directly name a sibling tool for comparison, though 'continuous archive' implies historical vs. current data.

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 clear operational context: how to paginate with next_before, how to read a full window, and how archive depth is reported. It does not explicitly state when to use this tool instead of kimchi_premium or kimchi_premium_stats, but the historical-archive framing makes the intended use reasonably clear.

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

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

With no annotations, the description carries the transparency burden and does well: it discloses the computed outputs, the proprietary continuous archive, and the $0.12 USDC/x402 cost. It stops short of stating response format or failure behavior, but for a read-only statistical query this is adequate.

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?

Five short, purposeful units: purpose, output list, use case, param sketch, pricing. There is no filler, and the most decision-relevant information is 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?

There is no output schema, so the description compensates by listing the fields returned and the cost to call. However, it leaves the exact response shape and the boundary with preview_kimchi_premium implicit, which is a minor gap.

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 symbol, window, and basis with enums and defaults. The compact param string in the description mostly duplicates that information rather than adding new semantic meaning.

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 names a specific analytical object—where the current kimchi premium falls within its own distribution—and enumerates concrete outputs: percentile, mean, stdev, z-score, min/max/median, and a plain-language read. This clearly distinguishes it from sibling tools like kimchi_premium (current value) and kimchi_premium_history (raw history).

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?

It gives an explicit trigger question ('is this premium unusual right now?') and a rationale for using this paid archive over free sources. It does not name siblings to avoid, but the use case is specific enough to route an agent.

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

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.

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.

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.

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is free, live, BTC-only, and a sample, but it does not explain update frequency, access/auth requirements, rate limits, or what exactly 'sample' omits.

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 short, front-loaded sentences: one states what the tool provides, and the other routes to the paid alternative. There is no wasted detail 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 no-parameter preview tool, the description gives a reasonable high-level overview, but with no output schema it does not state the response shape or fields. The term 'sample' is also vague, and the paid-endpoint reference would benefit from naming the exact sibling 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 has zero parameters with full schema coverage, so there is no parameter ambiguity. The description does not need to explain any parameters, 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 tool as a free, live, BTC-only sample of the kimchi premium, using a specific resource and scope. It also distinguishes it from the paid multi-symbol endpoint referenced within the description.

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?

It explicitly states the primary use case (free BTC-only preview) and directs the agent to the paid endpoint for up to 10 symbols. However, it does not name the paid sibling tool directly or mention other alternatives like history or stats tools, leaving some routing ambiguity.

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

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.

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.

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.

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.

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.