Skip to main content
Glama
Pit Officer

Pit Officer

Official

report_fill

Apply fills, commissions, or lifecycle statuses to an existing order; terminal statuses release remaining reservations, while drop-copy reports stay unsigned.

Instructions

Apply an execution report - a fill, a commission or a lifecycle status - to an order returned by submit_order or submit_drop_copy_order; the instrument, account and side come from the order. A report on an ordinary order is signed and attested fail-closed and returns its attestation, unsigned under eSign-off; a report on a drop-copy order stays unsigned and returns no attestation, because drop-copy never enforced a pre-trade verdict. filled and partially_filled carry a fill; rejected, rolled_back, filled and cancelled are terminal and release the order's remaining reservation. A report on a terminal order is refused with terminal_order, on a venue-linked order with venue_order_managed, and a repeated id with conflict. Mutates engine state; protected and disabled by default.

Input Schema

NameRequiredDescriptionDefault
idNoOptional caller-supplied unique report id; omit to have the store assign one; a repeated id is refused with conflict
orderYesOrder id returned by submit_order or submit_drop_copy_order
priceNoFill price as an exact decimal string; required with quantity for filled and partially_filled and refused for every other status
statusYesTarget lifecycle status: submitted, accepted, rejected, committed, rolled_back, filled, partially_filled or cancelled; rejected, rolled_back, filled and cancelled are terminal
quantityNoFill quantity as an exact decimal string; required with price for filled and partially_filled and refused for every other status
lockPriceNoDisplay lock price as a plain decimal string without surrounding space or exponent, recorded on the report event, the trade and the attestation; settlement uses the order's stored pre-trade lock, never this value; refused for the non-terminal workflow statuses submitted, accepted and committed
commissionNoOptional fee (positive amount) or rebate (negative amount) with its currency code, forwarded to the engine as one value without currency conversion; omit for none, and when present amount and currency must both be non-empty
leavesQuantityNoCaller-reported open base quantity as a non-negative plain decimal string, recorded verbatim on the order, the report event and the attestation; required with a fill, optional otherwise; the SDK receives the order's own recorded reservation remainder

Output Schema

NameRequiredDescriptionDefault
idYes
resultYes
signedYes
attestationKeyIdNo
signedAttestationNo

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 delivers: it states the tool mutates engine state, is protected and disabled by default, discloses the signing/attestation model (fail-closed signed attestation vs unsigned under eSign-off, drop-copy never attested), names the terminal statuses and that they release the reservation, and enumerates the specific error codes for refusal paths. This is exactly the behavioral context an agent needs before invoking a mutation.

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?

The purpose and scoping constraint are front-loaded, and the refusal/attestation sentences each add distinct information. It is dense, long-ish prose, but nearly every clause earns its place; minor tightening (e.g., the attestation and terminal clauses) would make it a 5.

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 8 parameters, no annotations, and an existing output schema (the attestation result), the description covers the mutation, default protection state, terminal/reservation behavior and error outcomes. Nothing an agent needs to call it correctly is missing, since return-value structure is handled by the output schema.

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 100% and the schema itself already documents fill price/quantity requirements, lockPrice settlement semantics, commission shape and leavesQuantity. The description adds little parameter-level meaning beyond the schema (it only alludes to 'a commission' and inheriting instrument/account/side from the order), 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 precise verb (apply) and resource (execution report: fill, commission or lifecycle status) scoped to orders returned by submit_order or submit_drop_copy_order, which clearly separates it from siblings like confirm_execution or apply_adjustment. An agent can tell what this tool does and what its inputs must originate from 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 establishes clear usage context: reports apply to orders produced by submit_order/submit_drop_copy_order, with distinct behavior for drop-copy vs ordinary orders, and explicit refusal conditions (terminal_order, venue_order_managed, conflict). It stops short of explicitly contrasting when to choose this over near siblings such as confirm_execution or apply_adjustment, so it is strong but not exhaustive.

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