Skip to main content
Glama

List risk-adjusted yields

list_yields
Read-onlyIdempotent

Rank stablecoin yield opportunities on Ethereum, Base, and Arbitrum using multi-factor risk-adjusted scoring (not raw APY). chains/chainIds: those three only (aliases eth/ETH/Ethereum, arb/ARB, BASE) — any unsupported or blank value (solana, optimism, "") is VALIDATION_ERROR, not a silent default-universe fallback. sourceChainKey: same keys/aliases; blank or unknown keys are VALIDATION_ERROR (bridge cost is not estimated).

Default ranking is risk-adjusted score, not highest APY. For headline yield order, use sortBy=net_apy.

Default is risk-adjusted ranking with balanced weights. Optional params are policy controls for visiting agents.

Default when omitted: sortBy=risk_adjusted, sortOrder=desc, riskAppetite=balanced (v1.1 weights), no minScore, no category filter, diversity=soft (max 2 markets per protocol in presented top-k). Primary composite key: compositeRiskAdjusted (protocol risk, depeg/counterparty, liquidity, yield quality base vs incentive, net yield after gas/bridge). Opportunities may include stability signals: apyChange24h is pool-level DefiLlama apyPct1D when present as a number (including 0 = observed flat change); null/missing means unknown/not provided for that pool (e.g. some Pendle markets) — not the same as 0, never invent 0; tvlChange24hPct is protocol-level DefiLlama change_1d (shared across markets of the same protocol — not this pool's TVL flow; missing stays null); large APY jumps warn only. Also exitRisk/exitRiskReason (size-vs-pool liquidity heuristic only: pool TVL vs notionalUsd + liquidity confidence — not on-chain withdraw, not queue/cap/pause/lockup, not transfer whitelist/eligibility/redemption, not an execution gate; unknown ≠ safe; medium often means liquidity confidence medium, not “small pool”; low is strict; when knownIssues mention transfer/eligibility do not treat low as free exit; soft warnings on high/unknown, plus low/medium if those issues are present; does not change default risk-adjusted ranking).

Optional policy knobs: sortBy (risk_adjusted|net_apy|gross_apy|tvl), sortOrder, riskAppetite (conservative|balanced|aggressive), minScore (0–100 after appetite; practical bands ~≥85 treasury default, ≥80 selective; 90 is rare/very strict — a few top L2 blue-chips may clear it), categories / excludeCategories (lending|rwa|other), diversity (soft|off — default top prefers protocol diversity; set off for every market from one protocol), includeFactors (boolean, default false — when true each opportunity has scores.factors compact map without a second tool call), maxRewardShare (0–1 optional incentive-share gate only — max reward/total; e.g. 0.3 treasury, 0.25 stricter; unknown share excluded when set; does not remove high base-only APY farms — pair with minScore/riskAppetite/excludeCategories for capital preservation).

Prefer this when capital preservation and sustainable yield matter more than headline APY.

Research only — never executes transactions or holds keys.

Copy-paste path (after health {}): { "assets": ["USDC"], "sortBy": "risk_adjusted" } Then contrast #1 vs #2 (risk-adjusted winner vs next row — often higher rate / thinner liquidity / other chain). Do not contrast against the max-APY row in the ten.

Examples: (a) Treasury/conservative: { "riskAppetite": "conservative", "minScore": 85, "excludeCategories": ["rwa"], "maxRewardShare": 0.3, "minTvlUsd": 10000000, "limit": 10 } (b) Default research (v1.1): { "assets": ["USDC"], "sortBy": "risk_adjusted" } (c) Yield-seeking: { "sortBy": "net_apy", "riskAppetite": "aggressive", "chains": ["base"], "assets": ["USDC"], "limit": 15 } (d) With factor breakdown: { "assets": ["USDC"], "limit": 5, "includeFactors": true }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (default 10, max 25). Example: 10
assetsNoStablecoin symbols to match in pool symbol, e.g. ["USDC","USDT"]
chainsNoFilter chains: ethereum | base | arbitrum (aliases eth/ETH/Ethereum, arb/ARB, BASE; or Llama names). Default when field omitted: all three. Blank, whitespace, or unsupported values (solana, optimism, "") are VALIDATION_ERROR — not a silent fallback. Example: ["base","ethereum"]
sortByNoSort key: "risk_adjusted" (default) | "net_apy" | "gross_apy" | "tvl"
chainIdsNoOptional numeric chain ids: 1, 8453, 42161 only. Any other id is VALIDATION_ERROR (not a silent default-universe fallback).
minScoreNoMinimum compositeRiskAdjusted after appetite weights (0–100). Omitted = no filter
diversityNoPresented top-k protocol diversity: "soft" (default, max 2 per protocol) | "off" (plain score order, every market)
minTvlUsdNoMinimum TVL in USD (default 1000000). Example: 5000000
protocolsNoOptional protocol slugs, e.g. ["aave-v3","morpho-blue"]. Blank entries are VALIDATION_ERROR (not treated as all protocols).
sortOrderNoSort direction: "desc" (default) | "asc"
categoriesNoInclude only these categories: "lending" | "rwa" | "other"
horizonDaysNoHolding horizon in days for gas/bridge amortization (default 30). Example: 30
notionalUsdNoNotional USD size for net-yield cost amortization and exitRisk TVL multiples (default 10000). Example: 10000
riskAppetiteNoScoring weight profile: "balanced" (default/v1.1) | "conservative" | "aggressive"
includeFactorsNoIf true, each opportunity includes scores.factors compact map (protocolRisk, depegCounterparty, liquidity, yieldQuality, costAdjusted). Default false — omits heavy factors[] rationales.
maxRewardShareNoIncentive-share gate only: max reward/total of gross APY, 0–1 (e.g. 0.3 treasury, 0.25 stricter). Does not remove high base-only APY farms. Capital preservation still needs minScore/riskAppetite/excludeCategories. Omitted = no filter. Unknown share excluded when set.
sourceChainKeyNoAgent's current chain for bridge cost estimate: ethereum | base | arbitrum (aliases: eth, ETH, Ethereum, arb, ARB, BASE). Blank/whitespace is VALIDATION_ERROR (omit the field to default). Unknown keys (solana, foo) return VALIDATION_ERROR — no invented bridge fee.
excludeCategoriesNoExclude these categories, e.g. ["rwa"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to restate safety. However, it adds useful behavioral context about error handling (VALIDATION_ERROR for unsupported chains) and what fields like exitRisk mean (heuristic only, not an execution gate). Still, the description is extremely long and includes many behavioral details that may overwhelm; some like 'never invent 0' are helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long (several paragraphs) and covers a lot of detail, but it is front-loaded with the core purpose and uses structured bullets for examples. Some redundancy exists (defaults restated in parameter descriptions), and the sheer length may reduce readability for an agent scanning quickly.

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?

For an 18-parameter tool with no output schema, the description covers defaults, error behavior, ranking logic, edge cases (like null vs 0 changes), and practical usage examples. The copy-paste path helps agents get started immediately. Nothing essential for calling this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter already has a description. The tool description adds significant semantic value beyond schema: explains the composite risk score meaning, gives practical bands for minScore, explains diversity default behavior, maxRewardShare edge cases, and how includeFactors avoids a second call. This goes well beyond what the schema's short descriptions provide.

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 explicitly states it ranks stablecoin yield opportunities using risk-adjusted scoring, distinguishes from raw APY ranking, and names the specific chains (Ethereum, Base, Arbitrum). It clearly differentiates itself from sibling tools that compare or explain scores.

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 provides explicit guidance on when to use this tool ('Prefer this when capital preservation and sustainable yield matter more than headline APY'), gives examples for different risk appetites, and explicitly says not to contrast against max-APY rows. It also names alternatives like sortBy=net_apy for headline yield.

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.