Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Desk notes: short dated observations the ByKaranteli desk wrote from its own recorded derivatives data

get_desk_notes
Read-only

Retrieve dated crypto derivatives desk notes on funding, open interest, liquidations, options, ETF flows and premiums, with timestamps and news value, for quotable daily market recaps.

Instructions

Call this when the user asks what happened in crypto derivatives today or on a date, what the desk observed, what moved in funding, open interest, liquidations, options, ETF flows or exchange premiums, or wants a dated, quotable sentence with its number and time. Returns the desk's notes newest first: each is one observation written by the desk writer (an AI model) from the platform's own recorded data and checked against it before publishing, with its publish time in UTC, the card's data time, the desk's 0 to 10 news value, the board it read from, the coins it names and its permanent URL. Information about the data, never advice. Default the newest 25 notes of the last 24 hours (count says how many came back; limit up to 100 for more); pass day for one UTC day, since for a window up to 7 days back (50 notes unless limit says otherwise), type for one card type (funding-arb, liqmap-btc, event-liq-burst, ...), lang for zh, ru or ko text. Pass detail "compact" for a shorter page or "full" for the whole answer.

Input Schema

NameRequiredDescriptionDefault
dayNoOne UTC day, YYYY-MM-DD
langNoText language (default en); a note without that translation comes back in English
typeNoOne card type, e.g. funding-arb, liqmap-btc, event-liq-burst
limitNoNotes to return, 1..100 (default 25 for the last 24 hours, 50 with day or since)
sinceNoISO time; notes published at or after it, at most 7 days back (ignored with day)
detailNoOptional. "compact": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). "full" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields 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"
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Optional. \"compact\": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). \"full\" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page."
+}
  2. Changed1 schema field changedv0.36.1
    • changedInput schema / properties / limit / description
      Previous value: -"Notes to return, 1..100 (default 50)"New value: +"Notes to return, 1..100 (default 25 for the last 24 hours, 50 with day or since)"
  3. Addedv0.36.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it read-only and open-world, and the description adds substantial behavioral context beyond them: returns newest first, AI-written notes checked against recorded data before publishing, publish time and data time, news-value score, board, coins, and permanent URL. It also discloses default window, count behavior, and detail variants, with no contradiction.

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-loads the call condition and then moves to return behavior and parameter guidance, so an agent can find the key routing information quickly. It is dense and somewhat repetitive with the schema, but the content is largely purposeful for a complex, zero-required-param tool.

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?

No output schema exists, so the description must explain what comes back; it does so thoroughly with ordering, provenance, field names, defaults, limits, language and card-type filters, and compact/full detail behavior. Given the annotations and full schema coverage, an agent has enough to invoke it correctly.

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 coverage is 100%, so the schema already documents all six optional parameters. The description mostly restates those defaults and options, adding only marginal context such as count indicating how many came back; baseline 3 is appropriate when the schema does the heavy lifting.

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 scope: the desk's short dated observations written from its own recorded derivatives data. It distinguishes itself from raw-data siblings by framing the output as checked, quotable desk notes and explicitly saying it is information about data, never advice.

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?

Gives a clear triggering condition: call when the user asks what happened in crypto derivatives today/on a date, what the desk observed, or wants a dated quotable sentence. It implicitly overlaps with many sibling data tools but does not explicitly name alternatives or when not to use this one.

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