kr-crypto-intelligence

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.4
Disambiguation5/5
Every tool has a clearly distinct purpose, from health check to specific premium types, arbitrage scanning, and separate news categories. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, mostly starting with 'get_', except 'check_health'. The naming is predictable and clear.
Tool Count5/5
17 tools is well-scoped for a comprehensive Korean crypto intelligence service, covering prices, premiums, arbitrage, news, sentiment, and alerts without being overwhelming.
Completeness5/5
The tool set covers the major aspects of Korean crypto market intelligence: prices, multiple premium metrics, arbitrage, market movers, sentiment, alerts, news, and exchange rate. No obvious gaps for its stated purpose.
Average 4.1/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on April 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint and openWorldHint. The description adds valuable context: 1-hour cache, returns sentiment label, score, English report, exchange signals, news context. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy with payment details and docs URL included. While clear and front-loaded, it could be more concise by separating business details from core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining multiple data sources) and presence of an output schema, the description adequately covers what the tool does and returns. The cache mention is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to explain params. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Korean crypto market sentiment in English, combining exchange intelligence and Korean news. It distinguishes from siblings like get_kr_news_kpop and get_kimchi_premium by focusing on sentiment analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (Korean market real-time insights) but does not explicitly state when to use vs alternatives or exclude other tools. No contrast with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds that the tool is free ('no x402 payment required'), which is useful behavioral context. However, it doesn't disclose other traits like data freshness or rate limits. Given annotation coverage, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, each adding value. It is front-loaded with purpose, then specifics about exchanges, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description covers the essential: what it returns (symbols from specific exchanges) and why to use it. It could mention that the list may change, but for a read-only free tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter info. It correctly omits parameter details, as there are none. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'available trading symbols on Korean exchanges', specifying Upbit, Bithumb, and common symbols. This distinctly defines its purpose and differentiates 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check which symbols you can query before calling other tools', providing clear context for when to use it. It could improve by mentioning when not to use it or naming alternatives, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds behavioral traits: payment via x402 micropayment on specific chains, detection of rapid price movements and unusual volume. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, including payment details and a docs link that are not strictly about tool behavior. While informative, it could be more front-loaded and eliminate non-essential info to improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, annotations for read-only and open world, and presence of an output schema, the description fairly covers what the tool does and its value. It lacks details on output format or pagination, but overall is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add parameter meaning. Baseline 4 is appropriate since schema coverage is 100% and no params exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets Korean market movers, including specific metrics (price surges/crashes >1%, volume spikes, top 20 tokens by volume on Upbit). This differentiates it from sibling tools like get_kr_prices or get_kr_sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use: 'Korean retail activity often leads global price movements — early signal for traders.' It implies when to use but does not explicitly exclude scenarios or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it uses multiple data sources, returns AI-generated output, and includes pricing/payment details (x402 micropayment). This goes beyond annotations which only indicate read-only and open-world.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy due to pricing details, but well-structured: purpose first, then indicators, output, and payment. Could be slightly more concise but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's purpose, inputs (none), outputs (listed), and usage constraints (pricing). With an output schema present, there's no gap in understanding return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description adds context about the output structure but doesn't need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's an AI-powered Korean crypto market analysis, listing specific indicators and what it returns (signal, confidence, summary, raw data). Distinguishes from sibling tools like get_kimchi_premium and get_fx_rate which focus on individual metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use this tool vs alternatives like get_kimchi_premium or get_global_vs_korea_divergence. The description implies it for comprehensive analysis but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, indicating safe read-only behavior. The description adds that it returns status of specific exchanges and that it is free (no payment). This provides useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a pricing line. No wasted words; front-loaded with key information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description adequately covers the tool's purpose and what it checks. No additional information needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (100% schema coverage). Baseline score of 4 applies as no parameter explanation is needed. The description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 connectivity of Upbit, Bithumb, and Binance APIs. The verb 'check' and specific resources distinguish it from sibling tools that retrieve data like arbitrage or prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. However, the purpose is self-evident as a health check tool, distinct from data retrieval siblings. Implicit usage, but no when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds behavioral details beyond annotations: detection types, polling frequency (60 seconds), and payment integration (x402 micropayment). No contradictions. The description enriches the tool's behavior understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the amount of information conveyed. It is well-structured with key purpose first, then technical details, then payment info. Minor redundancy (e.g., 'Get Korean exchange alerts' in the first line and later details), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema (presumed to document return details), the description covers all necessary context: what alerts are detected, how detection works (comparison every 60 seconds), and practical usage (payment, docs). It fully equips an agent to decide when and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The description does not need to add parameter details. It provides context for what the tool returns (alert types) and operational details (payment, docs). Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Korean exchange alerts including new listings, delistings, investment warnings, and caution flags. It specifies the types of alerts detected (INVESTMENT_WARNING, PRICE_FLUCTUATIONS, etc.) and how detections work (comparing market lists every 60 seconds). This is specific and distinct from sibling tools, which focus on prices, news, or divergence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is critical for risk management and early listing detection, indicating when to use it. It does not provide explicit exclusions or alternatives, but the context of sibling tools (prices, news, etc.) naturally suggests this is the go-to for alerts. Slightly lacking in when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds valuable behavioral context: pricing, payment method, and a documentation link. This discloses cost and client requirements, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence followed by four bullet points listing price, payment, client, and docs. Every sentence adds unique value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema exists, and annotations cover safety, the description is complete. It explains the tool's purpose, cost, and required client, which suffices for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers all (100%). The description adds no parameter info, but as per guidelines, 0 parameters yields a baseline of 4. The description still provides purpose and payment context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get current USD/KRW exchange rate' and specifies its use for converting between Korean Won and US Dollar prices. This is a specific verb+resource and distinguishes it from sibling tools that focus on arbitrage, news, sentiment, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on usage: it costs $0.001 USDC per call, uses x402 micropayment, and lists compatible clients and docs. However, it lacks explicit 'when to use' vs 'when not to use' instructions, though the purpose is inherently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds significant behavioral details: updates every 60 seconds, warning flags, volume/deposit soaring alerts, and the types of calculations performed. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but includes extra information about pricing and payment methods which, while useful, makes it longer than necessary for a no-parameter tool. It is well-structured with emojis for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, the description is complete. It explains the return values comprehensively (premium %, reverse premiums, gaps, market share, flags, alerts) and specifies the update interval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds rich context about the output, including premium percentages, gaps, flags, and alerts, which helps the agent understand what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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+) traded on both Upbit and Binance, returning detailed metrics for arbitrage analysis. It distinguishes itself from siblings like get_kimchi_premium by mentioning coverage of all tokens and additional data points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides use for cross-exchange arbitrage analysis by listing relevant metrics and update frequency. It does not explicitly state when not to use or name alternatives, but context from sibling tools helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kr-crypto-intelligence MCP server](https://glama.ai/mcp/servers/bakyang2/kr-crypto-intelligence/badges/card.svg)](https://glama.ai/mcp/servers/bakyang2/kr-crypto-intelligence)

Score Badge

Copy to your README.md:

[![kr-crypto-intelligence MCP server](https://glama.ai/mcp/servers/bakyang2/kr-crypto-intelligence/badges/score.svg)](https://glama.ai/mcp/servers/bakyang2/kr-crypto-intelligence)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bakyang2/kr-crypto-intelligence'

If you have feedback or need assistance with the MCP directory API, please join our Discord server