kr-crypto-intelligence

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

Annotations provide readOnlyHint and openWorldHint. The description adds that it returns status of specific exchanges and is free, which aligns with read-only behavior and adds context about pricing. No contradictions.

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?

Highly concise: two sentences plus a price line. The purpose is front-loaded, and every sentence provides useful information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, a simple health check, and an output schema exists, the description is complete. It specifies what exchanges are covered and that it's free, which is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline is 4, and the description adds value by listing the exchanges checked and stating it's free.

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 checks service health and exchange connectivity for three named exchanges (Upbit, Bithumb, Binance), distinguishing it from sibling data-fetching 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 does not explicitly state when to use this tool versus alternatives, nor provide when-not guidance. The only usage hint is the mention of 'FREE' pricing, which is minimal.

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?

Annotations include readOnlyHint and openWorldHint. The description adds that data is updated every 60 seconds and lists warning flags and payment details (x402 micropayment). This goes beyond annotations without contradiction.

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 moderately long but well-structured: main purpose first, then output details, update frequency, and payment info. Every sentence adds value, though the payment section could be slightly more concise.

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 parameters and an output schema, the description fully explains return values (premium percentages, flags) and includes critical payment and update frequency information. Complete for agent decision-making.

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, and schema coverage is 100%. The description adds no parameter info, but baseline is 4 as per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it scans Kimchi Premium for all tokens traded on Upbit and Binance, with specific outputs like premium percentages and flags. It distinguishes from siblings like get_kimchi_premium by specifying 'ALL tokens' and additional metrics.

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 says 'Essential for cross-exchange arbitrage analysis', which provides context for when to use. It does not explicitly mention when not to use or alternatives, but the sibling list implies other tools for general kimchi premium.

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?

Annotations already declare readOnlyHint and openWorldHint. Description adds specific exchanges (Upbit, Bithumb) and cost info (free), supplementing the annotations with valuable behavioral details.

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?

Extremely concise: two sentences plus a price line, with no wasted words. Front-loaded with the core action and purpose.

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 read-only tool with no parameters and an output schema, description covers purpose, exchanges, and usage context. Lack of edge-case discussion is acceptable given simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline for 0 params is 4. Description does not need to add parameter semantics, and it correctly omits them.

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?

Clearly states it retrieves available trading symbols from Korean exchanges (Upbit, Bithumb, common to both). Distinguishes from sibling tools that focus on prices, news, or sentiment.

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 advises using it before other tools to check available symbols. Also notes it's free, providing clear context for usage decisions, though does not explicitly state when not to use.

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?

Beyond the annotations (readOnlyHint, openWorldHint), the description adds behavioral details: it detects specific flags, and new listings/delistings are detected by comparing market list changes every 60 seconds. It also mentions payment via x402 micropayment, which is a behavioral cost/friction trait. No contradiction with annotations.

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 includes necessary details: alert types, detection method, use case, and payment info. It is somewhat lengthy but not overly verbose. The structure is clear, with the most critical info front-loaded. Minor improvement could be consolidating payment 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?

Given the tool's external data source complexity and the presence of an output schema (not shown), the description fully explains the purpose, detection method, and importance for risk management. The payment details are also included, making it complete 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 in the input schema, and schema coverage is 100% trivial. The description adds meaning by explaining what alerts are detected and the detection logic, compensating for the lack of parameter-related information. Baseline 3 is increased due to the added context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets Korean exchange alerts for new listings, delistings, investment warnings, and caution flags, and lists the specific alert types detected. It also explains the detection mechanism (comparing market list changes every 60 seconds). This is specific and distinct from sibling tools like get_kr_prices or get_arbitrage_scanner.

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 provides usage context by stating that the tool is critical for risk management and early listing detection. While it does not explicitly mention when not to use it or list alternatives, the context given is sufficient to guide appropriate use among sibling tools.

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?

The description adds critical behavioral details beyond annotations: payment cost, required x402 micropayment, and supported clients/chains. No contradictions with annotations.

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?

Front-loaded with purpose, but payment details add length. Structure is clear with sections, though could be more concise.

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?

