Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Expiry calendar and settlement prices across venues

get_settlements
Read-only

Find upcoming futures and options expiries and recorded settlement prices by date, venue, and underlying; filter by one asset or limit results.

Instructions

Call this when the user asks what futures or options expire soon, when the next quarterly expiry is on an exchange, how many contracts settle this week, or at what price a dated future settled. Returns the next 60 days of dated future and option expiries grouped by date, venue and underlying from 54 venues' market lists, plus the settlement prices recorded as dated futures deliver. Without base, the first 30 expiry rows and the 30 newest settlement prices; pass base for one asset's full lists, or limit (up to 300).

Input Schema

NameRequiredDescriptionDefault
baseNoOptional. One underlying, e.g. BTC: every expiry row and settlement price of that asset.
limitNoOptional. Rows per list without base (default 30): expiries soonest first, settlements newest first.

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. Changed2 schema fields changedv0.36.0
    • addedInput schema / properties / base
      Added value: +{
+  "description": "Optional. One underlying, e.g. BTC: every expiry row and settlement price of that asset.",
+  "pattern": "^[A-Z0-9]{1,16}$",
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Optional. Rows per list without base (default 30): expiries soonest first, settlements newest first.",
+  "maximum": 300,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv0.27.2

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 the safety profile is covered; the description adds real value on top by disclosing the 60-day horizon, the 54-venue source, the two separate result lists and their sort orders, and the default page size of 30. It omits failure behavior and any rate-limit or coverage caveats, which keeps it out of the 5 band.

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?

Two sentences, front-loaded with the invocation triggers before the return description, with no filler. It is dense and the defaults sentence is long, but each clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-optional-parameter read tool with no output schema, the description supplies the return shape (two grouped lists), the horizon, the default and maximum sizing, and the scoping effect of base. Only the exact field-level payload remains unspecified, which is acceptable without an output schema.

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 would be 3, and the description genuinely adds semantics: base selects one asset's full lists and lifts the row cap, limit only applies without base and caps at 300. The per-list sort direction (expiries soonest first, settlements newest first) is not derivable from the schema alone.

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 and resource set: expiries of dated futures and options plus the settlement prices recorded at delivery, grouped by date, venue and underlying. An agent can distinguish this from near-siblings such as get_options_chain or get_venue_markets because the scope is explicitly 'expiring contracts and their final settlement prices', not live chains or venue metadata.

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 four concrete invocation triggers ('expire soon', 'next quarterly expiry on an exchange', 'how many contracts settle this week', 'at what price a dated future settled'), which is strong context. It does not name a when-not case or an explicit alternative tool to prefer, so it stops short of the top band.

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