Skip to main content
Glama
Sign In

LiquidVision — Crypto Derivatives Data

by app.liquidvision
OverviewDiscussions(1)Admin

attest_snapshot

Read-onlyIdempotent

[receipt] A SIGNED snapshot: the wrapped endpoint's JSON plus an attestation (SHA-256 of the canonical JSON, server time, Ed25519 signature, key id). Anyone can verify it offline with the public key at /api/v1/attest/key, so an agent acting for someone else can prove what the exchanges reported when it decided. Free snapshots and conclusions only (no metered history). It certifies what LiquidVision served, not that the exchange was right. Priced: $0.05 per call (x402), 10 prepaid credits, or a key's daily quota; the public key at /attest/key is free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "attest_snapshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesAPI path under /api/v1 to wrap, e.g. /funding, /oi, /liquidations, /oiboard/BTCUSDT, /liqmap/BTCUSDT, /answer, /position/check.
paramsNoQuery string for the wrapped path, e.g. 'q=why+did+BTC+drop&coin=BTC' or 'symbol=BTC&side=long&entry=74000&leverage=20'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the exact attestation contents, the offline verification path (/api/v1/attest/key), the cost model ($0.05 per call via x402, 10 prepaid credits, or a key's daily quota), and an important limitation: it certifies what LiquidVision served, not that the exchange was right.

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?

Three dense sentences, front-loaded with what the tool returns before moving to verification and pricing. There is minor redundancy: the /attest/key public-key path and its freeness are mentioned twice.

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, the description fully carries the burden by enumerating the returned fields (wrapped JSON, hash, server time, signature, key id) and how to verify them. Pricing, scope limits, and trust caveats are all covered for a simple two-parameter tool.

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 description coverage is 100%, with path and params already documented with concrete examples in the schema. The description adds no further detail about parameter formats, so the baseline of 3 applies.

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 specific verb and resource: it wraps a given /api/v1 endpoint and returns that endpoint's JSON plus an attestation (SHA-256 of canonical JSON, server time, Ed25519 signature, key id). That makes it clearly distinct from raw data siblings like get_funding_rates or ask, since it is a signing wrapper rather than a data source.

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 a concrete use case (an agent acting for someone else needs to prove what the exchanges reported when it decided) and an explicit scope exclusion (free snapshots and conclusions only, no metered history). It does not name a specific sibling to use instead for other cases, but the when-to-use context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All LiquidVision — Crypto Derivatives Data toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources