check_can_place_orderVerify order eligibility by checking if a wallet has sufficient margin for the additional initial margin (IM) before placing an order.
PortfolioMarginEngine.canPlaceOrder(wallet, additionalIM) — the pre-trade gate. additionalIM is integer token units (USDC 6 decimals).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | ||
| additionalIm | Yes | Additional IM in token native units, integer string |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description/extension carries the full burden of behavioral disclosure. It only mentions 'pre-trade gate' and parameter units, and omits any side effects, return type, whether it reverts, or if it modifies state. As a supervision tool it likely is a read-only check, but that is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the contract signature and role, and the detail about additionalIM units. It has zero fluff, but the wording 'pre-trade gate' is opaque and could be more explicit about the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools like simulate_order and build_order_tx, and no output schema or annotations, the description is too terse. It fails to explain return type, how a decision is represented, or where to use this in a trade flow. The description is minimal for a 2-param tool in a complex batch of related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that additionalIM is integer token units with USDC 6 decimals, which supplements the schema's description. However, the wallet parameter is left entirely undocumented, and since the schema describes only additionalIM, the description only partially compensates for the 50% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact contract function 'PortfolioMarginEngine.canPlaceOrder(wallet, additionalIM)' and labels it 'the pre-trade gate,' which conveys that it is a predicate checking whether an order can be placed. It is clear enough to separate it from simulation or transaction-building tools, though it does not explicitly state the check outcome or contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pre-trade gate' implies the tool should be used before placing or building an order, but there is no explicit instruction on when to use it versus simulate_order or get_margin_status. It does not mention when not to use it and gives no alternative routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.