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

The description adds value beyond the readOnlyHint and openWorldHint annotations by specifying the exact exchanges covered and noting the tool is free (no x402 payment required). It does not discuss rate limits or auth, but output schema exists and the annotations cover the safety profile, so the added context is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences front-load the action and scope. The price note is a single short clause with an emoji, adding useful info without bloat. No wasted words.

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

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

For a zero-parameter, read-only health check with an output schema and annotations, the description covers all necessary context: what it does, which connections are checked, and cost. There are no missing inputs or behavioral gaps.

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

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

The tool has zero parameters, so there is nothing to explain. The baseline for 0 params is 4; the description appropriately focuses on behavior rather than parameter 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?

Description uses a specific verb 'Check' and clearly identifies the resource as 'service health and exchange connectivity status', naming concrete exchanges (Upbit, Bithumb, Binance). This distinguishes it from sibling tools which focus on market data, arbitrage, 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 a health-check use case but does not explicitly state when to prefer this tool over alternatives or provide exclusions. Its unique scope is obvious relative to siblings, but without direct guidance the agent must infer when to invoke it.

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=true and openWorldHint=true. The description adds valuable context by stating it updates every 60 seconds, returns reverse premiums, and includes pricing/payment details. It does not contradict annotations and contributes practical operational transparency beyond safe-read status.

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 functional but slightly lengthy, with a clear split between functional details and payment/docs info. Every sentence contributes value, and the use of line breaks and emojis improves readability, though it could be trimmed without losing core meaning.

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?

Despite having an output schema, the description provides a rich, self-contained overview of the returned data (premium %, reverse premiums, gaps, flags, alerts) and practical usage context (price, payment, clients, docs). It is fully sufficient for an agent to decide whether and how to invoke this zero-parameter 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, so the baseline is 4. The description provides a thorough overview of what the scanner returns without needing to explain parameters, which is consistent with the empty input 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 scans Kimchi Premium for all tokens (180+) on Upbit and Binance, returning premium percentages, price gaps, and alerts. It uses a specific verb ('Scan') and resource ('Kimchi Premium') and distinguishes itself from sibling tools like get_kimchi_premium by emphasizing cross-exchange arbitrage 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 gives clear context: 'Essential for cross-exchange arbitrage analysis.' It explicitly tells when to use it (for arbitrage analysis) but does not mention when not to use it or directly name alternative tools, so it falls short of full exclusion guidance.

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 annotations already declare readOnlyHint and openWorldHint, establishing the tool as safe and external. The description adds meaningful context beyond annotations by specifying the exact exchanges covered (Upbit, Bithumb, common) and stating the tool is free of charge, which is useful for agents evaluating cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two clear sentences and a price note. It front-loads the action ('Get all available trading symbols...'), and every sentence contributes value without redundancy.

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 (zero parameters) and the presence of an output schema, the description sufficiently covers purpose, usage context, and return scope. It also includes the pricing detail, which is relevant for other tools in the family.

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 coverage is 100%, so the description carries no parameter burden. The baseline for no parameters is 4, and the description appropriately adds no unnecessary parameter 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 the tool's purpose: retrieving available trading symbols from Korean exchanges, specifically naming Upbit and Bithumb. It distinguishes itself from sibling get_* tools by focusing on symbol availability rather than prices, alerts, 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 explicitly instructs users to use this tool before calling other tools to check which symbols can be queried, providing clear usage context. However, it does not mention when not to use it or name alternatives, but for this generic symbol-listing tool such exclusions are not critical.

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 signal readOnlyHint=true, so behavioral burden is lower. The description adds valuable context: the detection mechanism ('comparing market list changes every 60 seconds'), the specific alert categories detected, and payment requirements ($0.01 USDC per call, x402 payment). This goes beyond annotations without contradicting them.

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 well-structured with a functional summary first, then payment and access details in a clearly separated block. It's slightly longer than necessary because of pricing/client info, but each sentence carries useful information for an agent deciding whether to call 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?

With zero parameters and an output schema present, the description need not explain parameters or return values. It fully covers what the tool detects, how detection works (60-second polling), and the cost/access requirements, making it complete for an agent 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?

The tool has zero parameters, so the schema provides no meaning to add. The description compensates by explaining what the tool does when invoked, satisfying the baseline for zero-param tools.

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 'Get Korean exchange alerts' and enumerates specific alert types (new listings, delistings, investment warnings, caution flags). This specific verb+resource combination distinguishes it 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?

