Skip to main content
Glama
hypurrquant

perp-cli

by hypurrquant
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_funding_rates

Compare funding rates across verified perpetual futures venues by symbol to find spread opportunities; optionally include unverified venue rows for display only.

Instructions

Compare funding rates across every market-data venue whose funding rate is verified. Returns rates per symbol with spread analysis. includeUnverified also returns venues whose rate is unverified (QFEX; TxFlow — rate not checked against settled payments; Variational — a predicted rate not checked against settled payments; GRVT — indicative rate; Extended — not checked against settled payments), each row tagged fundingVerified / apiStatus — display only, never a basis for trading (mirrors the CLI arb scan --include-unverified).

Input Schema

NameRequiredDescriptionDefault
symbolsNoFilter to specific symbols (e.g. ['BTC','ETH']). Omit for all available
minSpreadNoMinimum annualized spread % to include (default: 0)
includeUnverifiedNoAlso include venues whose funding rate is unverified (default false); rows carry fundingVerified:false / apiStatus

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.3
    • addedInput schema / properties / includeUnverified
      Added value: +{
+  "description": "Also include venues whose funding rate is unverified (default false); rows carry fundingVerified:false / apiStatus",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it defines the verified/unverified split, names the specific unverified venues and the reason each is unverified, and warns that unverified rows are 'display only, never a basis for trading'. It stops short of covering freshness/caching, pagination, or result-size behavior.

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 with the primary purpose, followed by the conditional behavior and the safety caveat in a sensible order. The long parenthetical venue list makes the middle sentence dense and hard to parse, but every element carries information.

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?

No output schema exists, and the description compensates by sketching the return shape (rates per symbol, spread analysis, per-row fundingVerified/apiStatus tags) and the verification semantics. Missing only secondary operational details such as snapshot timing or result limits.

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 the baseline is 3, but the description genuinely adds meaning for includeUnverified by enumerating which venues appear and why their rates are unverified — context not present in the schema blurb. symbols and minSpread are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: compare funding rates across venues, returning rates per symbol with spread analysis. An agent knows exactly what it returns, but nothing distinguishes it from close siblings like get_funding_analysis or arb_scan, which share the same domain.

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

Usage Guidelines3/5

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

Usage is implied by 'compare funding rates across every market-data venue whose funding rate is verified', and the CLI equivalence ('mirrors the CLI `arb scan --include-unverified`') hints at a workflow. However, there is no explicit when-to-use-this vs. get_funding_analysis/get_arb_compare/arb_scan guidance and no stated prerequisites.

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