Skip to main content
Glama

Place a trigger order

create_order
Destructive

Place a resting order that executes later when its condition is met: a limit order, take-profit, stop-loss, trigger buy, or a DCA schedule. ⚠️ THIS SPENDS REAL MONEY. It submits a real transaction from the user's wallet using real funds and cannot be undone. Confirm the exact amount, token and network with the user in plain language, and get their explicit go-ahead, BEFORE calling this. It commits the user's funds to a trade that can fire while they are not looking. Read back the full order — type, token, amount, every price — and get an explicit yes before calling.

Trade limits: a SELL order (TP, SL, limit or DCA sell into the USD stable) never counts toward or is blocked by maxTradeUsd / dailyVolumeUsd. A BUY order is checked against both and reserves its USD value in the daily volume when placed; if it is cancelled, expires or fails, the unfilled part is given back.

order_type selects what to place, and which price arguments are required:

  • limit_buy — buy when the price falls to limit_price. Needs limit_price. amount is the amount of the FUNDING asset to spend.

  • limit_sell — sell when the price rises to limit_price. Needs limit_price. amount is the amount of the held token to sell.

  • tp_only — take profit: sell when the price rises to take_profit_price. Needs take_profit_price.

  • sl_only — stop loss: sell when the price falls to stop_loss_price. Needs stop_loss_price.

  • trigger_buy — buy when the price DROPS to the trigger. The trigger goes in stop_loss_price; no other price. amount is the FUNDING asset to spend.

  • sl_and_tp — a BRACKET: stop loss AND take profit on one position in ONE call. Needs stop_loss_price and take_profit_price; amount is the held token, and both legs cover it (whichever fires first sells it). It places TWO orders, a stop loss and a take profit: the result says order_type: "sl_and_tp" and lists them in legs (order_id + order_type each; also stop_loss_order_id / take_profit_order_id). When one fills, Moby cancels the other. If ONE leg could not be placed, failed_leg says which and failed_leg_error why — the other leg is LIVE and stays; place only the missing one with sl_only / tp_only, never the bracket again.

  • To protect a position on BOTH sides use sl_and_tp, or tp_only and sl_only as two calls (back to back is fine). Cancelling one leg does NOT cancel the other. When one FILLS and that sells the whole position, Moby cancels your remaining exits on that token within a minute or two (a full quick_sell cancels them in the same call); after a PARTIAL exit the other stays live. get_my_orders (status="terminal") then shows it with cancel_reason.

  • dca_buy / dca_sell — split the trade into order_count equal slices interval_seconds apart. Needs both, and NO price argument. All prices are USD prices of the token. amount is always what the user SPENDS: the funding asset on a buy, the token itself on a sell. Refusals that are NOT argument problems: no_market (no sell route for a new token yet — wait and retry the same call later) and stop_above_market / tp_below_market (price already past the trigger — re-check the price and pick a new trigger). Deciding to retry or re-place is your job; Moby does not retry or re-arm for you. To CLOSE or trim a position at market now, use quick_sell — not an order here. EXITS ARE YOURS: Moby attaches no automatic TP/SL to your buys. Place a position's take-profit / stop-loss here (sl_and_tp, or tp_only / sl_only) after the buy. SOL positions: use quick_sell; TP/SL on SOL is not supported yet.

Input Schema

NameRequiredDescriptionDefault
amountYesHow much to SPEND, in whole token units: the funding asset on a buy, the held token on a sell.
networkNosolana
rationaleNoOptional. Your 2–4 line thesis: why this coin, why now, who's in it, what breaks it. Stored with the trade and shown to the user; ≤500 chars.
order_typeYesWhich kind of order to place. See the tool description for what each one needs.
limit_priceNoUSD limit price. Required for `limit_buy` and `limit_sell`.
order_countNoHow many DCA slices to split the amount into. Required for `dca_buy` and `dca_sell`.
token_addressYesContract address of the token the order is about.
stop_loss_priceNoUSD price at which to stop out. Required for `sl_only` and `sl_and_tp`; for `trigger_buy` it is the price the buy fires at when the price drops to it.
interval_secondsNoSeconds between DCA slices. Required for `dca_buy` and `dca_sell`.
take_profit_priceNoUSD price at which to take profit. Required for `tp_only` and `sl_and_tp`.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark this as destructive, open-world, and non-idempotent, but the description adds critical context: it spends real money, submits a real wallet transaction, cannot be undone, and requires explicit user confirmation. It also discloses trade-limit behavior, buy-vs-sell volume accounting, bracket leg behavior, cancellation interactions, refusal reasons, and that Moby does not retry or re-arm orders.

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

Conciseness5/5

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

The description is long but appropriately sized for a destructive tool with eight order types and complex bracket/DCA behavior. The safety warning is front-loaded, and the order-type rules are organized as a scannable list with no obvious 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?

Given the rich annotations, 90% schema coverage, and an output schema, the description fills the remaining behavioral gaps: confirmation requirements, trade limits, bracket leg results, partial-exit cancellation behavior, refusal handling, and SOL limitations. An agent has enough information to invoke this tool correctly and safely.

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?

Schema coverage is high, but the description adds substantial conditional meaning beyond the schema: order_type determines which price arguments are required, amount means the funding asset on buys and the held token on sells, trigger_buy uses stop_loss_price, and DCA orders require order_count and interval_seconds with no price argument. It also clarifies that all prices are USD prices of the token.

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?

The description states a specific verb and resource: place a resting order that executes later when a condition is met. It enumerates the exact order types and distinguishes this tool from quick_sell for immediate market closes, so an agent can tell it apart from siblings without opening schemas.

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?

It explicitly says when to use this tool versus alternatives: use quick_sell to close or trim at market now, and place TP/SL here after a buy because Moby attaches no automatic exits. It also explains which order_type to choose for each trading intent and how to handle bracket failures.

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