It notes 'Critical for risk management and early listing detection,' providing clear use context. However, it does not explicitly compare to alternatives or state when not to use it, so it lacks the explicit exclusion found in top-tier examples.

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=true and openWorldHint=true, covering safety. The description adds behavioral context beyond that by specifying the cost ($0.001 USDC), the x402 payment requirement, supported blockchains, and client SDKs. This is useful disclosure of operational constraints.

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 the main purpose, then provides essential operational details in a structured list. The payment and docs lines are relevant and earn their place, though the emoji-heavy formatting adds minor noise.

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 zero-parameter tool with an output schema and read-only annotations, the description covers the core purpose, conversion use case, payment model, client options, and documentation link. It is sufficiently complete for an agent to select 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?

The tool has zero parameters, so the baseline is 4. The description adds meaning by clarifying the output is a rate for converting KRW/USD, which is helpful for understanding what the tool returns. No parameter documentation is needed.

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

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

The description starts with 'Get current USD/KRW exchange rate', which is a specific verb+resource combination. It clearly distinguishes this tool from siblings like get_kimchi_premium or get_kr_prices by focusing on the currency pair, and adds the conversion use case.

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 states 'Essential for converting between Korean Won and US Dollar prices', providing clear context for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, so it misses the 'explicit exclusions' bar.

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?

Discloses 60s cache, pricing ($0.05), payment method (x402), and return fields (prices, divergence, context_signals, ai_interpretation). No contradiction with annotations. Provides significant value 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?

Front-loaded with purpose, then structured with bullet points and emojis. Some extra info (pricing, docs) could be considered clutter but still clear and scannable.

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 output structure, cache, pricing, and payment. Output schema exists. Missing error handling or rate limits, but overall sufficient for agent invocation given annotations and 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?

Schema coverage is 100% with a detailed description of symbol parameter listing 25 cryptos. The description adds no further parameter meaning beyond '25 supported symbols'. 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 computes the premium between CoinGecko global and Upbit Korean prices, with AI interpretation. It specifies 'Light tier' distinguishing it from the deep variant sibling. Verb and resource are specific.

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

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

No explicit guidance on when to use this vs the deep version or other siblings. 'Light tier' implies a choice but no criteria 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?

Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral traits: 5-minute cache, $0.10 per call cost, and x402 micropayment requirement. It also outlines return fields (light response plus news signal and AI analysis). 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 relatively long and includes payment/pricing details that may not be essential for tool selection. While the first sentence is clear, the additional implementation details add clutter. It is not optimally 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 existence of an output schema and the complexity of the tool (deep analysis with news and AI), the description covers purpose, output structure, caching, and payment. It assumes some domain knowledge about 'light data' but is mostly complete.

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

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

Schema description coverage is 100% with a detailed list of accepted symbols. The tool description does not add further meaning beyond the schema, but it provides context that the symbol is used for divergence analysis with Korean news. 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 'Deep tier' and specifies the combination of light data, Korean news signals, and structured AI breakdown. It distinguishes itself from the sibling tool 'get_global_vs_korea_divergence' by implying a deeper analysis.

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

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

No guidance on when to use this tool versus alternatives. The description mentions 'deep tier' but fails to specify when not to use it or provide explicit context for selecting this over the lighter version. No exclusions or alternatives are mentioned.

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=true and openWorldHint=true, indicating a safe read operation. The description adds value by disclosing pricing, payment method, and return fields. No contradictions, and it enriches the behavioral context 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?

The description includes useful but somewhat verbose details (pricing, payment, docs link). It is structured with bullet points but could be more concise by moving some payment details elsewhere. Still informative.

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 optional parameter), the description is remarkably complete: it explains the concept, lists all return fields, and provides payment and documentation links. No output schema is provided, but the description fully covers 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?

With 100% schema coverage, the parameter (symbol) is well-documented in the schema. The description only adds an example (BTC) and slight context, but does not significantly enhance 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 tool's purpose: retrieving the real-time Kimchi Premium, defined as the price difference between Korean and global exchanges. It provides context (South Korea's trading volume) and distinctively focuses on this specific metric, differentiating it from siblings like get_global_vs_korea_divergence.

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 on what the tool returns but does not explicitly state when to use it versus alternatives like get_stablecoin_premium or get_global_vs_korea_divergence. Usage is implied for Kimchi Premium queries, but no exclusions or 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 include readOnlyHint and openWorldHint, and the description adds behavioral details: '5-min cache,' payment info ($0.01 per call, x402 micropayment), and return structure. 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 moderately concise, with first sentence stating main purpose, then additional context (caching, payment, docs). Could be slightly more concise but effective overall.

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 is simple with one parameter and an output schema exists, the description explains return fields and caching. Payment details are included. No major gaps for a read-only news 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?

