Skip to main content
Glama

Arcadia Finance

by io.github.arcadia-finance
OverviewDiscussionsAdmin

read_account_info

Read-onlyIdempotent

Get full overview of an Arcadia account: health factor, collateral value, debt, deposited assets, liquidation price, and automation status. Health factor = 1 - (used_margin / liquidation_value): 1 = no debt (safest), >0 = healthy, 0 = liquidation threshold, <0 = past liquidation. Higher is safer. The automation object reports which asset managers are enabled (rebalancer, compounder, yield_claimer, cow_swapper, merkl_operator, gas_relayer), each as the position's dex_protocol when protocol-specific or true when account-level, plus inferred_intents (the automations those managers add up to), merkl claim state, and deprecated_managers for any superseded deployment still set on the account. Superseded managers should be cleared: write_account_automations disables them as part of a save. For the full decoded per-manager config use read_asset_manager_current. LP positions in assets[] include a dex_protocol field (slipstream, slipstream_v2, slipstream_v3, metadexcl_v1, staked_slipstream, staked_slipstream_v2, staked_slipstream_v3, staked_metadexcl_v1, uniV3, uniV4). metadexcl_v1 is Aero CL, live on Base, Optimism and Robinhood for spot and margin accounts. Slipstream V2 is Base-only. V3 is available on Base and Optimism. Unichain supports Slipstream V1, uniV3 and uniV4. To configure automations, prefer passing the position's id as position_id to write_account_automations, which resolves the protocol and tokens for you; the dex_protocol value is also accepted directly as its protocol param. Numeric fields without a _usd suffix are in the account's numeraire token raw units (divide by 10^decimals: 6 for USDC, 18 for WETH, 8 for cbBTC). Fields ending in _usd are in USD with 18 decimals (divide by 1e18). health_factor is unitless. Asset amounts are raw token units. To list all accounts for a wallet, use read_wallet_accounts.

Input Schema

NameRequiredDescriptionDefault
chain_idNoChain ID: 8453 (Base), 130 (Unichain), 10 (Optimism), or 4663 (Robinhood)
account_addressYesArcadia account address

Output Schema

NameRequiredDescriptionDefault
overviewYes
automationNo
context_notesNo
account_versionYes
liquidation_priceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
    • addedOutput schema / properties / automation / propertyNames
      Added value: +{
+  "type": "string"
+}
    • changedOutput schema / properties / liquidation_price / anyOf
      Previous value: -[
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / overview / anyOf
      Previous value: -[
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / chain_id / description
      Previous value: -"Chain ID: 8453 (Base), 130 (Unichain), or 10 (Optimism)"New value: +"Chain ID: 8453 (Base), 130 (Unichain), 10 (Optimism), or 4663 (Robinhood)"
  3. Changed1 schema field changed
    • changedInput schema / properties / chain_id / description
      Previous value: -"Chain ID: 8453 (Base) or 130 (Unichain)"New value: +"Chain ID: 8453 (Base), 130 (Unichain), or 10 (Optimism)"
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent/non-destructive; the description adds substantial behavioral context beyond them — the health-factor formula and its 1/0/<0 semantics, the shape of the automation object including inferred_intents, merkl state and deprecated_managers, and that superseded managers are cleared on save. That is exactly the depth a state-reading tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the overview and the health-factor explanation, but it then spends many sentences enumerating ten dex_protocol identifiers and spelling out unit conversions for return fields that the output schema already covers. Valuable but not tightly earned — a third of the text is reference material repeated per call.

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 read tool over a complex DeFi account state, nothing an agent needs is missing: the interpretation of health_factor, the unit conventions for raw vs _usd fields, the meaning of the automation sub-object, and the sibling routing are all present. Any over-explanation of returns is redundant rather than incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with chain_id documenting the accepted chain values and account_address defined, so the schema carries the parameter burden. The description adds no parameter-level detail (it discusses units for returned fields, not inputs), which places it at the 3 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 ('Get full overview of an Arcadia account') and enumerates exactly the resources returned: health factor, collateral value, debt, deposited assets, liquidation price, automation status. This clearly separates it from siblings read_wallet_accounts, read_account_history and read_account_pnl.

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?

Names alternatives with explicit conditions: use read_wallet_accounts to list accounts for a wallet, read_asset_manager_current for full decoded per-manager config, and write_account_automations to configure or clear automations. The agent knows which sibling to pick without inferring.

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

All Arcadia Finance toolsInspect
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