Skip to main content
Glama

MetaLend

by io.github.rabeles11

List rebalancer pools

list_pools
Read-only

List all pools MetaLend's rebalancer can deposit into: protocol (Aave, Morpho, Euler), chain, APY breakdown (native/rewards/total/net-of-fee), TVL, liquidity, and the signData (protocolId, poolAddress, domainId) needed to build a rebalancer config. Does NOT return a wallet's current balances or configuration — use get_balances / get_config for that. Callers should filter out pools where blacklisted is true. poolTvl/poolLiquidity can read "0" either because the pool is genuinely empty or because upstream data is momentarily missing — the two are not distinguishable here. There is no pool-level paused/capacity/deposit-or-withdraw-enabled flag: deposits can be paused globally, and withdrawals from specific pools can be temporarily blocked per-wallet (e.g. during a funding-cap refill) — neither shows up in this list, only as an error from submit_deposit/submit_withdrawal itself. Rate limited to 20 calls/minute per caller, no more than one call every 3s.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: it explains that poolTvl/poolLiquidity may read '0' for two indistinguishable reasons, that blacklisted pools must be filtered, that there is no pool-level paused/capacity flag, and that deposit/withdrawal blocking is invisible here. No contradiction with annotations exists.

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?

Every sentence earns its place: the core purpose is front-loaded, the sibling distinction is explicit, the caveats address realistic misinterpretations, and the rate limit is actionable. Though the description is longer than a one-liner, the tool's data ambiguities and absence of pool-level flags genuinely require this much detail. It remains well-structured and not redundant.

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?

With no output schema, the description carries the full burden of explaining the return semantics, and it does so thoroughly: it names the returned fields, clarifies the meaning of zero TVL/liquidity, identifies what is intentionally not returned, and explains how paused/blocked states manifest elsewhere. Nothing essential is missing for an agent to call this tool correctly.

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?

The tool has zero parameters, so the input schema carries no burden and the description need not explain parameter meaning. The description instead focuses on what the returned list contains, which is appropriate. Since there are no parameters, a baseline score of 4 is warranted, and the description adds no misleading parameter-related claims.

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 opens with a specific verb and resource: 'List all pools MetaLend's rebalancer can deposit into.' It then enumerates the exact returned fields (protocol, chain, APY breakdown, TVL, liquidity, signData). It also explicitly distinguishes itself from get_balances and get_config, so an agent can immediately tell it apart from siblings.

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?

The description gives explicit when-to-use and when-not-to-use guidance: it says the tool does NOT return wallet balances or configuration and directs callers to get_balances/get_config. It also instructs callers to filter out blacklisted pools and warns that paused/capacity conditions will only surface as submit_deposit/submit_withdrawal errors, not in this list. Rate limits are also stated.

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

All MetaLend toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Every tool targets a distinct operation: auth challenge/verify, config read/build/submit, deposit/withdrawal prepare/submit/status, balances, rewards, pools, and small utility lookups. Descriptions explicitly cross-reference one another (e.g., get_balances vs get_bridge_balances vs get_rewards), making accidental misselection very unlikely.

Naming Consistency5/5

Tool names follow a consistent snake_case verb_noun pattern: get_* for reads, prepare_* for signing-payload construction, submit_* for signed writes, and list_pools for the catalog. The verb families map cleanly onto the tool's lifecycle stages, so the naming is predictable and scannable.

Tool Count4/5

19 tools is on the higher end, but the count is justified by the domain: authentication, config lifecycle, deposit/withdrawal prepare-and-submit flows, status polling, balances, and reward reading each need dedicated surface area. A few utilities (get_token_info, get_transaction_costs, get_withdrawal_version) feel slightly granular, but none are redundant.

Completeness4/5

The tool set covers the core lifecycle well: auth, config creation/update, deposit, withdrawal, status tracking, balance/reward queries, and pool discovery. Minor gaps exist (no reward claim endpoint, no deposit/withdrawal history listing, no explicit rebalancer deletion), but the descriptions provide workarounds and clearly scope what is intentionally unsupported.

Resources