Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Turkey Premium Index: what lira buyers pay above the world price, with TRY reference prices from Turkish venues

get_turkey_premium
Read-only

Check the Turkey premium for Bitcoin, Ether or USDT: see whether Turkish exchanges trade above or below the global price, with the live premium index score, regime and per-venue rates.

Instructions

Call this when the user asks about Bitcoin, Ether or USDT prices in Turkish lira, the Turkey premium, the USDT/TRY rate or dollar premium in Turkey, or which Turkish exchanges (BtcTurk, Bitlo, CoinTR, OKX TR, Binance TR, Bybit TR, Bitexen; KuCoin TR contributes the USDT pairs only) trade above or below the global price. Returns the live board: the Turkey Premium Index (what a lira buyer pays for bitcoin against the global dollar price at the official exchange rate, in bps) with its dollar leg and crypto leg, a 0-100 score (50 = world price) and regime, 24h and 7d averages and the same-sign streak; then five reference prices (median of eligible order books), per-venue book status, spread, depth and each venue's implied premium. Pass pair and history_days for 15-minute history of one pair. Without pair, the daily rows cover the last 7 days; pass pair, or daily_days (up to 30) for more. Pass detail "compact" for a shorter page or "full" for the whole answer.

Input Schema

NameRequiredDescriptionDefault
pairNoPair: BTC-TRY, ETH-TRY, USDT-TRY, BTC-USDT or ETH-USDT
detailNoOptional. "compact": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). "full" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page.
daily_daysNoOptional. Days of daily rows, newest first (default 7 without pair, every recorded day with one).
history_daysNoInclude 15-minute index history for the pair, 1..30 days

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Optional. \"compact\": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). \"full\" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page."
+}
  2. Changed1 schema field changedv0.36.0
    • addedInput schema / properties / daily_days
      Added value: +{
+  "description": "Optional. Days of daily rows, newest first (default 7 without pair, every recorded day with one).",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv0.27.2

TDQS

A4.2/5.0
Behavior4/5

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

Goes well beyond the readOnly/openWorld annotations by describing the returned board, the 0-100 score with 50 = world price, 24h/7d averages, streak, five reference prices, per-venue book status and implied premium. It also discloses pagination defaults (7 daily rows without pair) and the 100,000-character ceiling behavior for 'full'. Missing only freshness/caching or rate-limit notes.

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?

Trigger conditions come first, then return shape, then parameter behavior — a sensible front-loading. It is a single dense paragraph with a long parenthetical venue list, but nearly every clause carries information an agent needs.

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 no output schema, the description fully carries the burden of explaining return values: index, legs, score, regime, averages, streak, reference prices, venue status and premium. Pagination and truncation behavior are also covered, leaving nothing material for a caller to guess.

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% and the schema already documents pair enum, daily_days/history_days ranges, and the detail modes. The description adds the relationship that pair plus history_days yields 15-minute history for one pair and that daily_days allows up to 30 days, but repeats much of what the schema says. 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?

States a specific resource (Turkey Premium Index: lira price vs global dollar price in bps) and enumerates the exact user questions it answers, including named Turkish venues. An agent can tell this apart from siblings like get_coinbase_premium or get_venue_markets without opening the schema.

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 opening 'Call this when the user asks about...' clause gives a concrete trigger list covering BTC/ETH/USDT lira prices, the premium, the USDT/TRY rate and venue divergence. It lacks explicit exclusions or a named alternative (e.g. get_coinbase_premium for the US premium), so routing is clear but not fully disambiguated.

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

Deploy Server

Other Tools