Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Options walls, gamma exposure and DVOL (BTC + ETH)

get_options_snapshot
Read-only

Get a daily snapshot of Bitcoin and Ethereum options chains across venues to identify call/put walls, gamma exposure, zero-gamma level, and implied volatility term structure.

Instructions

Call this when the user asks where the big options bets sit, about call/put walls, gamma exposure (GEX), the zero-gamma level, implied volatility (DVOL) or the IV term structure for Bitcoin or Ethereum, across options venues or on one venue. Daily snapshot of the listed option chains of every options venue we record, summed by default or one venue with venue: the call wall (largest call open interest above spot) and put wall (largest put open interest below spot), the largest bars on the whole axis, top strikes by open interest, put/call ratio, dealer hedging map, ATM IV by expiry (calls and puts interpolated at the money, iv_source names the venue whose quotes price the chain), each venue's open interest (venues_included), and per expiry the open interest by side, the max pain strike (where the open contracts as a group pay out the least at settlement, not a price target) and the one-sigma implied move the ATM IV prices (expiries). DVOL is Deribit's index whatever the venue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
venueNoall (default) sums every options venue; or one venue id: deribit, bybit, binance, okx or delta (Delta Exchange India).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.29.0
    • addedInput schema / properties / venue
      Added value: +{
+  "description": "all (default) sums every options venue; or one venue id: deribit, bybit, binance, okx or delta (Delta Exchange India).",
+  "enum": [
+    "all",
+    "deribit",
+    "bybit",
+    "binance",
+    "okx",
+    "delta"
+  ],
+  "type": "string"
+}
  2. First observedv0.5.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely new behavioral context: the snapshot is daily, venue aggregation is summed by default, and 'DVOL is Deribit's index whatever the venue' clarifies a surprising cross-venue behavior. It also warns that max pain is 'not a price target', which pre-empts misreading. It stops short of stating latency, rate limits, or freshness guarantees.

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 trigger sentence is correctly front-loaded, but the remainder is one sprawling clause chain of output fields separated by commas and em-dashes, which is hard to scan and mixes several distinct concepts (walls, dealer map, iv_source, max pain, expiries) in a single breath. Every item is arguably useful, but the structure costs 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?

There is no output schema, so the description carries the full burden of describing return content, and it does so exhaustively: walls, top strikes, put/call ratio, hedging map, ATM IV by expiry, venues_included, per-expiry OI by side, max pain and one-sigma implied move. An agent knows what it will receive before calling.

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?

With one parameter at 100% schema coverage the baseline is 3, and the description exceeds it by explaining that 'all' sums every venue while passing a venue id narrows the aggregation, plus the non-obvious caveat that the venue choice does not change DVOL. That is real semantic value beyond the enum labels.

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 verb+resource ('daily snapshot of the listed option chains of every options venue we record') and enumerates the exact payload: call/put walls, GEX, zero-gamma level, DVOL, term structure. The 'daily snapshot of open interest across venues' framing implicitly separates it from flow-oriented siblings like get_options_flow and surface-oriented get_iv_surface.

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?

Opens with an explicit trigger set: 'Call this when the user asks where the big options bets sit, about call/put walls, gamma exposure (GEX), the zero-gamma level, implied volatility (DVOL) or the IV term structure for Bitcoin or Ethereum.' Clear context for invocation, but no exclusions or named alternatives, so an agent must still infer when get_iv_surface or get_options_flow is the better pick.

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