Ironflow: Hyperliquid data

Create liquidation alert

create_liquidation_alert

Have Ironflow post Hyperliquid liquidations to the user's Discord channel, Slack channel, Telegram chat or HTTPS webhook as they happen (within seconds), filtered by market, side, size and wallet. It keeps running after the conversation: use it when the user wants to be told about liquidations, not just to see them now. Needs an API key (free key: 1 alert; Explorer 5; Builder 20). Give url (a Discord channel webhook from channel settings, Integrations, Webhooks, Copy Webhook URL; a Slack incoming webhook; or any public https URL) or telegram_chat (then tell the user to add the bot named in the result's setup to that chat). A plain webhook gets signed JSON, and its signing_secret appears only in this result, so pass it on. Then call test_liquidation_alert to check that it arrives.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_liquidation_alert"
  }
}

Input Schema

Name	Required	Description
`url`	No	Where to post: https://discord.com/api/webhooks/..., https://hooks.slack.com/services/... or a public https URL (or use telegram_chat)
`name`	No	Label shown in each message, e.g. BTC whales
`side`	No	Which positions: long = longs liquidated (default any)
`address`	No	Only this wallet's liquidations (0x...)
`markets`	No	Comma-separated markets, e.g. BTC,ETH-PERP,xyz:NVDA (Hyperliquid names work); omit for every market
`min_usd`	No	Smallest liquidation to report, in USD (default 0; 100000 keeps a channel readable)
`telegram_chat`	No	A Telegram chat instead of url: @channel or group name, or a numeric chat id (-100...)

Output Schema

Name	Required	Description
`id`	No	Alert id (UUID)
`name`	No	Label shown in each message
`side`	No	any, long (longs liquidated) or short
`type`	No	webhook, discord, slack or telegram
`setup`	No	What to do before the first message arrives (Telegram: the bot to add to the chat)
`notice`	No	Present when the API added a note: how a market name was read, that data starts later than asked because of the history window, or a next step such as a free key
`status`	No	active or disabled (after 20 failed deliveries in a row)
`address`	No	Only this wallet, when set
`markets`	No	Markets watched; empty means every market
`min_usd`	No	Smallest liquidation reported, USD
`failures`	No	Failed deliveries in a row
`created_at`	No	Creation time, RFC 3339
`last_error`	No	The destination's last error
`sent_count`	No	Liquidations delivered so far
`destination`	No	Host it posts to, without the secret part of the URL
`last_sent_at`	No	Last delivery, RFC 3339; null before the first
`signing_secret`	No	Webhooks only: HMAC key for the X-Ironflow-Signature header, shown only here

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, open-world, non-idempotent write; the description goes well beyond that by disclosing delivery latency ('within seconds'), persistence after the conversation ends, API key quota tiers, that the response's signing_secret is shown only once and must be forwarded, and the Telegram bot-membership prerequisite. This is exactly the kind of behavioral context annotations cannot carry.

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?

The core capability, the when-to-use rule, and the credential requirement are front-loaded, and every later sentence carries operational value (quota, secret handling, bot setup). It is a dense single block, though, and the inline Discord UI navigation ('channel settings, Integrations, Webhooks, Copy Webhook URL') is wordy enough to slow scanning.

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?

For a 7-parameter write tool with an output schema, the description covers creation, delivery format, authentication, secret handoff, and the verification step. It leaves management of existing alerts (list/delete siblings) and repeat-call behavior of a non-idempotent tool unaddressed, which is the remaining hole.

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 adds real meaning on top: it explains that url accepts Discord channel webhooks, Slack incoming webhooks, or any public https URL, that a plain webhook receives signed JSON, and that telegram_chat is an alternative to url. It does not clarify how url and telegram_chat interact when both are supplied, or what the default filter behavior is for the zero-required-parameter case.

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?

Opens with a specific verb and resource ('post Hyperliquid liquidations') plus the delivery destinations and the filter dimensions, then explicitly separates itself from read-only siblings: 'use it when the user wants to be told about liquidations, not just to see them now.' An agent can distinguish this from get_liquidations or get_liquidation_summary without opening any 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 the selecting condition ('wants to be told ... not just to see them now') against the read alternatives, states the key/quota prerequisite with concrete tier numbers, and prescribes the follow-up call to test_liquidation_alert. The only mild gap is that it does not mention list_liquidation_alert or delete_liquidation_alert for later management.

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

All Ironflow: Hyperliquid 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.