Skip to main content
Glama

yieldhunter

by io.github.agentsherpa

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"]

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.

All yieldhunter 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.2/5.0
Disambiguation4/5

The tools are mostly distinct: list_yields for ranking, score_opportunity for detailed scoring of one, explain_score for explaining a score, compare_opportunities for side-by-side comparison, get_protocol_risk for protocol-level risk, and health for connectivity. However, score_opportunity and explain_score have overlapping purposes (both return factor scores and rationale), which could cause some confusion, though they serve different output formats.

Naming Consistency4/5

The naming pattern is mostly consistent using verb_noun (e.g., list_yields, get_protocol_risk, explain_score, compare_opportunities, score_opportunity). One deviation: 'health' is a single-word name that breaks the verb_noun pattern, but it's a minor deviation and still readable.

Tool Count5/5

With 6 tools, this is well-scoped for a yield research server. Each tool has a distinct role: listing, scoring, explaining, comparing, protocol risk, and health check. The count feels appropriate for the domain, not overly heavy or thin.

Completeness3/5

The server covers core research needs: listing opportunities, detailed scoring, explanation, comparison, protocol risk, and health check. However, there are some minor gaps: no direct way to filter by specific pool ID without first listing, no tool to get historical trends or detailed market info beyond the scoring. But the domain is research-only non-custodial, so a full CRUD lifecycle isn't expected; still, a tool to fetch specific opportunity details without scoring could be missing.

Resources