f1ow

Perp Levels (volume, OI, liquidations, walls)

flow_levels

Read-only

Perp price levels for one coin, from what printed rather than from a chart: executed volume at price on every venue that lists it (Binance, Bybit, BingX, Hyperliquid), with the value area (70% of volume around the POC), high-volume nodes and thin zones (prices crossed without trading, where moves tend to run); open-interest changes at price split into long and short entries; realized liquidations at price (OKX/Gate sample); and resting walls from deep books on several venues, counted only when a second snapshot 2 s later still shows them. Every level is graded by evidence — traded (volume, liquidations) > inferred (OI side) > resting (orders, which can be pulled) — and lists the other evidence at the same price (confluence). Walls larger than their venue's own daily volume are flagged. Use it for where price may stall, accelerate or meet forced flow; it is not a forecast.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hours`	No	Window in hours, 24–168. Default 72.
`symbol`	Yes	Coin symbol, e.g. "WAVES".

Output Schema

TableJSON Schema

Name	Required	Description
`rule`	No
`spot`	Yes
`step`	No	Price bin width
`levels`	No
`symbol`	Yes
`window`	No	The window at a glance: price from the venue that traded most, OI from the flow venue, volume in the band, liquidations in the sample
`caveats`	No
`sources`	No
`supports`	No	Nearest levels on this side, one entry per price, strongest-first among the nearest
`valueArea`	No
`resistances`	No	Nearest levels on this side, one entry per price, strongest-first among the nearest
`spotContext`	No
`windowHours`	No
`dailyRangePct`	No	Average 24h high–low range over the window, percent of price
`sourcesFailed`	No
`unconfirmedWalls`	No	Walls larger than their venue's own 24h volume: shown, never counted as support or resistance

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedOutput schema / properties / window

Added value: +{
+  "description": "The window at a glance: price from the venue that traded most, OI from the flow venue, volume in the band, liquidations in the sample",
+  "properties": {
+    "liquidatedUsd": {
+      "type": "number"
+    },
+    "oiChangePct": {
+      "type": "number"
+    },
+    "oiEndUsd": {
+      "type": "number"
+    },
+    "oiStartUsd": {
+      "type": "number"
+    },
+    "oiVenue": {
+      "type": "string"
+    },
+    "priceChangePct": {
+      "type": "number"
+    },
+    "priceEnd": {
+      "type": "number"
+    },
+    "priceStart": {
+      "type": "number"
+    },
+    "priceVenue": {
+      "type": "string"
+    },
+    "volumeUsd": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

AddedOct 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With only readOnlyHint provided, the description carries the behavioral burden well: it discloses data provenance and gaps (OKX/Gate liquidation sample), the 2-second second-snapshot confirmation for walls, the evidence-grading hierarchy (traded > inferred > resting), and the caveat that resting orders can be pulled. This is rich, non-obvious context beyond the annotations.

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?

Content is front-loaded (purpose first, then sources, then grading, then usage), and every clause adds substantive information. It is dense and the sources are packed into one long run-on sentence, which slightly hurts scannability, but there is little dead weight.

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?

An output schema exists, so return-value explanation is unnecessary. The description still covers sources, limitations, grading, and usage intent, leaving nothing an agent needs to call it correctly missing.

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% and both parameters (hours with range/default, symbol with example) are fully documented in the schema. The description adds no syntax or format detail beyond that, so baseline 3 is appropriate.

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 resource ('Perp price levels for one coin') and immediately scopes it ('from what printed rather than from a chart'), then enumerates the exact content types: volume-at-price, value area/POC, HVNs, thin zones, OI changes by side, liquidations, and resting walls. An agent can distinguish this from derivatives_flow or flow_orderbook without opening schemas.

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?

Gives explicit when-to-use context ('where price may stall, accelerate or meet forced flow') and an exclusion ('it is not a forecast'). However, it never names a sibling alternative such as derivatives_flow, derivatives_liquidations, or flow_orderbook, so the agent must infer routing against those tools.

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

All f1ow 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.

Resources

Need Help?