With output schema present, description need not detail returns. Covers current rate and payment requirement, but misses update frequency or limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100%, so baseline 3 applies. Description adds no parameter info as none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the current USD/KRW exchange rate, but does not distinguish it from sibling tools like get_kr_prices or get_kimchi_premium.

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 hints at use for currency conversion ('Essential for converting'), but provides no when-not-to-use or alternative tools.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds useful behavioral context: 60-second cache, output structure, AI interpretation, and pricing/micropayment instructions. No contradictions.

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 front-loaded with core purpose, then necessary details. However, it includes pricing and payment instructions that could be separated, and the arg list repeats information. Still, each sentence adds value.

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 output schema, the description covers purpose, output fields, caching, supported symbols, and pricing. It provides sufficient context for an AI agent to 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 description coverage is 100%, so the input schema already fully documents the symbol parameter. The description repeats the list of supported symbols without adding new semantics beyond schema, meeting the baseline.

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 calculates the premium between CoinGecko global price and Upbit Korean price with AI interpretation. It mentions 'Light tier' to differentiate from the sibling 'deep' tool, and lists 25 supported symbols and specific output fields.

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 via 'Light tier' and 60s cache for quick divergences, but does not explicitly state when to use this versus sibling tools like 'get_global_vs_korea_divergence_deep' or 'get_kimchi_premium'. The context is clear but not exhaustive.

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?

Annotations (readOnlyHint, openWorldHint) indicate safe, possibly varying returns. Description adds '5-min cache' and details of returned fields, which supplements annotations without contradiction.

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?

Description is verbose, including extraneous pricing and payment details not relevant to tool selection. Key purpose is front-loaded, but overall structure is not concise.

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?

With existing output schema, description adequately explains tool's return structure (news signal, AI analysis). However, lacks usage context compared to sibling tools, making it somewhat incomplete.

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%, so baseline 3. Description repeats symbol list from schema, adding no new meaning. Does not explain parameter behavior beyond what 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?

Description clearly states the tool provides deep divergence analysis with Korean news signals and AI breakdown. The phrase 'Deep tier' distinguishes it from the sibling tool 'get_global_vs_korea_divergence', and specific components (news, AI analysis) are listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like the basic 'get_global_vs_korea_divergence'. Does not mention prerequisites, exclusions, or recommended scenarios.

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?

Annotations already provide readOnlyHint and openWorldHint. The description adds valuable behavioral context: it discloses the cost ($0.001 per call), required payment method (x402), and client requirements. It also explains the significance of the two premium values. No contradiction with annotations.

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 somewhat verbose, including payment details and a documentation URL in bullet points. It front-loads the core purpose but includes extraneous information that could be omitted or placed elsewhere. Could be more concise.

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 an output schema, the description effectively explains return values and the meaning of the gap between premium values. It covers the key aspects: what the tool does, what it returns, cost, and payment. Missing information about error cases or payment failures is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, symbol, has 100% schema description coverage. The description adds example values (BTC, ETH, XRP, SOL, DOGE) which provide additional guidance but do not significantly enhance 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 states it gets real-time Kimchi Premium, explains the concept (price difference between Korean and global exchanges), and specifies the outputs (premium_percent, etc.). It distinguishes from sibling tools by focusing on this specific premium metric.

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 context about Kimchi Premium and South Korea's trading volume, but it does not explicitly state when to use this tool over alternatives like get_arbitrage_scanner or get_global_vs_korea_divergence. Usage is implied but not clearly guided.

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?

The description discloses caching (5-min cache), AI relevance classification, and the source (Naver). It also includes pricing and payment method. These go beyond annotations (readOnlyHint, openWorldHint), which are consistent with the safe, read-only nature. No contradictions.

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 includes necessary functionality but also contains extensive pricing and payment details that may not be essential for tool selection or invocation. This reduces conciseness, though the core purpose 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?

Given the tool's simplicity (one parameter, clear output), the description fully covers input, output structure (fields like title_en, summary_en, etc.), caching, and origin. It provides complete context for an agent to decide and 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?

