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

Retrieve a daily Bitcoin or Ethereum options snapshot with call/put walls, gamma exposure, DVOL, implied volatility term structure, max pain, and open interest, summed across venues or filtered to one venue.

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

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 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.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"
+}
  3. First observedv0.5.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already state readOnlyHint and openWorldHint, so the description correctly focuses on behavior beyond safety: the data is a daily snapshot (not intraday), venues are summed by default, 'DVOL is Deribit's index whatever the venue' is a real caveat, and max pain is flagged as 'not a price target'. These are genuine additions, though there is no coverage of latency, rate limits or data staleness.

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 phrase is well front-loaded, but the second sentence is an enormous run-on that strings a dozen returned fields together with parenthetical explanations. It remains readable, yet the field inventory reads as a data dictionary and would be tighter as a structured list.

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 carries the full burden of explaining return contents, and it does so thoroughly: walls, top OI strikes, put/call ratio, dealer hedging map, ATM IV by expiry with iv_source provenance, venues_included, per-expiry max pain and one-sigma implied move. An agent knows what it will get back before calling.

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 description coverage is 100% and the venue enum is fully documented in the schema. The description only restates the default-summing behavior and the meaning of the venue switch, which slightly clarifies semantics but adds little the schema does not already say.

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 names concrete resources: call/put walls, GEX, zero-gamma level, DVOL, IV term structure, max pain, and per-expiry open interest, framed as a daily aggregated snapshot across venues. That specificity is enough to separate it from chain-level or surface-level siblings such as get_options_chain or get_iv_surface, even though those are not named explicitly.

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 sentence is an explicit trigger list ('call this when the user asks where the big options bets sit, about call/put walls, gamma exposure...'), which gives a clear when-to-use signal. It does not state when NOT to use it or name a preferred alternative for raw chain or IV-surface queries, so it falls short of a 5.

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