mcp-server

write_account_automations_delta

Idempotent

Apply an incremental change to an Arcadia account's automations, switching individual ones on or off without restating the rest. Returns the unsigned setAssetManagers transaction to sign.

Instructions

Apply an explicit change to an account's automations and return the unsigned setAssetManagers transaction. Unlike write_account_automations this is a delta, not a full desired state: automations you do not mention are left untouched. Use it to switch one automation on or off without restating the others.

The enable array takes intents to switch on (same shapes as write_account_automations). To turn an automation OFF, call read_asset_manager_current, take the address of the manager serving it, and pass that address in the disable array: an intent with enabled: false in enable is rejected because the backend would ignore it. Superseded or unreadable managers still set on the account are force-disabled in the same transaction regardless.

Intents:

compound_fees: reinvest earned fees/rewards back into the LP. Optional 'tokens' scopes it per yielding token. A staked reward that is not a pool token is swapped in via CowSwap automatically.
claim_rewards: claim yield out. config.mode as_earned pays the tokens as-is, convert_to swaps them to config.buy_token via CowSwap. config.convert_tokens converts only a subset and claims the rest as-earned. config.destination account or wallet.
add_to_lp: fold idle pool-token balances (deposits, rebalance leftovers) back into the LP. Opt-in per token.
claim_merkl: auto-claim Merkl incentive rewards. Independent of the compounder/claimer/cowswapper triad and needs no position context.
rebalance: reposition the LP. strategy out_of_range (default), take_profit (runs on the dedicated profit-taker contract), or protocol_owned_liquidity.

Pass position_id (from assets[] in read_account_info) and the backend fills in protocol, is_staked, token0, token1 and reward_tokens for you; anything you pass explicitly wins. claim_merkl needs no position context.

Rules the backend enforces (a violation is returned as an error, never written on-chain):

Every yielding token must be assigned to exactly one of compound_fees or claim_rewards. Scoping one to a subset without covering the rest is rejected, and no token may be in both.
A wallet or custom-recipient payout requires a pure as-earned claim: nothing converted, and every yielding token claimed. Converts settle in the account.
convert_tokens must be a subset of the claimed tokens, and buy_token cannot be a compounded token, a converted token, or an add_to_lp folded token.
Each intent kind may appear only once, and a token list must not be empty or name a token the position does not yield.

Input Schema

Name	Required	Description
`owner`	No	Account owner EOA. Used to resolve wallet payout targets.
`enable`	No	Intents to switch on. Leave empty when only disabling. This array cannot turn anything off: an entry with enabled: false is rejected, use `disable` instead.
`token0`	No	Pool token0 address.
`token1`	No	Pool token1 address.
`disable`	No	Asset-manager addresses to switch off, as returned by read_asset_manager_current.
`chain_id`	No	Chain ID: 8453 (Base), 130 (Unichain), 10 (Optimism), or 4663 (Robinhood)
`protocol`	No	Position's DEX protocol. Only needed when position_id is omitted. Accepts the dex_protocol values the read tools return (slipstream, staked_slipstream_v3, uniV3, metadexcl_v1, staked_metadexcl_v1, ...), which imply is_staked, as well as the canonical slipstream_v1 / uniswap_v3 spellings. metadexcl_v1 is Aero CL; staked_metadexcl_v1 covers both the staked module and the wrapper.
`is_staked`	No	Whether the LP position is staked. Implied by a staked_* protocol value.
`position_id`	No	LP position (NFT) id, as listed in assets[] by read_account_info. Supply this and the backend fetches protocol, staked flag, tokens and reward tokens for you. Strongly preferred over passing the position fields by hand.
`reward_tokens`	No	Staking reward token addresses.
`account_address`	Yes	Arcadia account address

Output Schema

Name	Required	Description	Default
`diff`	No
`plan`	Yes
`valid`	Yes
`errors`	Yes
`warnings`	Yes
`description`	Yes
`transaction`	No
`preview_only`	No
`human_summary`	Yes
`simulation_url`	No
`no_changes_needed`	No
`tenderly_sim_status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.0Oct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, idempotent, open-world write. The description adds real behavior beyond that: the return is an unsigned setAssetManagers transaction, backend rule violations are returned as errors and never written on-chain, and superseded/unreadable managers are force-disabled in the same transaction. It doesn't cover what happens to automation state on partial failure, but the transaction-semantics note is substantive.

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?

It is long, but for a five-way intent union with backend invariants the length is largely justified, and it is front-loaded: the delta-vs-full-state contrast and the enable/disable split come before the intent catalogue. Some sentences restate schema text and could be trimmed without loss.

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?

An output schema exists, so return values need not be explained, and everything else an agent needs — prerequisite reads, disable procedure, cross-field validation rules, and the position context auto-fill — is present. Nothing material is missing for correct invocation of a complex write tool.

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 would be 3; the description still contributes by explaining the intent semantics (compound_fees, claim_rewards, add_to_lp, claim_merkl, rebalance) as a coherent narrative and by clarifying that position_id lets the backend fill protocol/tokens/reward_tokens while explicit values win. Much of this overlaps the schema, so it earns only a modest lift over baseline.

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 ('Apply an explicit change to an account's automations') and immediately contrasts with the sibling write_account_automations: delta vs full desired state. An agent can tell which of the two write tools to pick from the first sentence alone.

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 when-to-use ('switch one automation on or off without restating the others') and a concrete when-not plus alternative (full-state writes go to write_account_automations). It also spells out the disable workflow — read_asset_manager_current, take the address, pass it in `disable` — and states that enabled:false inside `enable` is rejected.

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

Deploy Server