Skip to main content
Glama
0xsl1m

cerebrus-pulse-mcp

cerebrus_oi

Analyze open interest for Hyperliquid perpetuals, including 1h/4h/24h delta, percentile rank, trend direction, and price-OI divergence signals. Cost: $0.01 USDC via x402.

Instructions

Get open interest analysis for a Hyperliquid perpetual. Returns OI delta (1h/4h/24h), percentile rank, trend direction, and price-OI divergence signals. Cost: $0.01 USDC via x402.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinYesCoin ticker (e.g., BTC, ETH, SOL). Case-insensitive.

Implementation Reference

  • Tool registration for 'cerebrus_oi' — defines the Tool object with name, description, and inputSchema within the list_tools handler. The tool takes a required 'coin' string parameter and returns OI delta (1h/4h/24h), percentile rank, trend direction, and price-OI divergence signals. Cost: $0.01 USDC via x402.
    Tool(
        name="cerebrus_oi",
        description=(
            "Get open interest analysis for a Hyperliquid perpetual. "
            "Returns OI delta (1h/4h/24h), percentile rank, trend direction, "
            "and price-OI divergence signals. Cost: $0.01 USDC via x402."
        ),
        inputSchema={
            "type": "object",
            "properties": {
                "coin": {
                    "type": "string",
                    "description": "Coin ticker (e.g., BTC, ETH, SOL). Case-insensitive.",
                },
            },
            "required": ["coin"],
        },
    ),
  • Handler for 'cerebrus_oi' tool — validates the coin parameter via _validate_coin (uppercases and regex-checks), then calls _api_get('/oi/{coin}') to fetch open interest analysis from the Cerebrus Pulse API. The result is JSON-serialized via _format_response.
    elif name == "cerebrus_oi":
        coin = _validate_coin(arguments["coin"])
        result = _api_get(f"/oi/{coin}")
  • Helper _validate_coin — validates and normalizes a coin ticker: strips whitespace, uppercases, and checks against the regex pattern ^[A-Za-z0-9_-]+$. Raises ValueError on bad input.
    def _validate_coin(coin: str) -> str:
        """Validate and normalize a coin ticker. Raises ValueError on bad input."""
        coin = coin.strip().upper()
        if not _COIN_RE.match(coin):
            raise ValueError(f"Invalid coin ticker: {coin!r}")
        return coin
  • Helper _api_get — makes an HTTP GET request to the Cerebrus Pulse API. Handles 402 (payment required), 429 (rate limited), and other HTTP errors. Returns parsed JSON response.
    def _api_get(path: str, params: dict | None = None) -> dict[str, Any]:
        """Make a GET request to the Cerebrus Pulse API."""
        with _make_client() as client:
            resp = client.get(path, params=params)
    
            if resp.status_code == 402:
                # Return payment details so the agent/user knows cost
                return {
                    "status": "payment_required",
                    "message": "This endpoint requires x402 USDC payment on Base or Solana.",
                    "url": f"{BASE_URL}{path}",
                    "payment_details": resp.headers.get("X-Payment", "See x402 SDK docs"),
                    "help": "Install the x402 SDK and set CEREBRUS_WALLET_KEY (Base) or CEREBRUS_WALLET_KEY_SOLANA (Solana) to enable auto-payment. See https://cerebruspulse.xyz/guides/x402-payments",
                }
    
            if resp.status_code == 429:
                return {
                    "status": "rate_limited",
                    "message": "Rate limit exceeded. Back off and retry.",
                    "detail": resp.json() if resp.headers.get("content-type", "").startswith("application/json") else resp.text,
                }
    
            resp.raise_for_status()
            return resp.json()
  • CLI tool mapping for 'oi' — maps the CLI 'oi' command to the API path '/oi/{coin}' with a required 'coin' string parameter. This is used by the --json CLI mode as an alternative to the MCP handler.
        "oi":            ("/oi/{coin}",         [("coin", True, str, None)]),
        "spread":        ("/spread/{coin}",     [("coin", True, str, None)]),
        "correlation":   ("/correlation",       []),
        "stress":        ("/arb",              [("limit", False, int, 10)]),
        "cex-dex":       ("/cex-dex/{coin}",    [("coin", True, str, None)]),
        "basis":         ("/basis/{coin}",      [("coin", True, str, None)]),
        "depeg":         ("/depeg",             []),
        "liquidations":  ("/liquidations/{coin}", [("coin", True, str, None)]),
    }
Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It discloses the cost ($0.01 USDC via x402), which is helpful. However, it does not mention any destructive actions, rate limits, or other behaviors. With no annotations, the description is moderately transparent but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states purpose and return values, the second states cost. No extraneous information. Every word is justified.

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?

Given the simple tool (one required parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, returned data, and cost. Could mention that coin is case-insensitive (schema already does) or add error handling details, but overall adequate.

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?

The schema covers the single parameter (coin) with 100% coverage, including a description. The tool description does not add additional meaning beyond the schema, only restating that it takes a coin ticker. Baseline is 3 for high schema coverage.

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 clearly states the tool's purpose: 'Get open interest analysis for a Hyperliquid perpetual.' It specifies the resource (OI analysis), action (get), and scope (Hyperliquid perpetual). It also lists the return values: OI delta, percentile rank, trend direction, and divergence signals, making it distinct from sibling tools.

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?

The description implies usage for querying OI analysis, but does not explicitly state when to use this tool vs. alternatives (e.g., cerebrus_funding, cerebrus_sentiment). No when-not-to-use guidance is provided, leaving the agent to infer context from sibling names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xsl1m/cerebrus-pulse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server