Only one parameter 'limit' with schema description 'Number of articles to return (1-10)' covering 100%. The description adds no further semantics beyond the schema, so baseline score 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 retrieves Korean K-pop news aggregated from Naver, translated to English, with AI relevance classification, and specifies the types of news (artists, groups, etc.). It distinguishes 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 provides usage context: 'Korean entertainment news often moves global fan markets before English coverage,' implying when to use for early K-pop news. However, it does not explicitly state when not to use or compare with alternatives 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?

Annotations already indicate readOnlyHint and openWorldHint. The description adds value by specifying a 5-minute cache, pricing details, payment methods, return structure, and that it uses the same articles as get_kr_news_kpop. 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 has a clear first sentence but includes detailed pricing/payment bullet points that might be better placed elsewhere. It is functional but could be more concise; every sentence earns its place but the payment info is peripheral.

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, multiple return fields) and that an output schema exists, the description covers core functionality, cache, pricing, and return fields. It is sufficiently complete for a single-parameter tool.

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

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

Schema coverage is 100% with the only parameter 'limit' described in the schema. The description does not add extra parameter semantics, but baseline is 3 when schema covers parameters. No additional guidance 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 provides Korean K-pop news with an AI analysis layer, listing specific components like overall_sentiment, key_themes, trending_entities, and summary. It explicitly distinguishes itself from the sibling tool get_kr_news_kpop by noting the added AI analysis.

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 AI analysis is desired over raw news, referencing the sibling tool without AI. However, it lacks explicit guidance on when not to use, prerequisites like wallet setup, or alternatives beyond the one sibling.

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 provide readOnlyHint (safe read) and openWorldHint. Description adds useful behavioral context: 5-min cache, payment requirements (x402), and output structure. No contradictions. Some omissions like rate limits or error states, but net positive.

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?

Efficient: two distinct sections (core functionality then payment/docs). Bullet points aid scanning. Could trim payment details into a note, but overall compact and front-loaded.

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

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

Given output schema exists, return info in description is supplementary, not required. Caching, payment, and source details covered. No output schema details needed. Minor gaps (no error handling) but adequate for complexity.

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 covers the single parameter 'limit' fully (description, min, max, default). Description adds no new info beyond that. Baseline 3 is appropriate given 100% 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?

Clear verb+resource: 'get' 'Korean semiconductor industry news', specifies aggregation source (Naver), translation, and covered topics (Samsung, SK Hynix, etc.). Distinguished from siblings like get_kr_news_kpop and get_kr_news_semiconductor_summary by explicit domain and output detail.

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

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

Implied usage via mention of 'global semiconductor supply-chain signals', but no explicit when-to-use vs. siblings (e.g., summary vs. full news). No exclusions or alternatives 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?

Annotations already provide readOnlyHint=true, so the agent knows it's a read operation. The description adds a '5-min cache' behavioral trait, which is useful. Payment details are not behavioral so they don't add to transparency 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?

The description includes payment information and a docs link, which are not directly about the tool's functionality. While structured, it could be more concise by separating functional from non-functional 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 simplicity (one parameter, no nested objects, output schema exists), the description covers purpose, sibling differentiation, and cache behavior. It is complete enough for an agent to use 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 has 100% coverage for the single parameter 'limit' with min, max, default, and description. The description does not add additional meaning beyond what the schema provides, so 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 uses the verb 'get' with resource 'kr_news_semiconductor_summary' and clearly states it returns articles plus AI analysis. It explicitly differentiates from sibling 'get_kr_news_semiconductor' by noting the added AI layer, providing excellent distinction.

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 indicates when to use this tool (when AI analysis is desired) versus its sibling (raw articles). It does not include when-not-to-use or alternatives beyond the sibling, but the context 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 already declare readOnlyHint=true and openWorldHint=true. The description adds value by specifying the data returned (prices, volume, change) and noting the payment model (x402 micropayment), which is beyond annotations. No 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 well-structured and front-loaded with the tool's core purpose. However, the payment details (cost, client, docs) are extraneous for an AI agent's tool selection, adding unnecessary length.

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 (not shown but indicated) and clear annotations, the description provides adequate context for the tool's functionality. The payment info is extra but not detrimental.

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 is 3. The description adds context by listing output fields (prices, volume, change), which indirectly clarifies parameter purposes. It also mentions the payment aspect, but that's not parameter-specific.

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 cryptocurrency prices from specific Korean exchanges (Upbit, Bithumb) and returns KRW-denominated data, including volume and change rate. This verb+resource+scope effectively distinguishes it from sibling tools like get_kimchi_premium or get_fx_rate.

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 querying Korean exchange prices but does not explicitly state when to use versus alternatives (e.g., get_market_read for broader market info). No when-not or exclusion 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?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral context: it discloses a 1-hour cache, the cost per call ($0.05 USDC), payment methods (x402 on Base/Polygon/Solana), and a documentation link. This is valuable transparency about operational aspects, though it does not cover rate limits 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 core description is efficiently written in three sentences, front-loading the purpose and outputs. The additional pricing/payment block is somewhat promotional but includes essential operational information, so it earns its place. Slight overuse of superlatives like 'First-in-world' and 'AI-powered' adds minor fluff.

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 zero parameters and an output schema, the description is contextually complete. It covers the tool's purpose, data sources, output structure, cache behavior, cost, and payment method. The documentation link further supplements implementation details, making this a well-rounded description for an AI agent.

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

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

