Skip to main content
Glama

DeFi lending liquidations

defi_liquidations
Read-onlyIdempotent

Lending liquidations from Aave V3 and Morpho Blue on Ethereum, Arbitrum and Base: a third party repaid the debt and seized the collateral, so both wallets are named on every row. A different event from a perp liquidation (see the liquidations tool) and never summed with one. count and total_usd cover exactly the rows returned and the window field states the period those rows span, so the total is never mistaken for a fixed 24h figure. Keyless. Descriptive market data only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoRestrict to one chain: ethereum, base, arbitrum. Anything else is refused by name rather than answered as nothing happening there. Omit for all of them.
limitNoMax rows returned. Defaults to 50, hard ceiling 200 for everyone and no plan raises it. count and total_usd cover exactly the rows returned, and window states the period those rows span, so neither is a fixed 24h figure.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOne line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading.
countNoHow many rows this reply carries.
cappedNoPresent only when an argument was cut down to a ceiling. Absent means nothing was clamped, so a smaller number than you asked for is the data and not a limit.
windowNoThe period the returned rows actually span: from, to and hours.
matchedNoHow many rows matched the chain filter before the row cap.
availableNoFalse when this lane could not answer: a producer is dark, the pair sits outside this plan, or the argument named something we do not carry. Absent or true means the numbers are a real reading, not a guess.
total_usdNoDollars across exactly the rows returned. A page sum, not a fixed 24h total: the window field says what period those rows span.
truncatedNoTrue when more rows matched than were returned, so what you have is a page and not the whole set.
access_noteNoWhat this connection could not return and what lifts it. Always pass this on to the user: it is the only place that information appears.
liquidationsNoThe events, each naming BOTH wallets: the one liquidated and the one that repaid the debt and took the collateral.
unknown_chainNoSet when a chain was named that this lane does not index. Nothing was searched, so this is not no liquidations there.
chains_coveredNoThe chains this lane indexes.
protocols_coveredNoThe lending protocols behind these rows.
duplicates_droppedNoHow many repeat rows for the same event were removed before counting, so the dollars are not doubled.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: keyless access, descriptive market data only, and clarifies that 'count' and 'total_usd' cover exactly the returned rows with a 'window' field, avoiding misinterpretation of fixed 24h figures. This exceeds the annotation baseline.

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?

Three sentences, each dense with information: scope, event distinction, and metric semantics. No fluff, front-loaded with the most important purpose, and every sentence earns its place.

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?

Given an output schema exists and annotations cover safety, the description covers scope, event type, chain availability, metric semantics, and alternative tool differentiation. It is complete for a read-only filtered tool with simple parameters.

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 100% for both parameters, providing full documentation. The description further clarifies the 'limit' parameter's behavior (defaults, hard ceiling) and the 'chain' parameter's refusal behavior, adding value beyond schema. Baseline 3 is elevated to 4 due to meaningful extra context.

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 states a specific verb ('repaid debt and seized collateral') and clearly names resources (Aave V3, Morpho Blue on Ethereum, Arbitrum, Base). It distinguishes from the sibling 'liquidations' tool by explicitly saying it's a different event and never summed with one.

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 provides clear context on what the tool covers (lending liquidations vs perp liquidations) and names the alternative 'liquidations' tool for perp liquidations. It does not explicitly say 'when not to use' beyond the differentiation, but the guidance is specific enough to select correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation3/5

Many tools share the same broad purpose domains, such as market_digest vs market_overview vs market_snapshot and whale_context vs whale_profile vs whale_flow, making selection genuinely ambiguous for an agent. The long descriptions help separate them, but the sheer number of overlapping 'one-call' market and whale views still invites misselection, and whale_tape is a direct duplicate alias.

Naming Consistency4/5

Names are consistently snake_case and mostly follow a clear domain-prefix pattern: market_*, whale_*, hl_*, defi_*. Minor deviations like liquidations vs market_liquidations, liq_zones, my_access, and the deprecated whale_tape keep it from a perfect score, but the overall convention is predictable and readable.

Tool Count2/5

With 30 tools, the server exceeds the reasonable upper bound and feels heavy even for a broad data domain. Many tools could be consolidated—for instance, several one-call market summary tools and multiple whale-flow variants—without losing capability.

Completeness4/5

The tool set covers an impressively wide range of whale and market data: news, liquidations, funding, DEX activity, Hyperliquid wallets, market scans, history, and plan access. There are minor gaps such as no general price/OHLC history or per-wallet trade history beyond swaps and fills, but agents can work around these using the existing surface.

Resources