Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Withdrawal status and network fees: which exchanges paused withdrawals, per asset and network

get_withdrawal_status
Read-only

Check whether exchange withdrawals or deposits are paused, compare withdrawal fees and minimums per network, and find the cheapest venue to withdraw from.

Instructions

Call this when the user asks whether an exchange has paused withdrawals or deposits, which networks are open for an asset, what the withdrawal fee or minimum is on each venue, or which venue is cheapest to withdraw from. Without arguments returns the overview (withdrawals paused right now, ranked, plus recent suspension and resumption events). Pass asset (e.g. USDT) for every venue and network of that asset, and venue (e.g. kucoin) to narrow. Recorded daily by ByKaranteli from 20+ venues' public currency lists. The overview lists the first 30 paused networks and the 30 newest events; pass asset, or limit (up to 400) for more.

Input Schema

NameRequiredDescriptionDefault
assetNostring, optional asset code, e.g. USDT
limitNoOptional. Rows of the overview lists (paused networks, events) without asset (default 30).
venueNostring, optional venue id, e.g. kucoin

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
  2. Changed1 schema field changedv0.36.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Optional. Rows of the overview lists (paused networks, events) without asset (default 30).",
+  "maximum": 400,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv0.27.2

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses provenance and freshness ('recorded daily by ByKaranteli from 20+ venues' public currency lists') and, importantly, result truncation ('first 30 paused networks and the 30 newest events', limit up to 400). Those caps are the kind of behavior an agent must know to avoid misreporting completeness.

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 the invocation triggers, then argument behavior, then provenance and pagination limits — a sensible order with no filler sentences. The opening sentence is long and trigger-dense, slightly taxing to parse, but nothing is redundant.

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?

There is no output schema, and the description compensates by describing the shape of the return (paused withdrawals ranked now, plus recent suspension and resumption events) and the truncation rules. An agent has everything needed to call it and to interpret result coverage.

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, but the description adds real meaning: asset expands to every venue and network of that asset, venue narrows the result, and limit applies only to the overview lists when no asset is given. That last scoping detail is a genuine complement to the schema text.

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 and set of questions it answers: withdrawal/deposit pauses per exchange, open networks per asset, fees and minimums per venue. This clearly separates it from lookalikes such as get_fee_table, get_network_health and get_venue_markets, so an agent can pick it 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 lead sentence gives concrete user-question triggers ('whether an exchange has paused withdrawals', 'which venue is cheapest to withdraw from') and explains the argument-driven modes (no args = overview, asset = per-venue/network, venue = narrow). What's missing is an explicit exclusion or a named alternative for overlapping needs like generic fee tables.

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