Yield.xyz AgentKit

List Yield Opportunities

yields_get_all

Read-onlyIdempotent

Discover yield opportunities across all supported networks and protocols. Use this to find yield IDs before calling yields_get, actions_enter, or any balance/validator tools. Filter by network, token symbol, or type to narrow results. For RWA yields (types ["real_world_asset"]) each item also includes a full kyc object (eligibility, investor tiers, jurisdictions, authorizeUrl) — read it directly instead of calling yields_get per yield.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	Server-side sort order. Results are returned pre-sorted by the server, do not re-sort client-side.
`limit`	No	Max results per page (1-50, default 20).
`token`	No	Token symbol e.g. "ETH", "USDC" or a contract address, to filter by output/reward token.
`types`	No	Filter by one or more yield types e.g. ["staking", "lending"]. Values: staking, fixed_yield, lending, restaking, vault, concentrated_liquidity_pool, liquidity_pool, real_world_asset.
`offset`	No	Pagination offset. Increment by limit to fetch the next page.
`search`	No	Free-text search across yield names, token names, provider names, and metadata descriptions.
`networks`	No	Filter by one or more networks e.g. ["base", "arbitrum"] or ["ethereum"]. Use a single-element array for one network. Never make multiple calls per network — pass all networks in one array.
`yieldIds`	No	Batch fetch up to 100 specific yields by ID.
`providers`	No	Filter by one or more provider IDs e.g. ["lido", "aave"].
`inputTokens`	No	Filter by one or more accepted deposit token symbols or addresses e.g. ["USDC"] or ["USDC", "ETH"]. Yields matching any of the tokens are returned.
`hasWarmupPeriod`	No	Filter by whether the yield has a warmup period.
`hasCooldownPeriod`	No	Filter by whether the yield has a cooldown period.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds real behavioral context beyond that: RWA-type results carry an embedded kyc object with eligibility, tiers, jurisdictions, and authorizeUrl. It does not discuss pagination limits or sort behavior, but those live in the schema.

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?

Four sentences, each carrying a distinct payload: purpose, sequencing precondition, filtering summary, and the RWA special case. The most decision-relevant information (use this before yields_get) comes early with no preamble.

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?

No output schema exists, and the description compensates for the main non-obvious return shape by describing the RWA kyc object inline. For a 12-parameter but zero-required discovery tool this is close to complete; only the page-size/offset loop semantics are left entirely to the schema.

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 coverage is 100%, so the baseline is 3; the description earns the extra point by tying the 'types' parameter to a concrete behavioral consequence (real_world_asset yields return a kyc object) that the schema alone does not convey. It also summarizes the filter axes (network, token symbol, type) as a usable mental model.

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?

Opens with a specific verb and resource ('Discover yield opportunities across all supported networks and protocols') and explicitly distinguishes itself from the sibling yields_get, which retrieves a single yield by ID. An agent can tell immediately this is the discovery/list surface.

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?

Explicitly states the downstream dependency: get yield IDs here before calling yields_get, actions_enter, or balance/validator tools. It also gives a clear when-not-to-call rule for RWA yields ('read it directly instead of calling yields_get per yield'), which prevents an N+1 pattern.

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

All Yield.xyz AgentKit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?