Pit Officer

Official

Overview Schema Source Related Servers Discussions Admin

apply_adjustment

Adjust an account's available, held, or incoming asset balance by absolute value or delta while enforcing bounds; records or rejects the adjustment with a reason.

Instructions

Apply an adjustment to an account's balances of one asset through the engine and return the recorded adjustment. An agent may only lower the balance (available), held and incoming of the account's own currency, each set to a value (absolute) or changed by one (delta), given as exact decimal strings: another asset, a position included, an account without a currency of its own, a delta above zero or an absolute above the field's current value refuses the whole adjustment with loosening_refused and changes nothing, and so does an averageEntryPrice or a realizedPnl other than the current one, or any realizedPnl while the position's P&L calculation is halted, as it would restart it. A bound constrains the value the adjustment results in, not the change: a result outside it records the adjustment as rejected with a structured reason and changes no balance, a policy outcome rather than an error. An adjustment that changes nothing, such as one naming no field, is not recorded and returns no adjustment. Mutates account balances; protected and disabled by default.

Input Schema

Name	Required	Description
`account`	Yes	Account code
`adjustment`	Yes	Adjustment to apply to the account's balances of one asset
`missingAccount`	Yes	Required: create or reject; for an account that does not exist yet, create is refused for an agent with loosening_refused, and reject fails the adjustment instead

Output Schema

Name	Required	Description	Default
`adjustment`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 2, 2026

TDQS

A4.2/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 behavioral burden and does so richly: it discloses the mutation, protected/disabled-by-default status, whole-adjustment refusal cases, bound-as-policy-outcome behavior, no-op non-recording, duplicate id conflict, reserved id prefixes, and operator-vs-agent differences. This is unusually detailed 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 purpose is front-loaded, but the description is an extremely dense, semicolon-heavy paragraph that is difficult to parse. Much of the content is substantive, yet the run-on structure reduces readability and would benefit from tighter organization.

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 a complex nested mutation tool with no annotations and an output schema already present, the description is sufficiently complete. It covers mutation scope, refusal cases, policy-bound outcomes, no-op behavior, default protection, and return expectations without needing to restate output fields.

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 already 100%, so the schema does most parameter documentation work. The description still adds meaning beyond the schema, notably the agent-only lowering constraint, the exact-decimal-string expectation, bound semantics as applying to resulting values rather than changes, and the special realizedPnl and averageEntryPrice restrictions.

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 description states a specific verb and resource: apply an adjustment to an account's balances of one asset through the engine and return the recorded adjustment. It does not explicitly differentiate this tool from adjacent mutation tools like update_account, but the purpose is clear from the first clause.

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 sets explicit usage constraints: an agent may only lower available, held and incoming balances of the account's own currency, and it lists many refusal conditions. It does not name alternative tools or say when another mutation tool should be used instead, so it stops short of full alternative routing.

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

Deploy Server