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

With no annotations, the description carries the burden and does well: it discloses the return vocabulary (approve / approve_with_warnings / reject with reasons), that a resized quantity may come back, and even the $0.005 cost. It never explicitly says the tool is read-only and does not itself transmit the order, which is the one thing an agent could misread from "run an order past."

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?

Three front-loaded sentences: what it does, what it checks, what comes back plus cost. The long middle checklist is dense but every item maps to a real rule dimension, so nothing feels padded.

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 multi-object, nested-input risk engine with no output schema, the description is strong: it names the decision outcomes and the resizing behavior, which is what the agent most needs to interpret results. It stops short of clarifying whether market data is optional or what happens when it is omitted, and never confirms the tool is side-effect free.

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 coverage is 50%, with four top-level objects (order, market, policy, account) and nested items. The description implicitly signals relevant inputs — stop price for risk-per-trade, recent_sales for wash sales, buying power, settlement, market hours — but never mentions the market or policy objects or the effect of policy overrides documented in the schema.

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?

Specific verb and resource: run an order past a compliance/risk check before it reaches the broker, followed by an enumerated list of the exact checks performed. That enumeration makes it clearly distinguishable from neighbors like options_risk_check or suitability_check, though no sibling is named explicitly.

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?

"Run an order past ... before sending it to the broker" establishes the workflow slot precisely: this is a pre-submission gate, not a post-trade review. It does not state when to skip it or which sibling to use instead (e.g. for options orders), so the routing guidance is contextual rather than explicit.

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