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

With no annotations, the description carries full disclosure burden and excels: it explicitly states it returns a stance, not an approval; explains 'covered=false means ... treat as unknown, not as HOLD'; and details top-level action_gate null semantics with 'gate_null_reason' distinguishing 'no_gate_available' vs 'signal_stale.' It also reveals persistence of every check to an auditable ledger (check_id) and warns about reverse_direction_conflict. This is far more than a typical description and prevents many misinterpretations.

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 and dense, but it front-loads the purpose and timing in the first two sentences, then methodically addresses critical edge cases: covered=false versus HOLD, null action_gate with gate_null_reason, the non-authoritative stance, the ledger persistence, and object_context nuances. Every sentence earns its place by clarifying a distinct behavior that could otherwise be misread. It is not merely verbose; it is information-dense. A slight deduction for a single unwieldy final block that could be structured into clearer sub-bullets.

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 there is no output schema, the description must and does explain the full range of response semantics: the stance vocabulary, side_alignment, coverage flag, null action_gate with its two reasons, and the entire signal.object_context structure, including the obscure reverse_direction_conflict condition. It even specifies when object_context is null. This fully equips an agent to call the tool and correctly interpret any permitted response. Nothing needed for correct invocation or understanding is missing.

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% and each parameter (side, symbol, timeframe, order_type) already has a detailed schema description, including alias resolution and timeframe precedence. The main description adds the conceptual role of symbol+side in the gate check and references how the timeframe default is derived, but these are already present in the schema. Thus the description adds modest incremental value beyond the structured fields, meeting the baseline for high-coverage schemas.

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 identifies the tool as a 'Pre-trade gate check for a proposed order intent' with the explicit purpose of validating symbol and side against Decker's deterministic market state. It distinguishes itself from order execution by stating 'Call this BEFORE placing any order' and clarifies it returns 'a stance reading, NOT an approval or rejection,' separating it from decision-making and state-query tools. This is a specific verb+resource with unambiguous contrast to 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 description provides an explicit temporal context: 'Call this BEFORE placing any order through any execution tool,' including an example flow ('a broker MCP's review→place flow'). It also sets boundaries on result interpretation: 'NOT an approval or rejection' and 'the order decision and responsibility remain with the calling agent/user.' While it doesn't enumerate alternative sibling tools to avoid, the when-to-use is unambiguous. A deduction for not naming explicit exclusion or alternative tools for other needs.

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