Skip to main content
Glama
Pit Officer

Pit Officer

Official

set_limit

Creates or tightens risk barriers for rate limits, order-size caps, P&L kill switches, and Spot Funds enforcement, then returns the stored barrier; requests that loosen risk are refused.

Instructions

Create a risk barrier, or make the one stored at the same address stricter, and return it as stored. policy names the kind - rate_limit, order_size_limit, one of the P&L-bound kill switches spot_funds_pnl_bounds_kill_switch (realized P&L), spot_funds_unrealized_pnl_bounds_kill_switch (unrealized P&L) and spot_funds_total_pnl_bounds_kill_switch (total P&L), or spot_funds_limit_mode - and the other arguments are that kind's fields; a field of another kind is refused with validation. Anything that loosens risk is refused with loosening_refused and changes nothing. A barrier that replaces the one at its address must be no looser: for rate_limit no more orders and, on the broker and asset scopes, the same window, on the account and account_asset scopes a window no shorter; for order_size_limit every current cap kept and none raised; for a P&L-bound kill switch the same currency, every current bound kept, the lower bound no lower and the upper bound no higher. A new account_underlying_asset or account_settlement_asset cap must be no higher than the underlying_asset or settlement_asset cap on the same asset that it overrides, and a new account_group or account bound must be in the currency of, and no looser than, the bound it takes over from: for a group the global bound, for an account the bound that applies to it now. The first order-size barrier is refused while any rate-limit barrier is configured. spot_funds_limit_mode is the Officer policy that decides whether Spot Funds checks funds, on the global scope only, with the one field mode: enforce (Check funds) refuses an order that lacks funds or holdings; track_only (Accounting without blocking) does not refuse on funds but records every hold, so balances and positions may go negative. Until first set the mode is enforce; the switch to track_only is refused with loosening_refused, and the switch to enforce resets no balance. P&L bounds, rate and order-size barriers apply in both modes. No barrier can be removed; to switch Spot Funds back to Check funds, set spot_funds_limit_mode with mode enforce. Mutates Officer control-plane config; protected and disabled by default.

Input Schema

NameRequiredDescriptionDefault
modeNospot_funds_limit_mode: enforce (Check funds) or track_only (Accounting without blocking); the switch from enforce to track_only is refused with loosening_refused
assetNorate_limit and order_size_limit: asset code, for a scope with an asset axis - the underlying asset for a quantity cap, the settlement asset for a notional cap; omitted otherwise
scopeYesBarrier scope: broker, asset, account or account_asset for rate_limit; broker, underlying_asset, settlement_asset, account_underlying_asset or account_settlement_asset for order_size_limit; global, account_group or account for the P&L-bound kill switches; global for spot_funds_limit_mode
policyYesBarrier kind: rate_limit, order_size_limit, spot_funds_pnl_bounds_kill_switch, spot_funds_unrealized_pnl_bounds_kill_switch, spot_funds_total_pnl_bounds_kill_switch or spot_funds_limit_mode
accountNoAccount code, for a scope with an account axis; omitted otherwise
currencyNoP&L-bound kill switches: code of an existing asset that denominates both bounds
windowMsNorate_limit: window in milliseconds, fixed on the broker and asset scopes and rolling on the account and account_asset scopes
maxOrdersNorate_limit: most orders admitted within the window
lowerBoundNoP&L-bound kill switches: lower P&L bound as an exact decimal string in plain notation, without an exponent
upperBoundNoP&L-bound kill switches: upper P&L bound, written as lowerBound is; at least one bound is set
maxNotionalNoorder_size_limit: per-order notional cap as an exact decimal string; the settlement-asset scopes carry this one only
maxQuantityNoorder_size_limit: per-order quantity cap as an exact decimal string; a broker barrier carries either cap or both, the underlying-asset scopes this one only
accountGroupNoP&L-bound kill switches: account group code, for the account_group scope
missingAccountNoNeeded when account is named: create or reject; for an account that does not exist yet, create is refused for an agent with loosening_refused, and reject fails the call instead; ignored otherwise

Output Schema

NameRequiredDescriptionDefault
rateLimitNo
orderSizeLimitNo
spotFundsLimitModeNo
spotFundsPnlBoundsLimitNo
spotFundsTotalPnlBoundsLimitNo
spotFundsUnrealizedPnlBoundsLimitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.4/5.0
Behavior5/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 so: it discloses that the tool mutates control-plane config, that it is protected and disabled by default, that refusals change nothing, the precise no-looser invariants per policy kind, the ordering constraint against the first order-size barrier, and the semantics of the enforce/track_only switch. This is unusually rich behavioral disclosure for a mutation tool.

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?

The intent is front-loaded and nearly every sentence conveys a distinct invariant, but the body is one dense run-on paragraph with repetitive phrasing ('no looser', 'every current cap kept') that is hard to parse on a first read. Bulleted per-policy invariants would preserve the content with far better scannability.

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?

Given 14 parameters, an output schema, and a large constraint surface, the description covers refusals, replacement semantics, mode transitions, and the default-protected state. The main residual gap is a pointer to the read-side tool for inspecting current barriers, which an agent would otherwise have to infer from the sibling list.

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 per-field descriptions already do heavy lifting, but the description adds real cross-field meaning: policy selects the kind and the remaining arguments are that kind's fields, with fields of another kind rejected by validation. That conditional dispatch across 14 params is not derivable from the schema alone. It stops short of mapping each scope value to its axis explicitly in the prose (the schema carries that).

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 clause names a precise verb pair (create / make stricter) and the resource (risk barrier), and immediately enumerates the policy kinds it governs. An agent can tell this is the write path for barriers — the counterpart to get_limits/get_spot_funds_limit_mode — 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 Guidelines4/5

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

It gives concrete routing guidance: no barrier can be removed, so switching Spot Funds back to Check funds means calling this tool with policy=spot_funds_limit_mode and mode=enforce. It also states exactly which calls are refused (loosening_refused, validation) so an agent knows when not to bother. It never names the sibling read tool for inspecting existing barriers, which keeps it short of a 5.

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