Skip to main content
Glama

Prepare: trade through the trade account

account_trade
Read-onlyIdempotent

Unsigned transactions to open or close a short or a leveraged long through the trade account: the same trades as open_short, close_short, open_long and close_long, with the account as the trader. action open_short (symbol, amount, deposit), close_short (symbol: all of the account's short on it), open_long (symbol, margin, leverage) or close_long (symbol, percent). The account pays from its own USDG; when it holds too little, a USDG transfer from the wallet to the account comes before the trade (from the agent's wallet with fund_from_wallet: true alone, since the agent's own USDG then becomes the owner's and can go out to the owner alone, never back to the agent). What a close returns stays in the account as USDG (account_withdraw takes it out). The wallet must be the account's owner or its agent; the agent's trades must price within its slippage of the stock's feed (refused in words when the pool is further off). The agent's opens need room in the daily loss budget the owner set: refused in words when it is 0 or today's loss has reached it (until 00:00 UTC), and by the account when the open's own shortfall against the feed would pass it. Its closes run whatever the budget (any share, within its slip), counted into today's loss, past the budget by at most their own shortfall. The answer says how much of the budget is left.

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>",
      "action": "<action>",
      "symbol": "<symbol>"
    },
    "name": "account_trade"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesopen_short, close_short, open_long or close_long
amountNoopen_short: stock to short, in whole units as a decimal string, like "1.5"
marginNoopen_long: USDG margin, in whole units as a decimal string, like "1.5"
symbolYesA stock on Borro by its ticker, like NVDA or AAPL (markets lists every one)
walletYesThe wallet's address (0x...); the transactions are built for it to sign
accountNoA trade account's address (default: the wallet's own, as its owner; an agent gives its owner's account)
depositNoopen_short: USDG held beyond the sale (optional), in whole units as a decimal string, like "1.5"
percentNoclose_long: how much to close, 1 to 100 (default 100)
leverageNoopen_long: leverage, more than 1, like 1.5
fund_from_walletNoThe agent signing: true to send its own USDG into the owner's account when the account holds too little (it becomes the owner's; it can go out to the owner alone)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the annotations: names the authorization requirement (wallet must be the account's owner or its agent), the slippage refusal against the stock's feed, the owner-set daily loss budget with its exact refusal conditions and 00:00 UTC reset, and the asymmetry that closes run past the budget while opens do not. It also discloses the non-obvious funding path and its irreversible consequence (the agent's USDG becomes the owner's and 'can go out to the owner alone, never back to the agent'), plus that close proceeds stay in the account.

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 correctly, but the middle collapses into long run-on sentences, notably the fund_from_wallet clause ('from the agent's wallet with fund_from_wallet: true alone, since the agent's own USDG then becomes the owner's and can go out to the owner alone, never back to the agent'), which takes several passes to parse. The content earns its place, but the structure does not.

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 a 10-parameter, high-stakes tool with no output schema, the description covers authorization, funding, budget refusals, slippage, and even the return ('The answer says how much of the budget is left'). Remaining gaps are minor: how many unsigned transactions are produced and what the agent must do with them next are left to the wallet parameter's schema text.

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 genuinely new semantics: it maps which parameters apply to which action ('open_short (symbol, amount, deposit)', 'open_long (symbol, margin, leverage)', 'close_long (symbol, percent)') and clarifies that close_short takes only a symbol and closes all of the account's short on it. That per-action coupling is not expressible in the flat schema.

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 and resource ('Unsigned transactions to open or close a short or a leveraged long through the trade account') and immediately disambiguates from four siblings by naming them: the same trades as open_short, close_short, open_long and close_long, with the account as the trader. An agent can tell exactly which tool to pick 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 Guidelines4/5

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

Explicitly positions itself against open_short/close_short/open_long/close_long (account-as-trader vs wallet-as-trader) and points to account_withdraw for moving proceeds out. It also gates the fund_from_wallet path on the agent signing. It stops short of an explicit 'use this when...' rule or a pointer to account_open/account_status for the setup side.

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