The input schema coverage is 100% with a single 'limit' parameter. The description repeats its range (1-10) and adds the default value (5), providing slight additional clarity over 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 explicitly states the tool returns 'Korean K-pop news' aggregated from Naver and translated to English. It distinguishes itself from sibling tools like get_kr_news_semiconductor and get_kr_news_kpop_summary.

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 explains the tool's value (Korean entertainment news moves global markets before English coverage) and mentions a 5-min cache, implying it should be used when fresh, translated news is needed. However, it does not explicitly specify when not to use it or compare usage with siblings like get_kr_news_kpop_summary.

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?

The description adds context beyond annotations (readOnlyHint, openWorldHint): 5-minute cache, x402 payment, and specific return fields including ai_analysis subfields. It aligns with readOnlyHint as a read operation.

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 front-loaded with purpose and key differentiators. It includes pricing and usage details but is not overly verbose. Some minor repetition (returns listed twice) but overall well-structured.

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 complexity (AI summary with multiple output fields) and the presence of an output schema, the description adequately covers behavior, caching, and payment. The return structure is clearly enumerated.

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 'limit' is fully described in the input schema (1-10, default 5). The description repeats this info without adding new semantics, so it meets the baseline for high 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 it provides Korean K-pop news with AI synthesis (sentiment, themes, entities, summary). It explicitly distinguishes itself from the sibling get_kr_news_kpop by adding the AI analysis layer.

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 explains when to use this tool over its sibling (same articles but with AI analysis). It also mentions caching and pricing, providing helpful context. It does not explicitly state when not to use, but the distinction is 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?

Annotations confirm read-only and open world; description adds cache duration, pricing, payment method, and output structure, going beyond annotations.

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?

Starts with core purpose but includes pricing and docs info that lengthens description; could be more concise.

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?

Covers input, caching, pricing, output structure; lacks error handling or authentication but output schema exists to clarify return values.

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 already describes limit with range and default; description repeats this without adding new semantics.

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?

Explicitly states it provides Korean semiconductor news translated to English, lists specific companies and topics, and distinguishes from sibling summary tool by returning full articles.

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 like get_kr_news_semiconductor_summary or other news tools; only mentions cache and pricing.

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?

The description adds behavioral context beyond annotations: mentions a 5-min cache, payment details (price, currency, clients, docs), and the specific structure of the ai_analysis output. The readOnlyHint and openWorldHint annotations are consistent with this read-only, paid tool. No contradictions.

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 moderately concise, front-loading the core purpose in the first sentence. However, it includes a block of payment details and a URL that may be considered extraneous for an AI agent's tool selection. It could be trimmed to focus on functional aspects.

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 complexity (AI analysis layer) and the presence of an output schema, the description covers the main aspects: articles base, AI fields, cache, pricing. It lacks details on how to handle the x402 payment flow, but for selection and invocation purposes, it is largely 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?

The only parameter 'limit' is fully described in both the schema and the description with identical information (integer, 1-10, default 5). Schema coverage is 100%, so the description adds no additional meaning beyond what the schema provides. Baseline score 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 it provides 'Korean semiconductor news plus AI market synthesis' and differentiates from sibling get_kr_news_semiconductor by explicitly listing the added AI analysis fields (overall_sentiment, key_themes, trending_entities, market_signal, summary). This makes the purpose and differentiation highly clear.

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 when an AI-enhanced summary is needed (by contrasting with the sibling without AI), but does not explicitly state when not to use it or suggest alternatives. The context is clear enough for correct selection.

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?

Annotations (readOnlyHint, openWorldHint) indicate safe read behavior. The description adds important behavioral context: payment via x402 micropayment, pricing info, and data returned. No contradictions with annotations.

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 relatively concise and well-structured with sections for purpose, payment, and arguments. However, including payment details may slightly detract from core functionality focus.

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 tool with two parameters and an output schema, the description fully covers what the tool does, what it returns, and all necessary context (including payment requirements). Complete 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?

Schema coverage is 100%, and schema parameter descriptions already provide examples and options. The description largely repeats this information with minor additions (e.g., more symbol examples). 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?

Clearly states it retrieves cryptocurrency prices from Korean exchanges (Upbit, Bithumb) and specifies the returned data (KRW-denominated prices, volume, change rate). It is distinct from sibling tools like get_kimchi_premium or get_arbitrage_scanner.

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 getting prices from Korean exchanges but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or sibling comparisons are provided.

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?

