alphapipeline

market.kimchi_alert

Read-only

Use this tool when evaluating Korean exchange price premiums, the 'kimchi premium', Upbit price gaps vs a global reference price, cross-border crypto arbitrage, or sudden Korea-specific price anomalies. Real-time Upbit vs Coinbase spot (CoinGecko fallback) - NOT a live Binance orderbook, despite the legacy binance_price_usdt field name kept for backward compatibility - with reverse-premium and surge alerts. Do not use for general USD spot prices or on-chain DEX swaps. Paid in USDC on Base (free while KIMCHI_ALERT_ENABLED=false).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "market.kimchi_alert"
  }
}

Input Schema

Name	Required	Description	Default
`symbol`	No	Crypto ticker symbol to check, e.g. BTC, ETH, SOL. Defaults to BTC.

Output Schema

Name	Required	Description
`alerts`	Yes
`notice`	No
`symbol`	Yes
`thresholds`	Yes
`generated_at`	Yes
`upbit_price_krw`	Yes
`cex_price_source`	No
`binance_price_usdt`	Yes	Legacy field name kept for backward compatibility - NOT a live Binance price, see notice/cex_price_source.
`kimchi_premium_pct`	Yes
`usdkrw_rate_estimate`	Yes
`premium_change_1h_pct`	Yes
`cex_reference_price_usdt`	No	Same value as binance_price_usdt under an honestly-named field.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 18, 2026

addedOutput schema / properties / binance_price_usdt / description

Added value: +"Legacy field name kept for backward compatibility - NOT a live Binance price, see notice/cex_price_source."

addedOutput schema / properties / cex_price_source
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / cex_reference_price_usdt

Added value: +{
+  "description": "Same value as binance_price_usdt under an honestly-named field.",
+  "type": "number"
+}

addedOutput schema / properties / notice
```
Added value: +{
+  "type": "string"
+}
```

First observedSep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only state readOnlyHint and destructiveHint. The description goes far beyond that by disclosing the real-time data sources (Upbit vs Coinbase with CoinGecko fallback), explicitly warning it is NOT a live Binance orderbook despite the legacy field name, mentioning reverse-premium and surge alerts, and stating the payment model (USDC on Base, free while flag is false). This is rich behavioral context that helps the agent set expectations.

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 dense but efficient, using multiple clauses to pack critical information without fluff. It leads with the usage context, then details data source, alerts, and payment. It is slightly long but every sentence contributes value, and the structure is logical.

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 complexity (arbitrage, multiple alerts, payment, data sources), the description covers all essential aspects: when to use, data sources, fallback, exclusions, and cost. An output schema exists, so return-value details are not needed. Nothing an agent requires to decide whether to call it and what to expect is missing.

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?

The only parameter (symbol) has full schema coverage (100%) with its own description, so the baseline is 3. The tool description adds only a default value (BTC) but no additional semantic nuance beyond what the schema provides. It does not explain symbol format or edge cases, but the schema covers it adequately.

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 opens with a precise verb-resource pair: 'evaluating Korean exchange price premiums,' and enumerates specific use cases (kimchi premium, Upbit vs global reference, arbitrage, Korea-specific anomalies). It explicitly distinguishes itself from a Binance orderbook and general spot prices, which differentiates it from siblings like arb.spread_matrix or derivatives.funding_rate.

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 when-to-use guidance ('Use this tool when evaluating...') and explicit exclusions ('Do not use for general USD spot prices or on-chain DEX swaps'). It does not name a specific alternative tool, but the when-not cases are stated unambiguously, which is sufficient for routing.

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

All alphapipeline tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.