Get margin status

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

With no annotations provided, the description carries the full burden. The '(eth_call)' disclosure is genuinely helpful behavior context: it tells the agent this is a read-only RPC with no state change and no transaction-building. However, it says nothing about edge-case behavior such as whether the call reverts for a wallet without a vault position, what happens with an invalid address, or whether results can be stale. It adds some meaningful disclosure but leaves important behavioral questions open.

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 a single, tight fragment that front-loads the three return fields and tags the call type. There is no filler, and the '(eth_call)' parenthetical earns its place by conveying behavioral context. It loses one point only because it is a noun phrase rather than a complete sentence, so the verb must be inferred from the title.

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?

For a one-parameter read-only tool, it covers what most agents need to call it correctly: the input (a wallet) and the outputs (balance, IM/MM, isHealthy). Given the domain, though, an agent would benefit from knowing how the isHealthy flag relates to check_can_place_order, whether IM/MM have units resolved by another tool, and what a missing position looks like. The absence of an output schema makes the description the sole source of return semantics, so it should say slightly more.

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?

Schema description coverage is 100% – the schema already documents wallet as a '0x-prefixed EOA'. The description's 'for a wallet' adds nothing beyond that, so the baseline of 3 applies. It does not clarify semantic details like whether the wallet must hold an open position, how addresses are normalized, or what 'EOA' implies (no contract wallets), so no extra credit is earned.

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 specifies the resource (vault of a wallet) and enumerates the exact outputs (vault balance, portfolio IM/MM, isHealthy), which clearly differentiates it from the sibling get_margin_model (the model vs. a wallet's status). It lacks an explicit verb, but the title 'Get' supplies it and the content leaves little ambiguity. This is clear but just short of the best case because it relies on the title for the verb rather than stating it in the description.

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?

There is no guidance about when to call this tool versus alternatives such as get_positions, check_can_place_order, or simulate_order, nor any mention of prerequisites like having a vault position. The '(eth_call)' hint implies a read-only on-chain query, but the description never tells the agent whether to use it before building an order, after a deposit, or for account health checks. This is a clear 'no guidance' case.

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