Skip to main content
Glama
parkyucheol-del

AlphaPipeline

by parkyucheol-del
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

market.oracle_gap

Measure the single-snapshot basis-point gap between a Hyperliquid perpetual's mid price and its mark/oracle price, returning an elevated flag to help detect oracle-pricing risk.

Instructions

Single-snapshot gap between Hyperliquid's mid price and its mark/oracle
prices for one perpetual - the exact failure mode behind the 2026-10-10
Papertrade incident on HyperEVM, where a protocol priced off Hyperliquid's
raw mid instead of mark/oracle and an attacker moved ~$2.31B notional on
Hyperliquid itself to swing the mid ~12bp, netting ~$1.28M from Papertrade.
Returns mid_oracle_gap_bp and mark_oracle_gap_bp in basis points, plus an
`elevated` flag.

`elevated` is a fixed-threshold boolean (abs(mid_oracle_gap_bp) >=
alert_threshold_bp), NOT a manipulation determination - it only says the
gap is currently wide, not why. This is a single point-in-time snapshot
with no trade-flow or volume data (Hyperliquid's public API does not
expose per-market volume), so it cannot by itself distinguish organic
volatility from an attempted price push. Always check the response's
`notice` field.

Args:
    coin: Hyperliquid perpetual ticker, e.g. "ETH" or "BTC".

Returns:
    On success: {"success": true, "coin", "mid_price", "mark_price",
        "oracle_price", "mid_oracle_gap_bp", "mark_oracle_gap_bp",
        "elevated", "alert_threshold_bp", ...}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly: it defines `elevated` as a fixed-threshold boolean, not a manipulation verdict, discloses the single-point-in-time limitation, notes the absence of volume data from the public API, and instructs the agent to always check the response's `notice` field. This is unusually candid behavioral disclosure.

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?

Purpose and return values are front-loaded, and the Args/Returns structure is clean. The 2026 Papertrade incident narrative is long but earns its place by motivating why the tool exists and what the `elevated` flag does not mean; a sentence or two of the backdrop could be trimmed.

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?

For a one-parameter snapshot tool with no output schema or annotations, the description documents the return shape (success/failure variants and field list), the caveats, and the interpretation of the computed flag. An agent has everything needed to call it correctly and read the result responsibly.

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 description coverage is 0% and the schema itself only has an untyped 'Coin' string. The description compensates by defining `coin` as a 'Hyperliquid perpetual ticker, e.g. "ETH" or "BTC"', which is exactly the format guidance the schema omits. An enum would have been better, but the description meaningfully fills the gap for the single parameter.

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 first sentence states a precise verb+resource+scope: a single-snapshot comparison of Hyperliquid's mid versus mark/oracle price for one perpetual. It names the exact output fields (mid_oracle_gap_bp, mark_oracle_gap_bp) and is trivially distinguishable from siblings like derivatives.funding_rate or dex.liquidity_slippage.

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 frames the use case (detecting the mid-vs-oracle divergence failure mode) and explicitly states what it is NOT — 'cannot by itself distinguish organic volatility from an attempted price push' — which is strong negative guidance. It doesn't name a specific sibling tool to use instead for trade-flow or manipulation confirmation, so it stops short of a 5.

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