Skip to main content
Glama

Place a paper trade

place_trade
DestructiveIdempotent

Buy YES or NO contracts. Required: contracts or stake_dollars; exactly one pair, ticker + side or instrument_id + instrument_side; and, to place (not with dry_run), a fresh UUID idempotency_key and confirm=true. MARKET fills at the ask now. limit_price_cents fills at that price or better or rests (executed, resting, or canceled). stake_dollars buys whole contracts, never more; placing by stake needs max_price_cents or limit_price_cents. The balance is the limit. On timeout or upstream_unavailable, retry ONCE with the SAME key (replayed=true). Never retry a 4xx. A reused key for a different trade is idempotency_key_reused. get_positions (get_orders for a limit) is ground truth. route=best (default, members) picks the venue. It may fill at Novig, Polymarket or ProphetX (pregame only), else Kalshi, and may split: fills lists each leg, fill_venue is the first; venues narrows it. route=kalshi is one venue. rule_note when the contract differs. dry_run=true places nothing (about 20 a minute). Over the cash: insufficient_balance with details.max_contracts. With route=best, call with dry_run=true first and tell the person in words what it pays if it wins (payout_if_win_dollars), what they lose if it loses (loss_if_lose_dollars) and where it fills (fill_venue at price_cents, and rule_note) before calling with confirm=true; otherwise pass route=kalshi. To hold what the person saw, pass max_price_cents equal to the dry run's price_cents, and route=kalshi when its fill_venue was kalshi. stated_prob_pct (1-99) never changes the fill. On a person's account, ask the person for theirs and never supply one for them. Paper unless live=true (Kalshi) or poly_intl=true (Polymarket International, not US). Pass one. Rules: arena://rules/engine. This server places paper trades only: a call with live or poly_intl is refused (live_not_hosted).

Input Schema

NameRequiredDescriptionDefault
liveNoKalshi order. Not poly_intl.
sideNoThe ticker's side.
routeNoDefault best.
tickerNoA Kalshi ticker, with side.
venuesNo
confirmNoREQUIRED to place: true. Not with dry_run.
dry_runNoPreview; places nothing.
token_idNopoly_intl CLOB token. Omit it and the ticker is mapped.
contractsNoWhole contracts, 1 or more. No cap: your balance is the only limit. One trade records at most 1,000,000,000. Or stake_dollars.
poly_intlNoPolymarket International. Not live, not US.
expires_atNoISO time a gtc order stops resting.
instrument_idNoAn instrument id or slug, with instrument_side.
stake_dollarsNoOr dollars: whole contracts at the ask, never more. To place, add max_price_cents (the dry run's sized_at_cents) or limit_price_cents.
time_in_forceNogtc (default) rests up to 365 days; ioc and fok fill now or come back canceled.
idempotency_keyNoREQUIRED to place: a fresh UUID v4. Not with dry_run.
instrument_sideNoyes holds its label (KC ML).
max_price_centsNoMarket orders: refuse a fill above this (server-enforced).
stated_prob_pctNoThe account holder's probability that the side wins, whole percent (62, not 0.62); ask a person, never guess theirs. Never changes the fill.
limit_price_centsNoA LIMIT order at this price, in the side's own price (no at 40 buys no at 40c).

Output Schema

NameRequiredDescriptionDefault
fillsNo
notesNo
orderNo
routeNo
tradeNo
filledNo
placedNo
statusNo
tickerNo
venuesNo
dry_runNo
warningNo
web_urlNo
edge_ptsNo
fee_noteNo
replayedNo
contractsNo
rule_noteNo
expires_atNo
fill_venueNo
order_typeNo
placed_viaNo
route_noteNo
crosses_nowNo
price_centsNo
ticker_sideNo
hold_dollarsNo
route_reasonNo
instrument_idNo
stake_dollarsNo
time_in_forceNo
walk_fillableNo
sized_at_centsNo
slippage_centsNo
instrument_sideNo
stated_prob_pctNo
walk_vwap_centsNo
instrument_labelNo
limit_price_centsNo
kalshi_price_centsNo
original_created_atNo
walk_slippage_centsNo
loss_if_lose_dollarsNo
payout_if_win_dollarsNo
profit_if_win_dollarsNo
venue_fee_est_dollarsNo
price_improvement_centsNo
requested_stake_dollarsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive/write semantics, and the description adds rich operational context: idempotency_key_reused, replayed=true on retry, upstream_unavailable/timeout handling, insufficient_balance with details.max_contracts, the ~20/min dry_run limit, and refusal of live/poly_intl (live_not_hosted). This far exceeds what the annotations alone convey.

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?

Long, but the length is justified by 19 parameters and dense server rules; required inputs are front-loaded before fill/error behavior. It reads as a run-on wall of text, however, and dry_run is described more than once, costing some crispness.

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 an output schema exists (so return values needn't be documented), the description still supplies the error codes, retry contract, and payout_if_win_dollars/loss_if_lose_dollars/fill_venue fields the agent must relay to a person. Nothing needed to call this correctly is missing.

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 95% so the baseline is 3, but the description adds cross-parameter logic the schema can't express: exactly one of ticker+side or instrument_id+instrument_side, stake_dollars needing max_price_cents or limit_price_cents, and pass-one-of live/poly_intl. It stops short of explaining a few params (venues, token_id, expires_at) but clearly exceeds schema field docs.

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?

Opens with a specific verb and resource ('Buy YES or NO contracts') and is instantly distinguishable from siblings like sell_trade and cancel_order. The trade-execution action and its paper-only nature are stated up front.

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?

Explicit when-to-use and when-not: it routes the agent through dry_run + confirm for route=best and says to pass route=kalshi otherwise, gives retry guidance (retry once with the same key, never retry a 4xx), and names get_positions/get_orders as ground truth. Alternatives and preconditions are all present.

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