Skip to main content
Glama

Liquidation Monitor

liquidation-monitor
Read-only

Aave v3 on Base: total collateral, debt, health factor and risk band (LIQUIDATABLE / AT_RISK / WATCH / HEALTHY / NO_DEBT) for any wallet. Price: 0.0050 USDC per call (premium: always paid).

Input Schema

NameRequiredDescriptionDefault
userAddressYesWallet address (0x...) to inspect

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnlyHint and openWorldHint, and the description adds genuinely new behavioral facts: the exact cost (0.0050 USDC per call), that it is a premium call always charged regardless of result, and the enumerated risk-band outputs. It stops short of describing latency, rate limits, or error behavior on invalid/unpositioned wallets.

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?

Two sentences with no filler; the scope and returned fields are front-loaded and the pricing/terms clause follows. Slightly dense with the parenthetical enum list, but every element earns its place.

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?

With no output schema, the description carries the burden of explaining return values, and it does so by naming the four metrics and the five risk bands. Combined with the pricing disclosure, an agent has what it needs to decide and call correctly, though error/empty-position behavior remains unaddressed.

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% for the single userAddress parameter, so the baseline is 3. The description adds no format, chain-scoping, or validity guidance beyond what the schema already states ('Wallet address (0x...) to inspect').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb-implied resource set (total collateral, debt, health factor, risk band) for a specific protocol and chain (Aave v3 on Base) and a scoped target (any wallet). It is clearly distinct from generic siblings like wallet-portfolio or market-snapshot, though it never explicitly contrasts with the closer liquidity-health sibling.

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?

Usage is implied: call this when you need a wallet's liquidation risk posture on Aave v3 Base. There is no statement of when NOT to use it, no prerequisite/eligibility notes (e.g., must be an Aave v3 position), and no routing to the similar-sounding liquidity-health sibling.

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.

Resources