Skip to main content
Glama

Prepare: set a stop-loss, take-profit or liquidation guard

trigger_set
Read-onlyIdempotent

Unsigned transaction leaving an order on a position in the trade account, which anyone may execute once the price feed confirms it, for a tip. kind stop (stop-loss: a short's fires at or above price, a long's at or below), take (take-profit: the other way) or guard (liquidation guard: fires when the position's LTV, Morpho's own at the market's oracle, reaches ltv and closes just enough to bring it down to target; target under ltv under the position's LLTV). A stop or take closes percent of the position (default 100). slip_bps: the most the close may come in worse than the feed's price once the trigger is armed and its bound has widened (100 to 300, default 100; the agent's at most its own limit). tip_bps: the executor's tip, 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) (default: the smallest that covers a fire's gas at today's gas and ETH prices, at least 10 from the owner; the agent's at most its max tip, 0 unless the owner set one). The answer says who will fire it: Borro's keeper fires a trigger whose tip covers its fire's gas (taken as 1,100,000 gas until the keeper screens the fire). A trigger whose tip does not cover its fire's gas (a zero tip included, any kind; an agent's trigger pays no tip past its daily loss budget until 00:00 UTC) is fired by Borro's keeper from its root owner's low-tip allowance alone: 0.0001 ETH of gas a UTC day (a few fires), its owner's alone. At most 40 root owners hold one a UTC day, by spending from it: a free one goes to a trigger that is ready and about to be fired, and to no other, in the keeper's owner order (a fire on record, then the least keeper work today, then the oldest trade account) and while its owner is under 200 units of keeper work that day, so the owners whose triggers fire earliest may take all 40 that day. Past it, the trigger is left to other executors. A close under $5 (dust) is left to other executors whatever the tip. Borro's keeper charges all its work on a trigger (screens, checks and simulations, 1 unit each; arms and resets, 5) to the trigger's root owner until the trigger fires, when it is given back. Owners go in this order: owners with a fire on record (a fire Borro's keeper itself sent for them and was paid for, its tip at least the fire's gas, in the last 30 days; fires by the account's own owner or agent, by other executors, or with no tip never count), then the least such work today, then the oldest trade account. Each fire on record also allows its owner one reserved arm or reset. An owner past 200 units a UTC day gets no more unpaid or subsidised keeper work that day (triggers on the low-tip allowance, arms, resets); a trigger whose tip covers its gas is never held back by it. Refused in words when its condition already holds (AlreadyMet) or when the pool cannot close its size within its slip at the price now (NeverFills, quoted at the pool); from the agent, also while its daily loss budget is 0 or today's loss has reached it (OverLossBudget, until 00:00 UTC). An agent-set trigger's tip to an outside executor is paid up to what is left of that budget at the fire and no more (the answer gives what is left now, and who fires it with that cap). expiry_seconds: 0 or left out is good until cancelled. At most 16 live triggers an account; each fires once, then is gone, and a position's triggers go when it closes. Triggers do not fire while the stock market is shut or the feed has not printed within 25 hours; a price crossed while it is shut (a weekend, a holiday) fires once the market opens again, at the price the feed prints then, within the trigger's slip, and after a gap that price can be well past the trigger's. Shows the price now and how far it is from the trigger, and warns when it would fire at once. Simulated from the wallet (the owner or the agent).

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>",
      "symbol": "<symbol>",
      "side": "<side>",
      "kind": "<kind>"
    },
    "name": "trigger_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
ltvNoguard: the LTV it fires at, a fraction like 0.55 or a percent with its sign like "55%"
kindYesstop (stop-loss), take (take-profit) or guard (liquidation guard)
sideYesshort (the account's short on the stock) or long (its leveraged long)
priceNostop or take: the stock's feed price in dollars that fires it, like "190.5"
symbolYesA stock on Borro by its ticker, like NVDA or AAPL (markets lists every one)
targetNoguard: the LTV it closes down to, under ltv
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)
percentNostop or take: how much of the position to close, more than 0 to 100 (default 100)
tip_bpsNoThe executor's tip, 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 (default: the smallest that covers a fire's gas now)
slip_bpsNoThe most the close may come in worse than the feed's price, in hundredths of a percent (100 to 300, default 100)
expiry_secondsNoHow long it stays live, in seconds (0 or left out: until cancelled; at most a year)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations: it explains that the output is an unsigned transaction anyone may execute, the tip and keeper subsidy mechanics, the low-tip allowance, refusal reasons (AlreadyMet, NeverFills, OverLossBudget), the 16-live-trigger cap, dust exclusion, and market-closed behavior. This is unusually complete behavioral disclosure for a mutation-preparation tool.

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 description is a dense wall of text with long run-on sentences and nested parentheticals; critical selection information is buried among keeper-economics details. It is not well front-loaded beyond the first clause and is far larger than needed for a tool-selection decision.

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 12-parameter financial trigger tool with no output schema, it covers creation limits, refusal modes, expiry, market/feed conditions, tip behavior, and what the answer reports (who will fire it, current price, warnings). An agent has enough to call it correctly, even if the presentation is hard to parse.

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

Parameters5/5

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

With 100% schema coverage the baseline is 3, but the description adds real meaning: how kind changes the price direction, percent default and effect, slip_bps bounds, tip_bps defaults and caps, expiry semantics, and that wallet/account are simulated. It also explains the guard's ltv/target relationship in context.

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 title and opening clause state a specific action: prepare an unsigned transaction that sets a stop, take, or guard on a position. It defines all three trigger kinds, so an agent can distinguish it from trigger_cancel, trigger_fire, and trigger_list by the creation semantics, though it never explicitly names those alternatives.

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?

Usage is implied by the purpose and by detailed fire conditions such as market hours, feed staleness, expiry, and account limits. However, there is no explicit when-to-use/when-not section and no routing to the sibling cancel/fire/list tools, so the agent must infer that this is the creation tool.

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