Skip to main content
Glama
R2Rlabs

Reins

Official
by R2Rlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Place an order

place_order

Place a USD-notional perpetual order with risk limits enforced; omit price to cross the spread. Logs order and reason.

Instructions

Place an order sized in USD notional. Every order is checked against the risk limits first; if it breaches one it is refused and nothing reaches the exchange. Omit price for a marketable order that crosses the spread. Both the order and your stated reason are written to a permanent log, including when the order is refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tifNoTime in force. Defaults to Ioc when marketable, Gtc otherwise.
sideYes
priceNoLimit price. Omit to cross the spread and fill now.
reasonYesWhy you are placing this order, in one or two sentences. State the signal or condition you are acting on and why this size. A human will read this later to understand what you were doing, so write what actually drove the decision rather than a generic summary.
symbolYesPerp symbol, for example BTC.
sizeUsdYesNotional size in USD, not asset units.
stopLossNoTrigger price of a stop-loss for this order: below the entry for a buy, above it for a sell. An order that fills now gets a stop under the whole position; a resting order takes its stop with it, placed as it fills, so the position is never unprotected. How far the stop sits decides what the trade risks (distance to stop x size), which get_limits reports as maxTradeRiskUsd: a wider stop needs a smaller order.
reduceOnlyNoTrue if this order may only shrink an existing position.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.6

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that every order is risk-checked first, that a breach causes outright refusal with nothing reaching the exchange, and that both the order and the reason are written to a permanent (irreversible) log even when refused. It does not cover auth/permissions or what happens to partial fills, so it stops short of a 5.

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

Conciseness4/5

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

Four short sentences, front-loaded with the core purpose and followed by the most decision-relevant behaviors (risk refusal, marketable order, permanent logging). Slightly redundant with the schema's own wording on price, but no wasted sentences.

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 8-parameter mutation tool with no annotations and no output schema, the description covers the critical unknowns: the risk gate, the refusal path, and the logging side effect. The main gap is that, with no output schema, it says nothing about what a successful or rejected call returns, and it does not clarify stopLoss-vs-set_stop_loss interaction.

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 88%, so the schema already documents almost every parameter in depth (price, tif, stopLoss, reason, sizeUsd). The description's 'sized in USD notional' and 'omit price for a marketable order' restate facts already present in the property descriptions rather than adding new meaning, so the baseline 3 is appropriate.

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 first sentence gives a specific verb plus resource ('Place an order') and immediately narrows the semantics with 'sized in USD notional', which distinguishes it from the close_position/cancel_order siblings. An agent can identify exactly what this tool does without opening the schema.

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 gives in-tool conditional guidance ('Omit price for a marketable order that crosses the spread'), which is genuinely useful. However, it never addresses how this tool relates to overlapping siblings such as set_stop_loss (despite offering a stopLoss parameter) or close_position, so the when-to-use-this-vs-alternatives question is only partly answered.

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

Deploy Server

Other Tools