mcp-server

write_account_stake

Idempotent

Stake, unstake, or claim rewards for an LP position in one atomic transaction to manage concentrated liquidity positions across supported chains.

Instructions

Flash-action: stake, unstake, or claim rewards for an LP position in one atomic transaction. Use the action parameter to select the operation. asset_address is the position manager contract: pass the non-staked PM address when staking, or the staked PM address when unstaking. The returned calldata is time-sensitive, sign and broadcast within 30 seconds. If the transaction reverts due to price movement, rebuild and sign again immediately (retry at least once before giving up). Tenderly simulation may not be available for this endpoint. Verify the position exists with read_account_info before signing. Aero CL (metadexcl_v1): spot accounts stake through the Arcadia wrapper, margin accounts through the staked module, on Base, Optimism and Robinhood.

Input Schema

Name	Required	Description
`action`	Yes	Action to perform
`asset_id`	Yes	NFT token ID of the LP position
`chain_id`	No	Chain ID: 8453 (Base), 130 (Unichain), 10 (Optimism), or 4663 (Robinhood)
`asset_address`	Yes	Position manager contract address
`account_address`	Yes	Arcadia account address

Output Schema

Name	Required	Description	Default
`after`	No
`before`	No
`description`	No
`transaction`	Yes
`price_checks`	No
`tenderly_sim_url`	No
`tenderly_sim_status`	No
`expected_value_change`	No
`expected_value_change_unavailable`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.1Oct 27, 2026

addedOutput schema / properties / expected_value_change_unavailable
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / price_checks

Added value: +{
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "pool": {
+        "type": "string"
+      },
+      "status": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "pool",
+      "status"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Addedv0.6.0Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations. It discloses that returned calldata is time-sensitive with a 30-second sign/broadcast window, that Tenderly simulation may be unavailable for this endpoint, and protocol-specific routing (Aero CL metadexcl_v1: spot accounts via the Arcadia wrapper, margin accounts via the staked module). These are operational facts an agent cannot derive from the schema or the readOnly/openWorld hints.

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 action framing, then prerequisites, retry policy, and protocol caveat in a sensible order; virtually every clause carries information. It runs long as a single dense block and the trailing Aero CL note is harder to parse than the rest, but there is no filler.

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 mutating, time-sensitive transaction builder, the description covers the selection logic, prerequisite lookup, timing constraint, retry behavior, simulation caveat, and protocol routing. An output schema exists and the description already characterizes the return as calldata, so return-value detail need not be repeated.

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 real meaning beyond it: `asset_address` is overloaded to mean the non-staked PM when staking and the staked PM when unstaking, which the schema text ('Position manager contract address') does not convey. Chain support is echoed from the schema rather than extended, so it stops short of a 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 set (stake, unstake, claim) plus the resource (LP position) and the atomic-transaction framing, so the agent knows exactly what is built. It is clearly distinguishable from siblings like write_account_add_liquidity or write_account_remove_liquidity, which operate on liquidity rather than an existing LP position NFT.

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 routes the agent via the `action` enum and states which `asset_address` to pass for staking vs unstaking (non-staked PM vs staked PM). It also names a prerequisite (verify the position exists with read_account_info before signing) and prescribes failure handling: retry at least once immediately after a price-movement revert.

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

Deploy Server