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

No annotations are provided, so the description carries the full disclosure burden. It explicitly states the tool is read-only, evaluates a hypothetical book, places no orders, and describes the exact outputs returned (per-position allowed check, policy level, size caps in percent and dollars, reason codes, and portfolio-level exposure/concentration). This is exemplary 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 three sentences that front-load the core action and intent, then give output context, then read-only and input guidance. Each sentence earns its place; only the comfortable return-value enumeration adds slight length, but it's essential in the absence of an output schema.

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?

The tool has one nested parameter, no annotations, and no output schema, so the description must carry pre-hybrid and return-value context. It does so thoroughly, covering what the tool checks, what it returns, and the portfolio-aware caveat. Minor absence: formal error behavior or rate limiting, but these are not critical for a read-only check tool.

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 the baseline is 3; the description adds real semantic value by clarifying that positions should include already-held items because caps are portfolio-aware, and that returns include size caps in percent and dollars. It doesn't restate the schema enums, but it does deepen an agent's understanding of how to populate the field.

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 uses a specific verb and resource ('Assess one or more PROPOSED positions against the engine's limits before placing them'), and it clearly differentiates itself from the sibling read tools (get_market_structure, get_playbook_status, get_risk_policy) by describing the hypothetical-book evaluation and the explicit 'Read-only: it places no orders' note.

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?

It says when to call the tool ('before placing them') and how to construct the input ('include any you already hold, since the caps are portfolio-aware'). It doesn't explicitly exclude alternative tools or state when not to use it, like 'if you just want the raw policy, use get_risk_policy', but the intended invocation context is clear.

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

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

With no annotations, the description carries the full burden. It discloses what the tool provides, what it deliberately does NOT provide (risk amount), and points to the correct sibling. It does not explicitly state read-only behavior or side effects, but 'Get the structural picture' implies a read operation; the explicit non-claim adds useful boundary context.

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?

Two sentences, zero filler. The first sentence front-loads the verb and resource then lists concrete output categories; the second delivers the yes/no question the tool answers and the explicit exclusion with a named alternative. Every clause earns its place.

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 single-parameter, read-oriented tool with no output schema, the description is complete: it explains what the return covers, what the tool cannot tell you, and which sibling to use instead. An agent has everything needed to decide whether to call this tool and what to expect.

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% for the single asset parameter, which already documents valid values (BTC, ETH) and meaning. The description only adds the generic 'crypto asset' context, so baseline 3 is appropriate since the schema does the heavy lifting.

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 opens with a specific verb and resource ('Get the structural picture for a crypto asset') and enumerates exactly what it returns: cycle/range position, structural events, triggers, and friction zones. It explicitly names the sibling it is not (get_risk_policy), making differentiation immediate.

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?

It tells the agent when to use the tool ('Answers are we near an inflection?') and explicitly states when not to: if you need risk sizing, use get_risk_policy instead. This is clear, actionable routing with no inference required.

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

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

With no annotations, the description carries the full burden. It discloses that setups already alerted are reported separately to prevent duplicate signals, mentions the engine veto and alert cooldown logic, and states it is public. This is substantial behavioral detail beyond the schema, though it omits potential rate limits or response format details.

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 moderately long but well-structured, front-loading the core purpose and then clarifying the actionable condition. Every sentence adds relevant detail, though it could be slightly tightened. It is not verbose and reads clearly.

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 simplicity (one optional parameter, no output schema), the description explains what is returned (list of playbooks, actionable setups, and separately reported already-alerted setups) and the filtering logic. It lacks explicit error or pagination notes, but for this tool the coverage is sufficient for an agent to invoke it correctly.

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% for the single parameter 'asset', which includes an enum and description. The tool description adds minor context by mentioning 'per asset' but does not go beyond what the schema already documents. A baseline of 3 is appropriate when the schema fully explains the parameter.

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 lists locked trading playbooks and actionable setups per asset, with a precise definition of what 'actionable' means. It specifies the resource (playbooks) and verb (list), and distinguishes itself from generic siblings by its focus on actionable conditions, though it does not explicitly name alternatives.

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 some usage context by stating the endpoint is public and needs no API key, and it explains the semantics of actionable setups. However, it does not explicitly state when to use this tool versus siblings like get_market_structure or check_trade, nor does it give any exclusions or alternative conditions.

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

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

No annotations provided, but description implies a read-only operation ('Get'). Discloses what is returned. Does not hide any destructive behavior. Lacks detail on authentication or rate limits, but adequate for a policy retrieval tool.

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?

Two sentences, front-loaded with purpose and output details, followed by usage guideline. No unnecessary words. Excellent conciseness.

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?

Despite no output schema or sibling tools, description provides clear purpose, return fields, and usage context. Could mention output format (JSON) but not essential. Sufficient for agent to select and invoke.

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% with descriptions for all 4 parameters. Description does not add significant new semantics beyond the schema; it focuses on return values. Baseline of 3 applies.

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?

Clearly states 'Get the current risk governance policy for a crypto asset' with specific verb and resource. Lists returned fields including policy level, position size, leverage limits, etc. Purpose is 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?

Explicitly says 'Call this BEFORE every trade to determine how much risk is allowed.' Provides clear usage context. No alternative tools or when-not-to-use mentioned, but for a standalone tool, this is sufficient.

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