The input schema has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameters, and any potential semantic meaning is irrelevant since no parameters exist. The description adds no parameter info, but that is fine given the schema's completeness.

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

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

The description clearly states the tool's function: Korean crypto market sentiment analysis in English, combining exchange intelligence and Korean news context. It also enumerates specific outputs (sentiment label, score, English report, exchange signals, news context), making its purpose unmistakable and distinguishing it from sibling tools that focus on raw metrics like kimchi premium or price 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 implies usage context by detailing the combined data sources (exchange intelligence + Korean news) and positioning it as a unique sentiment API, but it does not explicitly specify when to use this tool over alternatives or provide exclusions. There is no mention of sibling tools or conditions that would favor another option.

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 indicate readOnly and openWorld, but the description adds significant behavioral details beyond them: exact thresholds (1-minute, >1%), the focus on volume spikes and top 20 tokens, and crucially, the monetization (cost per call, payment methods, required x402 SDK). This goes well beyond what annotations provide, with no 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 core functionality is front-loaded in the first sentence and the following two sentences add useful context. However, the payment metadata (4 lines with emojis) is somewhat verbose and could potentially be condensed or moved to a separate metadata field, though it is structured and informative.

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-param read-only tool with an output schema, the description is comprehensive: it specifies the exchange (Upbit), time window (1-minute), criteria (>1%, volume spikes, top 20), and the monetization model. It fully equips an agent to select and invoke the tool 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?

The tool has 0 parameters, and the schema coverage is trivially 100%. Per rubric, baseline is 4 for 0-param tools. The description correctly adds no parameter information; it's unnecessary.

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

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

The description clearly states the tool's purpose: 'Get Korean market movers' with precise criteria (1-minute price surges/crashes >1%, volume spikes, top 20 tokens by trading volume on Upbit). This specific verb+resource+metric set distinguishes 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 provides clear context: 'Korean retail activity often leads global price movements — early signal for traders.' This implies when to use the tool (for early trading signals) but does not explicitly mention alternatives or when not to use it, preventing 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?

The description adds substantial behavioral context beyond the annotations, including the $0.10 USDC per call cost, x402 payment requirement, supported clients, and documentation URL. It also clarifies the read-only nature by describing outputs rather than side effects, consistent with readOnlyHint and openWorldHint.

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 well-structured, leading with the tool's purpose and then providing concise bullet points for payment, client, and docs. Every sentence adds useful information with no 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?

Despite the tool's complexity, the description covers the input (none), the data sources, the output shape, and the commercial/payment requirements. With an output schema present and no parameters, the description fully equips an agent to decide when and how to invoke 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 the schema is complete and there is no parameter ambiguity. The description adds no parameter details, but none are needed, so the baseline of 4 is appropriate.

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

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

The description clearly states the tool provides AI-powered Korean crypto market analysis by combining multiple indicators, and it explicitly lists the output (BULLISH/BEARISH/NEUTRAL signal, confidence score, summary, raw data). This distinguishes it from sibling tools like get_kimchi_premium or get_fx_rate, which cover individual 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 establishes a clear use case: holistic Korean crypto market analysis with an AI-generated consensus signal. It implies this tool is for when a broad market read is needed rather than individual indicator data, though it does not explicitly name alternative tools or state 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?

Beyond annotations (readOnlyHint, openWorldHint), the description adds critical behavioral traits: payment method (x402 micropayment), supported chains, client SDKs, and a link to documentation. It also explains the economic interpretation of the output.

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 some extraneous details (e.g., emoji, price/micropayment specifics) that could be streamlined. However, it is well-structured with bullet points and front-loaded with the core 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?

Given zero parameters and an existing output schema, the description completely explains the tool's purpose, interpretation of results, payment requirements, and references. No gaps remain.

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

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

There are no parameters, so the description naturally adds no parameter info. Baseline of 4 applies as no additional semantic value is needed 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 explicitly states 'Get USDT and USDC premium on Korean exchanges vs official USD/KRW rate' and distinguishes itself from Kimchi Premium, making the purpose clear and differentiated from siblings like 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?

It explains the indicator's meaning (positive/negative premium indicating capital flow) and separates it from Kimchi Premium, but does not explicitly mention when not to use it or alternative tools.

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