Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Solana Perps board: open interest, 24h volume and hourly rates across six Solana perpetual venues (Jupiter, Pacifica, Phoenix, GM Trade, Velocity, Bullet)

get_solana_perps
Read-only

Retrieve Solana perpetuals data across Jupiter, Pacifica, Phoenix, GM Trade, Velocity and Bullet: per-venue open interest, 24h volume, funding rates, market counts and hourly market history.

Instructions

Call this when the user asks about perpetuals on Solana as a whole, which Solana perp DEX has the most open interest or volume, a market on Pacifica, Phoenix, GM Trade (GMX on Solana), Velocity (the Drift relaunch) or Bullet (funding, open interest, 24h volume, mark), or how Jupiter compares with the order-book venues. Returns the board read every 10 minutes: per-venue totals (one-sided open interest, both sides on pool venues, 24h volume, market count, median hourly rate, as_of), every market of every venue largest first with instrument type (perpetual, equity, index, commodity, fx), and optional hourly history of one market on any venue but Jupiter (7 days on the Free plan, 30 on Builder and higher plans; Jupiter history is get_jupiter_perps). Without venue, the 30 largest markets; pass venue, or limit (up to 300) for more.

Input Schema

NameRequiredDescriptionDefault
limitNoOptional. Markets without venue, largest first (default 30).
venueNoVenue filter: jupiter, pacifica, phoenix, gmtrade, velocity or bullet
symbolNoMarket symbol on the chosen venue (Pacifica when venue is not given) for hourly history, as the board lists it, e.g. SOL, SOL-PERP, SOL-USD, kBONK
history_daysNoHourly history for the symbol, 1..30 days

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.36.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Optional. Markets without venue, largest first (default 30).",
+  "maximum": 300,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Changed2 schema fields changedv0.31.0
    • changedInput schema / properties / symbol / description
      Previous value: -"Market symbol on the chosen venue (Pacifica when venue is not given) for hourly history, e.g. SOL, SOL-PERP, SOL-USD"New value: +"Market symbol on the chosen venue (Pacifica when venue is not given) for hourly history, as the board lists it, e.g. SOL, SOL-PERP, SOL-USD, kBONK"
    • changedInput schema / properties / symbol / pattern
      Previous value: -"^[A-Z0-9_.-]{1,24}$"New value: +"^[A-Za-z0-9_.-]{1,24}$"
  4. Addedv0.30.4

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior beyond that: the board is refreshed every 10 minutes, open interest is one-sided except on pool venues where it is both sides, medians are hourly rates, and history depth is plan-gated (7 days Free, 30 on Builder+). Those are exactly the operational constraints an agent needs before promising data to a user.

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-loaded correctly: trigger conditions first, return shape second, parameter behavior last. However, it is delivered as one dense run-on with stacked parentheticals (venue aliases, plan tiers) that takes effort to parse; a couple of breaks would preserve all content with less friction.

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 return-value disclosure and does so thoroughly: per-venue totals with named fields, per-market rows ordered largest first with instrument type taxonomy, and the optional history series. Nothing an agent needs to call this correctly or describe results to a user is missing.

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 field-level meaning is already carried by the schema. The description still adds real semantics: without a venue you get the 30 largest markets, passing venue or raising limit (up to 300) widens it, and symbol defaults to Pacifica when venue is absent. It does not explain how symbol and history_days interact when symbol is supplied without history_days, which keeps it below a 5.

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 (reads the Solana perps board) and enumerates the exact scope: six named venues, per-venue totals, per-market rows, optional hourly history. It explicitly separates itself from the sibling get_jupiter_perps for Jupiter history, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger list ('when the user asks about perpetuals on Solana as a whole, which venue has the most open interest or volume, a market on Pacifica/Phoenix/...'), and names the alternative tool for the one case this one does not cover (Jupiter history). When-to-use and when-to-use-something-else are both present.

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