Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

LiqMap: estimated liquidation clusters with real prints overlaid

get_liqmap
Read-only

Retrieve modeled liquidation levels, zone aggregates, and real liquidation prints for a perpetual symbol to see where leveraged longs and shorts get liquidated and read the liquidation heatmap.

Instructions

Call this when the user asks where liquidation clusters or liquidity pools sit for a perpetual, where leveraged longs/shorts would get liquidated, or for a liquidation heatmap reading. Returns the LiqMap snapshot for one symbol: modeled liquidation levels by price, zone aggregates and real liquidation prints from every liquidation venue ByKaranteli counts (listed on bykaranteli.com/coverage). On the Free plan the 24h view; on Builder and higher plans every timeframe from 1h to 30d. By default the 30 real levels nearest the price and the 30 largest real prints; pass detail "full" for all of them. Pass detail "compact" for a shorter page or "full" for the whole answer.

Input Schema

NameRequiredDescriptionDefault
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.
symbolNoSymbol like BTCUSDT (bare BTC accepted). Default BTCUSDT.
timeframeNoModel window. Default 24h, the only one on the Free plan; Builder and higher plans get every window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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 / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "enum": [
+      "compact",
+      "full"
+    ],
+    "type": "string"
+  }
+]
    • changedInput schema / properties / detail / description
      Previous value: -"Optional. true: every real level and every real print (default false: the 30 nearest levels, the 30 newest prints)."New value: +"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."
    • removedInput schema / properties / detail / type
      Removed value: -"boolean"
  2. Changed2 schema fields changedv0.36.0
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Optional. true: every real level and every real print (default false: the 30 nearest levels, the 30 newest prints).",
+  "type": "boolean"
+}
    • changedInput schema / properties / timeframe / description
      Previous value: -"Model window. Default 24h, the only one served without a Builder or higher key."New value: +"Model window. Default 24h, the only one on the Free plan; Builder and higher plans get every window."
  3. Changed1 schema field changedv0.27.2
    • addedInput schema / properties / timeframe
      Added value: +{
+  "description": "Model window. Default 24h, the only one served without a Builder or higher key.",
+  "enum": [
+    "1h",
+    "4h",
+    "12h",
+    "24h",
+    "3d",
+    "1w",
+    "30d"
+  ],
+  "type": "string"
+}
  4. Addedv0.9.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnly and open-world behavior. The description adds valuable context beyond that: plan-based timeframe access, default capping to the 30 nearest levels and 30 largest prints, and what detail modes change.

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 front-loaded with the invocation trigger and return summary, then adds plan and detail behavior. It is somewhat repetitive with the schema around detail modes, but the repetition is functional rather than noisy.

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 read-only, open-world analytics tool with no output schema, it explains when to use it, what the response contains, plan limitations, default truncation, and detail-mode behavior. An agent has enough context to invoke it correctly.

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 the schema already explains detail, symbol, and timeframe. The description still adds useful default-output semantics, notably the 30 levels / 30 prints cap and how detail full or compact alters the result.

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 operation and resource: returns a LiqMap snapshot with modeled liquidation levels, zone aggregates, and real liquidation prints. It clearly distinguishes this from generic liquidation-list siblings by naming clusters/heatmap and one-symbol scope.

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?

Gives explicit user-intent triggers such as where liquidation clusters sit, where leveraged longs/shorts would be liquidated, or reading a liquidation heatmap. It does not explicitly compare against siblings like get_liquidations or get_liquidation_cascades, so it stops short of full routing guidance.

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