Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Options implied-volatility surface and 25-delta skew

get_iv_surface
Read-only

Retrieves implied volatility surface (expiry x moneyness) for BTC/ETH from Deribit, including ATM/25-delta IV, skew, butterfly, and 30-day history to assess volatility pricing and downside protection.

Instructions

Call this when the user asks about implied volatility by strike or expiry, skew, put versus call IV, term structure of IV, or whether downside protection is expensive. Returns the IV surface (expiry x moneyness), per-expiry ATM / 25-delta put and call IV, skew and butterfly, and the constant-30d history, from the daily Deribit chain.

Input Schema

NameRequiredDescriptionDefault
currencyNoBTC or ETH, default BTC

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.27.2
    • addedInput schema / properties / currency / enum
      Added value: +[
+  "BTC",
+  "ETH"
+]
  3. Addedv0.9.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish that this is a read-only, open-world data lookup, so the description does not need to carry the safety profile. It still adds useful context by naming the data source (daily Deribit chain) and enumerating the returned fields, which helps since there is no output schema; it stops short of disclosure about freshness, latency, or snapshot timing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the selection trigger and followed by the return contents. Every clause earns its place and there is no filler.

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 and only one fully documented parameter, the description supplies exactly the missing information: what analytical questions it answers and what fields the response includes. An agent can decide to call it and interpret the result without further context.

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?

The single currency parameter has full schema description coverage and an enum, so the schema already documents it completely. The description does not mention currency at all, so it adds no meaning beyond the schema; 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?

The description states a precise resource (implied-volatility surface and 25-delta skew) and enumerates the exact analytical questions it answers (IV by strike/expiry, skew, put vs call IV, term structure, downside protection cost). Those triggers distinguish it clearly from siblings like get_options_chain, get_options_snapshot, and get_options_flow.

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?

It gives explicit when-to-use triggers tied to user questions about IV, skew, term structure, and downside protection cost. It does not name an alternative tool or state when not to use it, but the trigger conditions are specific enough to route most calls correctly.

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