Skip to main content
Glama
arcadia-finance

mcp-server

by arcadia-finance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

write_account_automations

Idempotent

Configure an account's automations from intents to get a signable setAssetManagers transaction, or preview-validate a combination without one.

Instructions

Configure an account's automations from a list of intents and return the unsigned setAssetManagers transaction. The backend resolves which asset managers each intent needs, validates that the combination is compatible, encodes the metadata and builds the calldata, so you describe the desired outcome rather than the contracts.

With mode 'save' (the default) the intents array is the complete desired state: the backend diffs it against what is currently enabled, so any automation you leave out is DISABLED by the returned transaction. Pass a single intent with enabled: false to turn everything off.

Mode 'preview' validates and resolves the intents WITHOUT reading chain state and returns no transaction, because its calldata carries no disable entries and would only partially apply the state. Use it to check a combination is legal or to show a plan; use 'save' to get something signable. To toggle one automation without restating the rest, use write_account_automations_delta.

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.

Returns { valid, errors, warnings, human_summary, plan, diff, transaction }. When a compatibility rule fires the call returns an error and no transaction: read errors[].reason, adjust the intents and retry. There is deliberately no transaction when the account already matches the request (no_changes_needed), when the Tenderly simulation predicts a revert (an error), or in preview mode (preview_only). Call read_asset_manager_intents first to see which intents this account can enable.

Input Schema

NameRequiredDescriptionDefault
modeNosave diffs against on-chain state and returns a signable transaction that also disables anything omitted. preview resolves and validates only, returning a plan and no transaction.save
ownerNoAccount owner EOA. Used to resolve wallet payout targets.
token0NoPool token0 address.
token1NoPool token1 address.
intentsYesComplete desired automation state. In save mode anything omitted is disabled, so include every automation to keep. A single intent with enabled: false disables all automations.
chain_idNoChain ID: 8453 (Base), 130 (Unichain), 10 (Optimism), or 4663 (Robinhood)
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, 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_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

NameRequiredDescriptionDefault
diffNo
planYes
validYes
errorsYes
warningsYes
descriptionYes
transactionNo
preview_onlyNo
human_summaryYes
simulation_urlNo
no_changes_neededNo
tenderly_sim_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

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 the key footgun that the intents array is a full desired state and anything omitted is DISABLED, plus that a single enabled:false turns everything off. It also enumerates the backend-enforced compatibility rules, the error-first behavior (errors[].reason, adjust and retry), and the three cases that deliberately return no transaction (no_changes_needed, simulated revert, preview_only). Only note: destructiveHint=false arguably understates a call that removes automations, but the description itself surfaces that risk.

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?

Long but front-loaded: the core action and the save/preview distinction come first, then intents, then validation rules, then return behavior. Every block is substantive, but several rules (token assignment, recipient/convert restrictions) are restated from the schema, which is some avoidable length.

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 a complex 11-parameter mutation with nested intent unions it covers everything an agent needs: intent semantics, mode trade-offs, autofill behavior, validation failures, and the returned { valid, errors, warnings, human_summary, plan, diff, transaction } shape, which reinforces rather than replaces the output 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, but the description earns more by explaining what each intent kind means (compound_fees, claim_rewards, add_to_lp, claim_merkl, rebalance), what position_id auto-fills (protocol, is_staked, token0/token1, reward_tokens), and the cross-intent constraints. Some of that overlaps the already-detailed schema descriptions, which caps it below 5.

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: "Configure an account's automations from a list of intents and return the unsigned setAssetManagers transaction." It immediately separates itself from write_account_automations_delta (delta toggling) and read_asset_manager_intents (capability discovery), so an agent can pick correctly without opening a 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?

Explicitly states when to use 'save' (something signable) versus 'preview' (validate/show a plan, no transaction, does not read chain state), and when to switch to write_account_automations_delta for a single toggle. It also prescribes a prerequisite: call read_asset_manager_intents first to see what the account can enable.

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

Deploy Server

Other Tools