Skip to main content
Glama
arcadia-finance

mcp-server

write.account.automations_delta

Idempotent

Apply targeted updates to an account's automations: enable or disable specific intents while leaving unmentioned ones untouched, then get the unsigned setAssetManagers transaction.

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

TableJSON Schema
NameRequiredDescriptionDefault
ownerNoAccount owner EOA. Used to resolve wallet payout targets.
enableNoIntents to switch on. Leave empty when only disabling. This array cannot turn anything off: an entry with enabled: false is rejected, use `disable` instead.
token0NoPool token0 address.
token1NoPool token1 address.
disableNoAsset-manager addresses to switch off, as returned by read.asset_manager.current.
chain_idNoChain ID: 8453 (Base), 130 (Unichain), or 10 (Optimism)
protocolNoPosition's DEX protocol. Only needed when position_id is omitted. Accepts the dex_protocol values the read tools return (slipstream, staked_slipstream_v3, uniV3, ...), which imply is_staked, as well as the canonical slipstream_v1 / uniswap_v3 spellings.
is_stakedNoWhether the LP position is staked. Implied by a staked_* protocol value.
position_idNoLP 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_tokensNoStaking reward token addresses.
account_addressYesArcadia account address

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNo
planYes
validYes
errorsYes
warningsYes
descriptionYes
transactionNo
preview_onlyNo
human_summaryYes
simulation_urlNo
no_changes_neededNo
tenderly_sim_statusNo
Behavior5/5

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

Beyond annotations, the description discloses key behaviors: it returns an unsigned transaction (not an on-chain execution), disable entries with enabled:false are rejected, superseded/unreadable managers are force-disabled in the same transaction, and validated rules are returned as errors never written on-chain. It also discloses implicit CowSwap swaps for reward tokens. This far exceeds the minimal readOnly/destructive/idempotent flags in the annotations.

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?

The description is long but well-structured: core purpose first, then enable/disable mechanics, then per-intent bullet summaries, then position_id guidance, then backend-enforced rules. It is appropriately sized for a complex tool, though a few points are duplicated (e.g., 'claim_merkl needs no position context' appears twice) and the intent bullet summaries partially repeat schema descriptions. Overall it is readable and front-loaded.

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?

Given the tool's complexity, the output schema existing, and the rich input schema, the description is exceptionally complete. It covers transaction return type, error behavior, how to disable, force-disabling, the distinction between full-state and delta, all intent kinds, positional context handling, and hard backend rules. An agent has all necessary context to invoke the tool correctly without reading external documentation.

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, but the description adds meaningful orientation beyond the schema: it clarifies that the enable array cannot turn anything off, that the disable array takes addresses from read.asset_manager.current, and that position_id is strongly preferred and auto-fetches protocol/token context. It also explains shared constraints like the 'pure as-earned rule' and the 'every yielding token must be assigned' rule. This adds value, though the schema already contains detailed per-field descriptions.

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 opens with a specific verb and resource: 'Apply an explicit change to an account's automations and return the unsigned setAssetManagers transaction.' It immediately distinguishes itself from the sibling write.account.automations by stating this is a delta, not a full desired state, and that unmentioned automations are left untouched. This clearly communicates both what the tool does and how it differs from similar tools.

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 gives explicit when-to-use guidance: 'Use it to switch one automation on or off without restating the others.' It also explains the alternative (write.account.automations) and describes the exact workflow for disabling, including calling read.asset_manager.current to fetch manager addresses. It further clarifies which inputs are rejected and how force-disabling works, giving the agent clear decision rules.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/arcadia-finance/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server