Yield.xyz AgentKit

Exit a Yield

actions_exit

Construct unsigned transactions to unstake or withdraw from a yield. Does NOT execute — the user must sign each transaction exactly as returned (never modify unsignedTransaction). Amounts are human-readable strings ("1.5" = 1.5 tokens, not wei). Submit transactions in stepIndex order. Call yields_get_balances first to verify the staked balance. To complete a PENDING withdrawal (e.g. claiming after a cooldown) that carries a passthrough value, use actions_manage — exit does NOT accept passthrough. For RWA and ERC-4626 vaults, inspect yields_get → mechanics.arguments.exit.fields[] to discover yield-specific options (e.g. useInstantExecution, useMaxAmount, receiverAddress).

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	No	Amount to withdraw in token units e.g. "1.5". Optional when useMaxAmount is true on supported yields.
`address`	Yes	Wallet address that owns the position.
`yieldId`	Yes	Yield ID from yields_get_all e.g. "ethereum-eth-lido-staking".
`outputToken`	No	Withdrawal token address, for yields that can pay out in more than one token. Required when yields_get → mechanics.arguments.exit.fields[] lists an outputToken field with required: true; that field's options[] holds the valid addresses. Use "0x" to receive the network's native token.
`useAutoClaim`	No	Optional. Available on yields whose exit schema lists this field (e.g. Nest RWA vaults). true = authorize the redeem operator to auto-claim settled async redemptions (adds a one-time per-wallet operator approval), so no manual claim is needed after settlement. false or omitted = claim manually once the redemption settles. Honored only when listed in yields_get exit schema.
`useMaxAmount`	No	Optional. ERC-4626 vault convenience flag. true = redeem the full position (overrides amount). Honored only when listed in yields_get exit schema.
`executionMode`	No	Transaction execution mode. Defaults to "individual". "batched" is reserved for future use — batch mode is not yet available across all yields and should not be used until fully enabled.
`receiverAddress`	No	Optional. ERC-4626 vault convenience field. Address that should receive the underlying token from the redemption. Defaults to the position owner (`address`). Honored only when listed in yields_get exit schema.
`validatorAddress`	No	Validator address to undelegate from. Required for delegation-based yields.
`outputTokenNetwork`	No	Network of the output token e.g. "ethereum". Only for cross-chain withdrawals, where the destination token is not on the vault's own network.
`useInstantExecution`	No	Optional. Available on yields whose exit schema lists this field (e.g. Midas mTBILL, Upshift vaults, Marinade on Solana). true = instant redemption (settles same block, may incur a higher fee — Midas docs quote up to 50 bps for mTBILL). false or omitted = standard redemption (queues; for RWAs settlement may take 1-7 business days — poll yields_get_balances and read the "exiting" entry's `date` field for the expected settlement timestamp). Distinct from executionMode (which controls per-step batching, not redemption path).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`type`	Yes
`amount`	Yes
`intent`	Yes
`status`	Yes
`address`	Yes
`yieldId`	Yes
`amountRaw`	Yes
`amountUsd`	Yes
`createdAt`	Yes
`completedAt`	Yes
`rawArguments`	Yes
`transactions`	Yes
`executionPattern`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations by disclosing that this does not execute, that the user must sign each transaction exactly as returned, that unsignedTransaction must never be modified, that transactions must be submitted in stepIndex order, and that amounts are human-readable strings rather than wei. This is exactly the kind of safety-critical context annotations (readOnlyHint=false, destructiveHint=false) cannot convey.

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?

Front-loaded with the core action and the non-execution warning, then layered with routing and discovery hints. Every sentence carries information, though the final sentence on RWA/ERC-4626 options is dense enough that it competes for attention with the more critical signing constraint.

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 11-parameter, 2-required mutation-adjacent tool with both annotations and an output schema, the description covers the critical gaps: non-execution, signing discipline, step ordering, and the conditional validity of optional fields. Return shape is covered by the output schema, so nothing an agent needs to call this correctly is missing.

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 baseline is 3, but the description adds a genuine discovery workflow: optional fields like useInstantExecution, useMaxAmount and receiverAddress are only valid when listed in yields_get → mechanics.arguments.exit.fields[]. It also reinforces the amount-as-string semantics and the outputToken "0x" convention is left to the schema, keeping the gain modest rather than exceptional.

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?

States a specific verb and resource ("Construct unsigned transactions to unstake or withdraw from a yield") and immediately scopes the boundary against siblings actions_enter and actions_manage. An agent can distinguish this from the deposit and manage paths without opening any schema.

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?

Gives explicit routing rules: call yields_get_balances first to verify the staked balance, use actions_manage for PENDING withdrawals carrying a passthrough value, and inspect yields_get → mechanics.arguments.exit.fields[] for yield-specific options. Both the when and the when-not are named with concrete tool alternatives.

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?