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

With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that orders execute via Decker's own engine, not the user's broker, that execution_mode is resolved server-side with real trading gated by opt-in, eligibility, and hard caps, and that the response states actual mode. It also discloses position netting behavior and pre_existing_position, going well beyond basic write-side transparency.

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 long but highly dense; every sentence adds a needed caveat or constraint (mode resolution, cap checks, symbol whitelist, validate_intent dependency, netting). The opening distinguishes it immediately from siblings. A bulleted structure might improve scannability, but the content earns its length for a high-risk money-moving tool.

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 no output schema and no annotations, the description is remarkably complete. It covers prereqs (validate_intent), restrictions (crypto-6 only), execution semantics (server-side mode, caps), response behavior (authoritative mode, pre_existing_position), and downstream actions (close_position closes combined total). It leaves no major operational question unanswered.

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 100%, so baseline is 3, but the description adds meaningful layer: it explains notional_usd is the value checked against tier notional cap and defines quantity as notional/price. It also flags that execution_mode is not a caller-chosen parameter, preventing a likely misuse. This compensates for any schema brevity.

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 clearly states the tool places a market order through Decker's own execution engine, explicitly distinct from every sibling tool ('unlike every other tool here, this one moves money'). It names the resource (orders) and the action (places a market order), making the purpose unambiguous.

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 description provides explicit when-to-use guidance: it contrasts with other tools, instructs calling decker.validate_intent first ('this tool does not check it for you'), and notes that HL-synthetic and KRX symbols are read-only via other tools. It also references close_position for later closing combined positions, giving clear operational context.

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