LiquidVision — Crypto Derivatives Data

test_rule

Read-onlyIdempotent

[measured] Test a trigger against our hourly archive BEFORE acting on it or alerting on it: when was this rule true before, and what did price do next? Returns matched hours, independent episodes (one per 24 h) with each one's 24 h and 72 h return, the outcome statistics (share up, median, quartiles, worst, best), the unconditional base rate over the same hours, whether the rule is true right now, and a verdict on sample size. The rule syntax is the condition-alert syntax, so a rule that tests well becomes create_alert(type= 'condition', ...) with the same metric/op/threshold. Frequencies from our archive (hourly, since 2026-07 for BTC/ETH/SOL), NOT a forecast. Priced: $0.10 per call (x402), 20 prepaid credits, a free key's daily quota (100 metered calls), or Pro/Bot.

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": {
      "rules": "<rules>"
    },
    "name": "test_rule"
  }
}

Input Schema

Name	Required	Description	Default
`coin`	No	Base asset, e.g. BTC, ETH, SOL (no USDT suffix).	BTC
`rules`	Yes	Up to 3 rules joined by commas or 'and', each metric>threshold or metric<threshold. Metrics: price_chg_1h_pct, price_chg_24h_pct, oi_chg_1h_pct, oi_chg_24h_pct, funding_apr_pct, long_pct, liq_1h_usd, liq_24h_usd. Example: funding_apr_pct>40,oi_chg_24h_pct>5
`api_key`	No	LiquidVision API key (lv_...). Omit when the key is sent as the X-API-Key header on the connection.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds substantial context beyond them: archive coverage limits (hourly, since 2026-07, BTC/ETH/SOL only), pricing/rate-limit model ($0.10 per call via x402, 20 prepaid credits, free-key daily quota of 100 metered calls, Pro/Bot), and the verdict-on-sample-size behavior. This tells the agent what constraints and costs to expect before calling.

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 purpose and the caution before the output list, and the return contract is enumerated compactly. The pricing sentence is somewhat dense and longer than needed, but it carries real constraints rather than filler.

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 carries the return contract — matched hours, independent 24h episodes with 24h and 72h returns, outcome stats (share up, median, quartiles, worst, best), unconditional base rate, current truth, and a sample-size verdict — which is complete for an agent to interpret results.

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. The description adds value beyond the schema by stating that the rule syntax is the condition-alert syntax sharing metric/op/threshold with create_alert, which lets an agent reuse a known format rather than infer it from the example 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 (test) and resource (a rule/trigger) plus the scope (hourly archive, backtest not forecast), and explicitly distinguishes from create_alert by positioning itself as the pre-check step. An agent can tell it apart from sibling alert tools without opening the 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?

Gives an explicit when: 'BEFORE acting on it or alerting on it', plus the alternative path — a rule that tests well becomes create_alert(type='condition', ...) with the same metric/op/threshold. It also states what the tool is not (a forecast), which prevents misuse as a prediction endpoint.

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 tools Inspect

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.