Annotations (readOnlyHint, openWorldHint) already declare safety and variability. Description adds value by detailing output fields, 1-hour cache, and real-time nature. No contradictions.

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?

Description is moderately verbose but includes necessary details like pricing and payment method. Structured with bullet points. Not overly long; every sentence adds information for an agent that may need to process payments.

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?

With no parameters and an output schema present, the description fully explains inputs (none), outputs (sentiment label, score, report, signals, news), and caching behavior. Complete for understanding tool's capability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 params, 100% schema coverage), so description doesn't need to add parameter info. Baseline 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?

Clearly states the tool provides Korean crypto market sentiment analysis in English, combining exchange intelligence and Korean news. Distinguishes from sibling tools like get_kimchi_premium and get_global_vs_korea_divergence by specifying its unique focus on sentiment.

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?

Implied usage for Korean crypto sentiment analysis but lacks explicit guidance on when to use versus alternatives or when not to use. No discussion of prerequisites or exclusions.

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?

Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing detection of rapid price movements and volume spikes, but does not contradict annotations. Payment and pricing info is provided, which is useful 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?

The description is informative but includes extraneous payment/pricing details that could be moved to a separate metadata field. The core functionality is front-loaded, but overall length could be reduced.

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 parameters and an existing output schema, the description adequately covers what movers are detected and the underlying rationale. It does not explain output format, but that is handled by the schema.

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 baseline is 4. The description explains the scope (1-minute, >1%, top 20) which adds meaning beyond the empty 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 states the tool retrieves Korean market movers: 1-minute price surges/crashes (>1%), volume spikes, and top 20 tokens by volume on Upbit. It uses specific verbs and resources, effectively distinguishing it from sibling tools that focus on specific indicators like kimchi premium or news.

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 as an early signal for traders due to Korean retail activity, but does not explicitly state when to use this tool versus alternatives like get_kimchi_premium or get_kr_prices. No direct comparisons or exclusions are provided.

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?

The description adds critical behavioral context beyond annotations: it discloses the per-call cost ($0.10 USDC), payment method (x402), and required client SDKs. Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict.

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 front-loaded with purpose and components, followed by output and payment details. Every sentence adds value, though it could be slightly more concise. The structure is logical and readable.

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 zero parameters, presence of output schema, and annotations, the description adequately covers what the tool does, what it returns, and payment requirements. It does not mention limitations or error handling, but it is sufficiently complete for an agent to decide to call it.

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 schema coverage is 100%. Per the guidelines, baseline is 4. No parameter information is needed, and the description does not repeat schema details.

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 provides AI-powered Korean crypto market analysis, listing specific components and output (signal, confidence, summary, raw data). It distinguishes from sibling tools like get_kimchi_premium or get_stablecoin_premium by being an aggregate analysis tool.

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 does not explicitly state when to use this tool versus alternatives, such as individual indicator tools. The purpose is implied through the list of components, but no when-not or alternative guidance is provided.

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?

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: pricing ($0.001 per call), payment method (x402 micropayment), supported chains (Base, Polygon, Solana), and documentation link. No contradiction with annotations.

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?

Description is front-loaded with core purpose, followed by a helpful explanation and then payment details in a structured list. While a bit long, the emojis and bullet points aid readability; only minor redundancy (e.g., repeating 'x402').

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 parameters and existence of output schema, the description covers interpretation of results and payment requirements. It distinguishes from 'Kimchi Premium' but does not reference other sibling tools like get_kr_prices or get_market_movers, leaving some context implicit.

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?

Input schema has zero parameters and schema coverage is 100%. Per calibration rules, baseline is 4. The description does not need to add parameter info since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves USDT/USDC premium on Korean exchanges vs USD/KRW rate. It explains the meaning of positive/negative premium and distinguishes itself from the 'Kimchi Premium' sibling tool, thus fulfilling specific verb+resource+differentiation.

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 context by stating it's a key indicator of Korean market fund flow direction and separate from Kimchi Premium. However, it does not explicitly list when to use vs. alternatives or provide exclusion criteria.

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