Skip to main content
Glama

Prepare: open a trade account

account_open
Read-onlyIdempotent

Unsigned transaction opening the wallet's version 2 trade account (a TradeAccountV2, one per owner, made by TradeAccountFactoryV2): a trade account with Bailouts, where the owner may post standing offers that pay rescuers to save a position instead of letting it be liquidated (bailout_offer). An agent may be named: an optional second key, never the wallet itself, that can open and close positions within its slippage of the stock's feed, set triggers and cancel the ones it set, post offers within the owner's cap, and send money out to the owner alone. Positions opened inside the account can carry triggers (stop-loss, take-profit, liquidation guard) that anyone can execute for a tip once the price feed confirms them; positions opened from the wallet cannot (close them and open them again inside). Whenever no bailout is owed the owner can take everything out at any time and nobody, Borro included, can stop that; while one is owed, the owner's way out is to pay it (bailout_repay), which lifts the lien at once. A version 1 account the wallet holds stays as it is and keeps working; the other trade tools take either. With a version 2 account open already: agent names a new agent (the old agent's triggers and offers are cancelled with it), revoke_agent: true revokes it at once; account names which of the wallet's accounts to change (default its version 2 one). The owner's settings, on a new account or an open one: the agent's limits (agent_slip_bps, agent_max_tip_bps, agent_max_margin_usdg, agent_daily_loss_usdg, agent_restricted; the agent opens nothing, takes no deposit out, sets no trigger and posts no offer until it has a daily loss budget, and closes whatever the budget; it tips nothing until it has a max tip), agent_bailout_max_usdg (the most an agent's offer may put at stake, 0 by default: none) and max_slip_bps, how far a stop's or a guard's fire bound may widen past its slip (while an offer is live or a bailout is owed it may come down and never up). Simulated from the wallet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet": "<wallet>"
    },
    "name": "account_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNoThe agent's address (optional): a second key that may trade the account and set triggers, never the wallet itself
walletYesThe wallet's address (0x...); the transactions are built for it to sign
accountNoWhich of the wallet's trade accounts to change (default its version 2 account; give its version 1 account to change that one)
max_slip_bpsNoHow far a stop's or a guard's fire bound may widen past its slip over time, in hundredths of a percent (0: no further, up to 1000)
revoke_agentNoWith an account open: revoke its agent at once
agent_slip_bpsNoThe most the agent's trades and triggers may price from the feed, in hundredths of a percent (100 to 300, default 100)
agent_restrictedNotrue: the agent opens on the desks the owner allows (setAgentMay) alone
agent_max_tip_bpsNoThe most tip the agent's triggers may pay executors (a share of the closed notional at the feed, capped (tip_bps, at most 50 basis points, and never more than the USDG the close returns)), in hundredths of a percent (0 to 50, default 0: its triggers then pay none)
agent_daily_loss_usdgNoThe most the agent's fills (and the fires of the triggers it set) may cost against the feed in all each UTC day, renewed at 00:00 UTC (default 0: no agent opens, deposit withdrawals or triggers; its closes run whatever the budget), in whole units as a decimal string, like "1.5"
agent_max_margin_usdgNoThe most equity one position may hold after the agent's trade, or "none" (default none), in whole units as a decimal string, like "1.5"
agent_bailout_max_usdgNoVersion 2: the most an offer the agent posts may put at stake (max_usdg), or "none" (default none: the agent posts no offers), in whole units as a decimal string, like "1.5"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / account
      Added value: +{
      +  "description": "Which of the wallet's trade accounts to change (default its version 2 account; give its version 1 account to change that one)",
      +  "type": "string"
      +}
    • addedInput schema / properties / agent_bailout_max_usdg
      Added value: +{
      +  "description": "Version 2: the most an offer the agent posts may put at stake (max_usdg), or \"none\" (default none: the agent posts no offers), in whole units as a decimal string, like \"1.5\"",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint true, and the description is consistent with a transaction-builder ('unsigned transaction... Simulated from the wallet'), so there is no contradiction. It adds substantial behavior beyond the annotations: bailout lien mechanics, owner exit rights, agent permission boundaries, trigger executability, and what revocation does to the old agent's triggers and offers. It could go one step further and state explicitly that the caller must sign and submit the returned transaction elsewhere.

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

Conciseness2/5

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

The purpose is front-loaded in the first clause, but the remainder is one sprawling run-on paragraph that welds protocol economics (bailout payments, trigger tips, liquidation guards) onto parameter guidance. Sentences are long, comma-chained, and hard to scan, and several clauses describe sibling tools (bailout_repay, bailout_offer, trigger_set) rather than this call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no output schema, the description covers defaults, v1/v2 coexistence, revocation side effects, and the simulate-not-execute nature of the call. Missing only edge-case guidance (errors, whether the wallet needs prior state or funds), which is minor at this complexity level.

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 coverage is 100%, so the baseline is 3 and every parameter is already documented. The description does add real semantics the schema lacks, notably the dependency that the agent can do nothing until agent_daily_loss_usdg is set and tips nothing until agent_max_tip_bps is set, plus the monotonic constraint on max_slip_bps ('may come down and never up'), but these are scattered inside dense prose rather than attached to the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific verb and resource: an unsigned transaction opening the wallet's version 2 TradeAccountV2 via TradeAccountFactoryV2. It also silently doubles as a reconfiguration/agent-management call for an already-open account, which blurs the 'open' framing slightly, but the core action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It distinguishes v1 from v2 accounts ('a version 1 account the wallet holds stays as it is... the other trade tools take either'), which implicitly tells the agent when this tool applies versus siblings like account_trade or account_status. However, it never explicitly states when to call this instead of those siblings, and no prerequisites (funding, existing account, signing flow) are laid out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources