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

With no annotations provided, the description carries the full burden and does so well. It discloses the fee model (actual entry fees from trade history plus estimated exit fees at ~$0.9/contract taker), the realism of exit simulation using bid/ask rather than mark, and the inclusion of recommendations. This goes well beyond a generic 'analyze position' claim and sets accurate behavioral expectations.

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 compact and front-loaded: the first sentence immediately labels it preferred and lists its valuable outputs, while the second sentence supplies routing guidance. There is no filler; every clause adds either behavioral detail or selection context.

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 absence of an output schema and annotations, the description is notably complete for selection and invocation: it names required concepts, fee assumptions, output categories, and the preferred-use scenario. It does not spell out output formatting or empty-position edge cases, but those are not necessary for an agent to choose and call the tool 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%, so the input schema already documents both parameters (currency enum and optional instrument_name). The description itself adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 a specific verb and resource: it is the preferred tool for position analysis, and then enumerates concrete outputs such as fee-aware NET P&L, realistic exit simulation at bid/ask, DTE, greeks, moneyness, risk flags, and actionable recommendations. It also explicitly distinguishes itself from get_positions + get_ticker by naming that alternative.

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 usage directive: 'Always use this instead of get_positions + get_ticker when analyzing positions.' It also opens with 'PREFERRED tool for position analysis,' giving the agent a clear selection rule and naming the alternatives it should displace.

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 burden of disclosure. It does warn that this places a real trade, which is critical for an execution tool. However, it does not mention prerequisites like authentication or funds, nor what happens after order placement, such as order lifecycle or cancellation.

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 short and front-loaded with the core action, and the caution about real trades is valuable. It loses a point because listing the supported order types duplicates the schema enum rather than adding new information.

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 schema covers all parameters, and the description explains the tool's purpose and critical risk. However, with no annotations and no output schema, it omits useful details such as return values, order confirmation, and prerequisites, leaving the description adequate but incomplete for a high-stakes execution 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 description coverage is 100%, so the baseline is 3. The description restates the order type enum but adds no new parameter semantics beyond what the schema already documents.

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: 'Place a buy order on Deribit.' It also names the supported order types, which makes the tool's function immediately clear and distinguishes it from sibling tools like sell.

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 implies this tool is for buying on Deribit, but it gives no explicit when-to-use guidance, no exclusions, and no direction to alternative tools such as sell or edit_order. The warning about real trades provides context, not usage selection guidance.

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 provided, the description carries the behavioral disclosure burden. It transparently states that the action cancels all open orders and can be filtered, which is the core destructive behavior. However, it does not disclose the result/return value, whether the operation is idempotent, or any partial-failure behavior, which would be useful for a bulk mutation 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?

The entire description is one tight sentence with no filler. The core action is front-loaded first, followed by the optional filtering behavior. Every word contributes meaning.

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 tool with two optional, fully documented parameters and no output schema, the definition is nearly complete. It tells the agent how to invoke the tool broadly and how to narrow scope. The only notable gap is the lack of any statement about the return value, which is more relevant because no output schema exists.

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?

The schema already documents both parameters with enums and descriptions, so description-level parameter semantics are not critical. The description adds no meaning beyond what the schema provides, just reiterating that filtering is by currency and instrument type. This matches the baseline for high schema coverage.

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 ('Cancel') and a clear resource ('all open orders'), and the optional filters add precision. It naturally distinguishes itself from the sibling tool cancel_order, which handles a single order, and from close_position, which handles positions. There is no ambiguity about what this tool does.

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 clearly implies when to use it: when the goal is to cancel all open orders, optionally narrowed by currency and instrument type. It does not explicitly name alternatives like cancel_order for a single order, but the scope is clear enough to guide selection. No exclusions or prerequisites are stated, so it stops short of a 5.

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 are provided, so the description must carry the burden of behavioral disclosure. It only states the action and target, but does not mention whether cancellation is reversible, what happens to partially filled orders, permission requirements, or the resulting order state.

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, front-loaded sentence with no filler. Every word contributes to identifying the action, target, and required input.

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 is simple with one fully documented parameter, so the description is adequate for basic invocation. However, with no output schema and no annotations, the agent is left without information about success/failure behavior or side effects, which keeps it from being fully complete.

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?

The input schema already fully describes order_id as 'The order ID to cancel.' The description adds only the phrase 'by its order ID,' which reinforces rather than extends the schema meaning. With 100% schema coverage, the baseline of 3 is appropriate.

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 ('Cancel') with a precise resource ('an open order') and the identifying mechanism ('by its order ID'). This clearly distinguishes it from siblings like cancel_all_orders and edit_order without requiring the agent to inspect schemas.

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 usage is implied: use this tool when you have a specific open order ID and want to cancel it. However, it does not explicitly contrast with cancel_all_orders or mention when not to use it, leaving the routing decision to inference.

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 does disclose that the tool submits a market or limit order rather than directly modifying a position. But it omits order lifecycle details such as whether a limit order can remain open, what happens if the position does not exist, and whether a confirmation or order ID is returned.

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 concise sentences with no filler; the core action is front-loaded and the mechanism is stated immediately. Every sentence 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?

Given the low parameter complexity and complete schema, the description is mostly adequate for invoking the call. However, with no output schema and no annotations, it would benefit from stating what the response contains and any order lifecycle caveats, especially for limit orders.

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%, so the schema already documents instrument_name, type, and price. The description adds minimal value beyond confirming that type can be market or limit and that the goal is flattening, which maps to existing schema fields. Baseline 3 is appropriate.

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?

States exact verb (close), resource (existing position), scope (entirely), and mechanism (places market/limit order to flatten). This clearly distinguishes it from siblings like buy/sell, cancel_order, and get_positions.

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 implies when to use it: when an existing position needs to be flattened entirely. However, it does not explicitly say when not to use it, such as for partial closes or routine buy/sell orders, and it names no alternative tools, leaving some routing to inference.

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 of behavioral disclosure. It usefully reveals that the operation targets open orders and avoids a manual cancel/re-place cycle. However, it does not disclose potential side effects such as loss of queue priority, rejection on partially filled orders, restrictions on changing certain fields, or what happens to the order ID. Some of this nuance is important for a trading 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?

The description is a single, well-structured sentence with no filler. The core action, target resource, and key behavioral distinction are front-loaded. Every word contributes to understanding.

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?

This is a 7-parameter state-changing tool with no annotations and no output schema, so the description needs to carry more weight. It adequately states what the tool does and the basic constraint that the order must be open, but it leaves gaps around return values, failure modes, and how the various parameters interact (e.g., amount vs contracts, trigger_price applicability). The schema covers parameter meaning, but the overall usage context is not fully complete.

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%, so the baseline is 3. The description adds little beyond the schema: it mentions 'price, amount, or other parameters' but does not clarify when to use amount vs contracts, nor does it add guidance about trigger_price or flag interactions. The schema already documents each parameter, so the description neither helps nor hurts.

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 ('Modify'), a clear resource ('existing open order'), and names the key fields ('price, amount, or other parameters'). It also distinguishes itself from the cancel-and-replace workflow by explicitly saying 'without cancelling and re-placing', making it easy to tell apart from cancel_order and buy/sell.

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 phrase 'without cancelling and re-placing' provides clear context that this tool should be used when the goal is to adjust an open order in place rather than cancel and create a new one. However, it does not explicitly state when to prefer cancel_order or buy/sell instead, so it lacks a formal exclusion list.

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 behavioral burden. It discloses that results are 'the best matching options sorted by delta proximity,' which is useful, but it doesn't state side effects, edge cases, or behavior when no match exists. The read-only nature is only implied by the verb 'Find.'

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 short sentences with no filler: objective, examples, and output behavior. The core information is front-loaded.

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 relatively simple lookup tool, the description covers the main inputs, examples of use, and the nature of the output. It does not describe the exact return shape, but the absence of an output schema makes that a minor gap given how specialized the tool is.

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 schema already documents all parameters. The description adds only natural-language examples (25-delta put, 50-delta call) and does not provide additional semantic detail beyond 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?

The description opens with a specific verb and resource: 'Find options closest to a target delta for a given currency and expiry.' This makes the tool's job unambiguous and clearly differentiates it from broader siblings like get_options_chain or get_volatility_surface.

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 examples ('find the 25-delta put' / 'find the 50-delta call') make the intended query scenario explicit. It doesn't name an alternative or give a when-not-to-use rule, but the use case is clear enough to guide selection.

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 behavioral burden. 'Get ... summary' strongly implies read-only behavior and the listed fields clarify what is returned, but it does not explicitly state that it performs no side effects or mention any access requirements or caveats.

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?

One succinct sentence that names the resource, scope, and core returned information with no filler. Every word contributes meaning, and the key scope qualifier 'for a currency' is front-loaded.

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 low-complexity two-parameter tool, the description is nearly complete: it names the currency scope and the expected summary fields. It does not describe the optional extended parameter's effect, but the schema already covers that, so an agent has enough information to call the tool 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 coverage is 100%, so both parameters are already documented in the schema. The description adds the semantic scope 'for a currency,' which aligns with the required currency parameter, but it adds no detail about the optional extended parameter beyond what the schema already provides.

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 ('Get') and resource ('account balance, equity, margin usage, and P&L summary') scoped to a currency. It clearly states what the tool returns, though it does not explicitly contrast it with siblings like get_portfolio_summary or get_margins.

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 wording implies this tool is for retrieving a per-currency financial summary, but it gives no explicit when-to-use guidance or exclusions. An agent must infer usage from the resource terms rather than being told when to prefer this over similar account or margin tools.

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 are provided, so the description carries the full behavioral burden. It clearly communicates a read-only 'get' operation, confirms the scope ('all instruments of a currency'), and discloses the response contents (volume, open interest, bid/ask, mark price). It does not mention potential response size or rate-limit implications.

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 two sentences with no filler. The first sentence front-loads the operation, scope, and output fields; the second adds the primary use case. Every part 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?

Given there is no output schema, the description helps by naming the returned fields and the market-wide scope. The required currency parameter and optional kind filter are covered by the schema. It could be more specific about the exact result shape or large payload handling, but it is adequate for a summary scan 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 description coverage is 100%, so the schema already documents both parameters thoroughly with enums and descriptions. The tool description adds no parameter-specific meaning beyond the output fields, which does not go beyond the baseline.

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 states a specific verb ('Get'), a clear resource ('summary info ... for all instruments of a currency'), and explicitly lists the returned data fields. The 'all instruments of a currency' scope distinguishes it from single-instrument tools like get_ticker and get_order_book.

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 gives an explicit use case: 'scanning the entire options or futures market at a glance.' It implies this is a market-wide summary tool rather than a single-instrument lookup, but it does not explicitly name sibling alternatives or state when not to use it.

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. 'List all available currencies' communicates a read-only, exhaustive listing behavior, but it does not mention response format, ordering, or any currency inclusion criteria beyond 'available.'

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 sentence with no filler. It front-loads the action and resource clearly and every word contributes meaning.

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 zero-parameter, single-purpose list tool with no output schema, the description is sufficiently complete. An agent can invoke it correctly with no additional context.

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?

The tool has zero parameters, so the empty schema fully documents the input surface. The description adds no parameter information, but none is needed; baseline 4 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?

Description states a specific verb and resource: 'List all available currencies on Deribit.' It clearly distinguishes this from sibling tools by its unique object type, even though it does not explicitly name any alternative.

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 implies the usage context: when an agent needs the full set of Deribit currencies. However, it offers no explicit guidance about when not to use it or how it relates to sibling tools like get_instruments or get_book_summary_by_currency.

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 are provided, so the description carries the full burden of behavioral disclosure. It only identifies the data type and use case; it does not describe output format, pagination behavior, side effects, or any access requirements. For a read-only tool this is not misleading, but it is thin on behavioral 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 concise sentences with no filler. The primary action and resource are front-loaded, and the second sentence adds relevant use-case context without redundancy.

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 simple read-only retrieval tool with fully documented parameters, the description covers the essential purpose and context. The lack of output schema means return shape is not explicitly described, but the tool is still callable correctly based on this definition.

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%, so the parameters are already documented with examples and limits. The description adds no additional parameter-level semantics, making the baseline score of 3 appropriate.

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 states a specific verb and resource: getting historical settlement/delivery prices for an index. It clearly distinguishes this from current index price or volatility history, though it does not explicitly name a sibling tool to differentiate against.

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 use-case context ('backtesting', 'past expiry outcomes') which implies when this tool is relevant. However, it does not explicitly state when to prefer this over alternatives like get_index_price or get_historical_volatility, nor does it mention any exclusions.

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 burden of behavioral disclosure. It discloses the operation (listing), chronological sorting, and the USDC/underlying nuance. However, it does not mention what the response looks like, whether the operation is read-only, or any potential errors if underlying is omitted for USDC.

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 with no filler: the primary purpose and the key edge case are stated directly. The most important information is front-loaded, and 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?

The description covers the core purpose and the one non-obvious usage (USDC + underlying). With no output schema, it leaves the exact return shape slightly underspecified, but 'list of expiration dates' is reasonably inferable. The main gap is that it doesn't explain behavior for other currency/underlying combinations, which is a minor omission for a moderate-complexity 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 description coverage is 100%, so the schema already documents all three parameters. The description's note about USDC and underlying largely repeats the schema's 'REQUIRED for USDC' message, adding minimal new meaning. This matches the baseline of 3 for full schema coverage.

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 states a specific verb ('List') and resource ('available option expiration dates for a currency'), and adds a sorting detail ('sorted chronologically'). This clearly distinguishes it from sibling tools like get_options_chain or get_instruments, whose purposes are broader or different.

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 clear contextual guidance for the USDC currency case ('use underlying to filter ETH vs BTC options'), which is exactly the kind of conditional usage an agent needs. It stops short of explicitly naming alternative tools or stating when not to use this tool, but the context is clear enough for most scenarios.

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 provided, the description carries the full burden. It adds useful behavioral context by disclosing the granularity ('hourly') and the data contents (funding rates, index prices, interest rates), but it omits ordering, time-range limits, and response shape — acceptable margin for a low-risk read tool but not rich disclosure.

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 totaling about 22 words with zero filler. The first sentence front-loads the action and resource; the second adds return-data detail. Every word 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 simple read-only tool with a fully documented 3-parameter schema, the description covers the essentials: what it does and what data it returns. Since there is no output schema, the description's naming of returned fields is helpful, though the exact response structure is left unspecified.

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%, so all three parameters (instrument_name, start_timestamp, end_timestamp) are already documented in the schema. The description adds no parameter-specific detail beyond what the schema provides, so the baseline score 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?

The description states a specific verb ('Get') with a precise resource ('historical funding rate data') scoped to 'a perpetual instrument.' The second sentence names the returned content (hourly funding rates, index prices, interest rates), which clearly distinguishes it from siblings like get_historical_volatility and get_delivery_prices.

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?

No explicit when-to-use guidance is provided, and no alternatives or exclusions are named. The usage context must be inferred from the tool name and the data promised, which is adequate but left to the agent's judgment.

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?

Annotations are absent, so the description carries the full burden. It discloses that the tool returns a time series of historical volatility data points, but it does not mention granularity, time range, or the exact structure of the returned data. The behavior is understandable but only partially transparent.

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 clear sentence with no filler. Every word contributes to identifying what the tool returns and for what kind of asset.

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-style tool, the description is enough to select and invoke it. However, with no output schema and no annotations, it leaves unclear the exact data-point format, available historical range, and volatility calculation details. Some additional specificity would round it out.

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%: the only parameter, currency, is fully described with an enum of supported values. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: 'Get historical volatility data points for a currency index over time.' The word 'historical' and 'over time' help distinguish it from the sibling get_volatility_index, though it does not name the alternative 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?

There is no explicit guidance about when to use this tool versus alternatives such as get_volatility_index or get_tradingview_chart_data. The phrasing implies a historical use case, but the description leaves the agent to infer routing from sibling names rather than stating exclusions or 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 are provided, so the description carries the burden of behavioral disclosure. It communicates that this is a read-only, snapshot-style price lookup, which is adequate for a simple tool, but it does not describe the response format, error behavior, or any data-source nuances.

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?

A single front-loaded sentence states the action, the resource, and examples with no filler. Every word contributes to the tool's meaning.

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 tool with 100% schema coverage, the description gives the agent enough to invoke it correctly. It is only missing explicit differentiation from sibling price-related tools and return-value detail, which are partially covered by the low complexity and simple expected result.

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 the schema already documents index_name with examples. The description repeats the example indices but adds no meaningful semantics beyond what the schema provides, so the 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?

The description names the verb ('Get'), the resource (current index price), and provides concrete examples (btc_usd, eth_usd), so the action is clear. However, it does not explicitly distinguish itself from closely related siblings such as get_ticker, which may also return price-like data.

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 intended context—when you need the current index price—is implied by the description, but there is no explicit 'when to use vs. alternatives' guidance. Given the large sibling list with overlapping pricing tools, this is a meaningful gap.

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 are provided, so the description carries the full burden. It discloses that the tool returns instrument names, strike prices, expiration dates, and contract details and implies a read-only listing. However, it doesn't mention default behavior like exclusion of expired instruments, the existence of combo instrument types, or any rate limits or side effects.

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 short sentences each earn their place: the first states action and scope, the second lists return contents, and the third provides a usage hint. No filler or repetition.

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 description is adequate for a simple listing tool, covering scope and return content. But it omits combo instrument types from the parenthetical even though the enum includes future_combo and option_combo, and it fails to distinguish this from specialized siblings like get_options_chain, which could lead to tool mis-selection.

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%, so the baseline is 3. The description mentions 'options, futures, spots' and 'currency,' but these merely mirror the enum values and the required currency parameter. It adds no new parameter semantics beyond what the schema already provides.

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 states a specific verb and scope: 'List tradable instruments (options, futures, spots) for a currency.' It also names return contents (instrument names, strike prices, expiration dates, contract details), which makes the purpose clear. However, it doesn't explicitly differentiate itself from closely related siblings like get_options_chain or get_expirations.

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 says 'Essential for discovering available options chains,' implying a key use case. But it gives no explicit guidance on when to choose this instead of get_options_chain or other sibling tools, and it doesn't mention when not to use it.

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 and handles it well: it clarifies the operation is hypothetical and therefore not an order execution. It also discloses the return content (buy/sell margins and min/max price bounds). It does not discuss authentication, rate limits, or estimation caveats, but the core behavioral profile is transparent.

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 with no filler. The first sentence establishes purpose and timing, and the second discloses the return fields. Every clause earns its place and the most decision-relevant information is front-loaded.

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 three-parameter estimation tool with no output schema and no annotations, the description covers the essential points: what it computes, when it is used, and what it returns. It is slightly incomplete on parameter-specific nuances and alternative tool routing, but those are minor relative to the tool's low complexity.

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 does not add detailed meaning to individual parameters beyond what the schema already lists ('price', 'amount', 'instrument_name'); those descriptions remain generic. No additional context like units, precision, or order direction semantics is supplied.

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?

Description states a specific action ('Estimate the margin required for a hypothetical trade') with a clear resource and timing ('before placing it'). It also distinguishes its output from simple trade execution by listing what it returns. This is immediately differentiated from the trading and position sibling tools.

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 phrase 'before placing it' provides clear context that this tool is for pre-trade estimation rather than execution. It does not explicitly name an alternative or state when not to use it, but the use case is clearly implied and unlikely to be confused with order placement tools.

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 provided, the description carries the full burden of behavioral disclosure. It only restates the tool's name and adds 'unfilled', without mentioning read-only behavior, return shape, ordering, pagination, or failure modes. It also conflicts with the schema by implying currency filtering is optional when currency is actually required.

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, front-loaded sentence with no filler words. It loses a point because the misleading 'optionally filtered' phrase introduces ambiguity and is not structurally necessary.

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 simple two-parameter list tool with full schema descriptions, the description is minimally viable. However, the optionality contradiction, lack of output format details, and absence of any behavioral context leave noticeable gaps for an agent deciding how to handle the response.

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?

The schema already documents both parameters with enums and descriptions, so the baseline is 3 due to high coverage. However, the description undermines this by claiming filtering by currency is optional, contradicting the schema's required field. This could mislead an agent into omitting a required 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 uses a specific verb ('List'), identifies the resource ('open (unfilled) orders'), and clarifies scope ('all'). This makes it easily distinguishable from siblings like get_order_state, which targets a single order, and get_user_trades, which covers filled trades.

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 states what the tool does but provides no guidance on when to prefer it over alternatives such as get_positions, get_order_state, or get_user_trades. There are no exclusions, prerequisites, or routing hints.

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 are present, so the description carries full behavioral burden. It discloses the output fields (bid/ask, mark, IV, greeks, OI) and the critical constraint that USDC requires an underlying. For a read-only 'get' tool, this is adequate transparency; rate limits or side effects would be nice but aren't essential here.

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 two sentencees plus an IMPORTANT note, with the primary purpose front-loaded. Every sentence contributes; there is no fluff or repetition.

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 tool with 4 parameters and no output schema, the description covers the return content, the default strike range, and the one real edge case (USDC needs underlying). It omits only minor details like strike ordering or pagination, which aren't critical for correct invocation.

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% and all parameters already have descriptive text, including enums and the USDC requirement. The description adds marginal value by clarifying atm_range as 'ATM ± 10' and re-emphasizing the underlying requirement, but the schema already carries the semantic load.

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?

Description states a specific verb ('Get'), resource ('options chain'), and scope ('currency + expiry'), then enumerates the return payload (strikes with bid/ask, mark, IV, greeks, OI). This clearly distinguishes it from sibling tools like get_instruments or get_volatility_surface, which return different data shapes.

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 gives clear invocation context: it fetches an options chain by currency and expiry. It also provides explicit param-level guidance with the IMPORTANT note to always set 'underlying' for USDC and to use 'atm_range' to limit strikes. It doesn't name alternative tools, but the usage context is unambiguous.

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 provided, the description carries the full burden. It adds useful output behavior context beyond the name ('including best bid/ask, mark price, and funding rate for perpetuals') and even hints at conditional behavior for perpetuals. However, it says nothing about default depth behavior, response shape, or error cases, which would matter for a market data endpoint.

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?

One sentence of 21 words with zero filler. The core action and resource are front-loaded, and the 'including' clause adds differentiating value about return contents. Every word 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 low-complexity, two-parameter getter with full schema coverage and no output schema, this description covers the essential contract: what the tool returns and for which instruments. Minor gaps remain — no mention of the default depth when omitted or the exact structure of the response — but these are small for a read-only market data 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 description coverage is 100%, so the schema fully documents both parameters — instrument_name and depth with its allowed level values. The description adds no new parameter meaning; it only clarifies at a high level that the tool returns bids and asks. Baseline 3 is appropriate since the structured schema carries the load.

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?

Uses a specific verb and resource: 'Get the order book (bids and asks) for an instrument.' The scope qualifier 'for an instrument' distinguishes it from sibling get_book_summary_by_currency, and the mention of mark price and funding rate for perpetuals separates it from get_ticker. An agent can identify the correct tool without opening the schema.

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 conveys implied usage — get this when you need order book levels, best bid/ask, mark price, or funding rate for an instrument — but it never explicitly names alternatives or states when not to use it. No exclusions are given versus get_ticker or get_book_summary_by_currency, leaving the agent to infer selection criteria from the field list.

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 behavioral disclosure burden. It discloses the read-only nature through 'Get' and 'Returns', lists the possible order_state values, and names the returned fields. It does not cover error behavior or authentication, but for a simple lookup this is sufficient.

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 concise sentences front-load the core action and return values, followed by a concrete use case. Every sentence earns its place, with no redundant filler.

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 lookup with no output schema and no annotations, the description is complete: it names all relevant return fields, lists every possible order_state value, and states when to use the tool. Missing not-found behavior is a minor gap for such a simple retrieval operation.

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 a description for order_id, so the baseline is 3. The description adds minimal extra meaning beyond 'by its order_id' and contextualizes the parameter as part of a state lookup, but it does not elaborate on ID format, origin, or edge cases.

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 ('Get') and resource ('the current state of an order'), and enumerates the exact return fields and order_state values. This clearly distinguishes it from sibling tools like get_open_orders or cancel_order without needing to open their schemas.

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 explicitly tells the agent when to use the tool: 'Use this to check if an order was filled, partially filled, or cancelled.' This provides a clear use case, though it does not mention alternatives or exclusions explicitly.

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 provided, the description carries the full burden of behavioral disclosure. It clearly explains the operation shape: an aggregated read of portfolio greeks with a per-position breakdown. It does not discuss auth, data freshness, or rate limits, but for a read-only getter the core behavior is well disclosed.

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 with no wasted words. The core action is front-loaded, outputs are listed compactly, and the use-case sentence adds purpose without padding.

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 tool with no output schema and no annotations, the description adequately explains what the tool returns and its scope. It covers the essential usage context. A slightly higher score would require mention of limitations or explicit sibling differentiation, which is not essential given the tool's simplicity.

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?

The sole parameter 'currency' has 100% schema coverage with an enum, so the schema already documents it. The description only repeats 'for a currency' and adds no additional semantic nuance such as settlement vs. underlying currency behavior. The baseline for high schema coverage 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?

The description states a specific verb ('Get'), a precise resource ('aggregated portfolio greeks across all open option positions for a currency'), and explicitly lists the outputs (delta, gamma, vega, theta, per-position breakdown). This makes the tool's purpose unambiguous and distinguishes it from siblings like get_positions or portfolio_risk_metrics.

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 clear context for use ('Essential for understanding net risk'), which signals when an agent should reach for it. However, it does not explicitly mention alternatives or exclusionary conditions, so it stops short of the highest tier.

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 provided, the description carries the behavioral disclosure burden. It openly describes the operation as a read-oriented 'overview' and 'snapshot', and lists the data categories returned. It does not mention response format or potential latency, but the aggregate, non-mutating nature is clearly conveyed.

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 two sentences with no filler. The core value proposition and scope are front-loaded, and the benefit over multiple API calls is stated in one concise clause. Every sentence contributes to tool understanding.

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-only summary tool, the description is largely complete: it names the scope and the major content categories. There is no output schema, so the description partially compensates by listing what the snapshot includes, though it could specify field-level details or ordering behavior for full completeness.

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?

The schema covers the only parameter (currency) with an enum and a 'Currency' description, so schema coverage is 100%. The description adds no further parameter-specific detail, such as how the currency affects which positions or orders are included, but the schema already provides sufficient semantics.

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 states a specific verb and resource: a one-shot account overview for a currency. It enumerates the contents (balances, margin usage, equity, positions with P&L, open orders), which clearly distinguishes it from narrower siblings like get_account_summary, get_positions, and get_open_orders.

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 clearly implies when to use this tool: when a broad account snapshot is needed without making multiple separate API calls. It does not explicitly name excluded alternatives or edge cases, but the phrase 'Saves multiple API calls into a single comprehensive snapshot' provides actionable context for tool selection.

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 are provided, so the description carries the behavioral disclosure burden. It communicates the returned fields and implies a read-only operation, but does not mention pagination, ownership scope, default filtering behavior when kind is omitted, or potential side effects.

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 front-loaded sentence with no wasted words. The list of returned attributes is useful and directly helps an agent decide whether this tool satisfies its need.

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 straightforward read-only positions tool, the description plus fully documented schema is largely sufficient. It could be slightly more explicit about whose positions are returned and the default when kind is omitted, especially since no output schema exists.

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%, with both parameters already having descriptions and enums. The description adds no additional semantic detail about currency or instrument kind, so it does not exceed the baseline set by 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?

Description states a specific verb and resource ('Get all open positions') and enumerates the returned attributes (size, direction, P&L, average price, greeks). This clearly distinguishes it from sibling tools like get_open_orders and get_portfolio_summary.

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 phrase 'Get all open positions' creates a clear use case: an agent should use this when it needs position-level detail. It does not explicitly name alternatives or exclusions, but the intended context is still evident.

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 of behavioral disclosure. It does disclose real-time data content and option-specific fields, which is useful, but it omits other behavioral aspects such as authentication requirements, rate limits, error behavior, or what happens for invalid instruments.

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 with no filler. The first sentence front-loads the core purpose, and the second adds valuable option-specific detail. Every word 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 tool with no output schema, the description is quite complete: it states the operation, scope, and key return fields. A minor gap is not mentioning sibling tools or explicitly stating that order book and chart data are out of scope, but this does not seriously hinder an agent.

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% because the single parameter 'instrument_name' has a clear description with examples. The main description adds no additional parameter-level semantics beyond the schema, so the baseline 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?

The description clearly states a specific verb and resource: 'Get real-time quote data for an instrument.' It further distinguishes itself by enumerating option-specific fields like greeks, IV, mark price, bid/ask, open interest, and volume, which differentiates it from sibling tools like get_order_book or get_index_price.

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 intended use is implied: use this for a single instrument's real-time quote, especially for options data. However, there is no explicit guidance on when not to use it or which sibling should be used instead (e.g., get_order_book for depth, get_tradingview_chart_data for historical data), so the agent must infer the boundary.

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 are provided, so the description must carry the behavioral disclosure burden. It communicates that the tool returns historical OHLCV data and is read-only in nature, but it does not mention ordering, inclusivity of timestamps, pagination, response shape, or any rate limits or data availability caveats.

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 two concise sentences with the core action front-loaded. The second sentence adds practical use-case context without redundancy or filler.

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 read-only historical data retrieval tool, the description combined with a fully documented schema is largely sufficient for an agent to select and invoke it. The main gap is the lack of an output schema or any explicit statement about the response format beyond 'OHLCV candlestick data,' but the core calling contract is clear.

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 parameters are already fully documented in the input schema. The description adds no additional parameter-level meaning beyond framing the data as historical OHLCV, which aligns with the start/end timestamp parameters.

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 states a specific verb and resource: 'Get OHLCV candlestick data for any instrument.' This clearly identifies what the tool returns and distinguishes it from sibling tools like get_ticker or get_index_price, which serve different data purposes.

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 second sentence gives useful context ('price charts, technical analysis, historical price research') that implies when this tool should be used, but it does not explicitly contrast it with alternatives or state when not to use it. With many market-data siblings available, explicit routing would have been stronger.

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 are provided, so the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation ('Get'), but it fails to disclose pagination behavior — the claim of a 'full ledger' sits awkwardly against the schema's count default of 100 and the need for continuation tokens — and says nothing about ordering, authentication, or response shape.

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 sentence with the core scope front-loaded ('full ledger of account transactions') followed by a clarifying enumeration. There is no filler, though the list of eight transaction types is somewhat long and partially duplicates the query enum already present in the 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?

For a 6-parameter tool with no annotations and no output schema, the description is thin. It omits the return format, fails to explain that retrieving the full ledger requires pagination via the continuation parameter, and offers no guidance on when it should be preferred over the trade-specific sibling tools.

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%, so the schema already documents all six parameters, earning a baseline of 3. The description adds some value by enumerating ledger contents — including 'fees' and 'funding payments', which do not appear in the query enum — but this is largely redundant with the filter options already listed 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?

The description uses a specific verb ('Get') and a specific resource ('full ledger of account transactions') and enumerates the transaction types in scope. The inclusion of trades, settlements, fees, funding payments, deposits, withdrawals, and transfers implicitly distinguishes it from trade-only siblings like get_user_trades and get_user_trades_by_instrument, 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?

The description provides no guidance on when to use this tool versus the overlapping siblings get_user_trades and get_user_trades_by_instrument, which both concern the trade portion of the ledger. There are no conditions, exclusions, or alternative routing cues, leaving the agent to infer the appropriate selection from the name and scope alone.

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?

There are no annotations, so the description carries the behavioral burden. It discloses that the tool returns recent fills for a currency and states the returned fields (price, size, fees, P&L, IV, underlying price), which conveys a read-only, disclosure-oriented behavior. It does not explicitly mention side effects or safety, but the get/Shows framing makes the read nature clear.

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 tightly written sentences: purpose first, then critical filtering guidance, then sibling routing. There is no filler, and all sentences earn their 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 read-only trade-history tool with six well-documented parameters and no output schema, the description covers the purpose, required filtering behavior, returned data fields, and when to use a sibling tool. This is sufficient for an agent to select and 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%, so the baseline is 3 and all six parameters are already documented. The description adds practical emphasis on filtering by kind but does not add new meaning to individual parameters beyond what the schema provides.

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: "Get recent trade fills for a currency," clearly distinguishing this from Get user trades by instrument. It also names the sibling alternative and lists the returned trade fields, making the tool's 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 explicitly instructs the agent to always filter by kind and gives the direct alternative: use get_user_trades_by_instrument if the specific instrument name is known. This provides clear when-to-use and when-to-choose-another-tool guidance.

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?

There are no annotations, so the description carries the full burden. It discloses that the tool returns price, size, fees, underlying price, and IV at trade time, which adds useful behavioral context. However, it does not explicitly state that this is a read-only operation or cover defaults like time range, pagination, or empty-result behavior.

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 sentences with no wasted words: the first states the tool's core function, the second provides usage guidance with an example, and the third lists return fields. The most important information is front-loaded.

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 read-only query tool with five optional parameters and no output schema, the description adequately covers the return values and the key usage context. It could be slightly more explicit that this returns the authenticated user's trades, but 'my fills' and the sibling get_user_trades provide enough context.

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%, so the parameters are already fully documented. The description adds a concrete instrument_name example but does not add meaning beyond the schema for count, sorting, or timestamps. Baseline 3 is appropriate.

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 states a specific verb and resource ('Get trade history for a SPECIFIC instrument') and includes a concrete example. It distinguishes this from the sibling get_user_trades by emphasizing instrument-specific filtering and the preference when the instrument is known.

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?

'Preferred when you know the instrument name' gives a clear condition for use, and the example reinforces the intended scenario. It does not explicitly name the alternative get_user_trades or state when not to use it, but the condition is clear enough.

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 for behavioral disclosure. It discloses that the output is OHLCV data representing implied volatility, which is useful, but it does not mention read-only status, date-range handling, response shape, or any limits or side effects.

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 only two sentences, front-loaded with the core action and resource. The VIX analogy and trend statement add value without becoming verbose, though the second sentence is somewhat redundant with 'OHLCV data'.

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 four-parameter read-only tool with no annotations and no output schema, the description explains the core concept and return type but omits response format details, behavior around timestamps and resolution, and how this differs from closely related tools like get_tradingview_chart_data or get_volatility_surface.

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%, with every parameter documented and enums provided for currency and resolution. The description adds DVOL context but no extra parameter-level meaning beyond what the schema already supplies.

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 names a specific resource (DVOL, Deribit's volatility index) and a specific output type (OHLCV data), with a helpful analogy to the VIX. It clearly identifies what the tool does, though it does not explicitly contrast itself with volatility-related siblings like get_historical_volatility or get_volatility_surface.

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 implies a use case ('shows implied volatility trend over time') but provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no routing among the many volatility and chart siblings.

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 provided, the description carries the full behavioral burden. It does this well by stating the return structure: a matrix of expiry × strike → IV, plus ATM IV and skew metrics per expiry. It does not specify exact field names or units, but the behavioral disclosure is substantive.

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 concise sentences with no filler: the first states scope, the second describes the return value, and the third gives the use case. Every sentence 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 market-data tool with no output schema, the description explains both the return shape and the intended use case. It is enough for an agent to select and call the tool correctly, though exact response field names and units are left unspecified.

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 the only parameter, currency, is fully documented with an enum. The description only restates 'for a currency' and adds no extra guidance beyond what the schema already provides, so the baseline 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?

Uses a specific verb and resource: get the implied volatility surface across all strikes and expirations for a currency. This distinguishes it from siblings like get_historical_volatility and get_volatility_index because it targets the full strike/expiry matrix of IV.

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?

States a clear context: 'Essential for relative value analysis and vol trading.' It leaves the agent with a concrete sense of when this tool is the right choice, though it does not explicitly name alternatives or say when not to use it.

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 burden. 'Get' signals a read-only operation, and the threshold explanation adds behavioral meaning about how to interpret the returned values. It does not discuss auth, rate limits, or output shape, but those are not critical for this data-only 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 tightly written sentences: the first enumerates the returned metrics and scope, the second gives the key trading interpretation. There is no filler or repetition.

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 two-parameter read-only tool with full schema coverage, the description is nearly complete: it names all outputs and explains how to interpret IV Rank. The lack of an output schema and explicit return format is a minor gap, not a blocker.

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%, so the schema already documents currency and period including the default. The description adds no parameter-specific detail beyond mentioning cryptocurrency and the thresholds; therefore it meets the baseline but does not exceed it.

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 the specific verb 'Get' and names four concrete metrics (IV Rank, IV Percentile, HV30, VRP) for a cryptocurrency. This clearly distinguishes iv_rank from volatility siblings like get_historical_volatility and get_volatility_index by identifying the composite ranking output.

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 actionable decision context with thresholds: IV Rank > 50 is rich for selling premium and < 30 is cheap for buying. It does not explicitly name alternatives or state when-not-to-use, but the context is clear enough for a trading-oriented agent.

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 exist, so the description carries the full disclosure burden. It discloses the output scope (metric categories and HEALTHY/CAUTION/AT_RISK statuses) and the underlying risk framework (Tasty Trade), which meaningfully informs an agent about what the tool computes. 'Dashboard' reasonably conveys a no-side-effect read operation, though freshness/snapshot semantics and behavior with zero positions are not addressed.

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?

A single, front-loaded sentence that names the resource first and then lists the delivered metrics efficiently. The Tasty Trade framework attribution adds context without bloat; only minor restructuring (e.g., grouping metrics) could improve it.

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 a single well-defined parameter, no output schema, and no annotations, the description is sufficiently complete to support an invocation decision: an agent knows what metrics to expect and that the scope is portfolio-wide. Remaining gaps are the health-status thresholds and explicit differentiation from portfolio-sibling tools, but neither blocks correct invocation.

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 currency parameter is self-documenting via its enum, and the description's portfolio-scope hint implies currency selects the portfolio denomination, but the description adds no explicit explanation of the parameter's role beyond what the schema already provides.

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?

States a specific resource - a portfolio-level risk dashboard - and enumerates the concrete metrics it delivers (dollar greeks, ratio, margin utilization, concentration, health status). The 'portfolio-level' scope distinguishes it from instrument-specific siblings like get_ticker or get_order_book, though it lacks an explicit verb like 'retrieve' and doesn't name the overlapping sibling tools get_portfolio_greeks or get_portfolio_summary.

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?

Usage context is implied by the portfolio-level framing and the metric list, so an agent can infer this is for aggregate risk assessment rather than instrument-level queries. However, no explicit when-to-use or when-not-to-use guidance is given, and the natural alternatives (get_portfolio_greeks, get_portfolio_summary, get_margins) are never mentioned or excluded.

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 behavioral disclosure burden. It does disclose the output shape (ranked candidates with premium, delta, IV, margin, annualized yield, position sizing) and the scanning-by-strategy behavior, but it does not explicitly state that this is a read-only query, cannot execute trades, or what the ranking criterion is.

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?

A single front-loaded sentence communicates the action, allowed strategies, and returned fields without filler. Every part earns its place and there is no redundant restatement of parameter names.

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 description is adequate for a screening tool given full schema coverage of required/enum parameters, but the absence of an output schema and the unspecified ranking criterion leave some ambiguity about how results are ordered. It does not explain what 'ranked' means or how candidates should be interpreted.

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%, so the input schema already documents all six parameters. The description only echoes the strategy enum and general output fields, adding no additional parameter semantics.

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 names a specific action ('Scan'), a resource ('option trading opportunities'), and the supported strategies ('naked_put, strangle, covered_call'), and it lists the returned ranking metrics. It does not explicitly contrast itself with sibling option-data tools such as get_options_chain or find_options_by_delta, so it misses the top tier for sibling differentiation.

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 intended use is implicit: call it when you need strategy-based option candidates rather than raw market data or order execution. It provides no explicit when-to-use/when-not-to-use guidance and names no alternatives, so the agent is left to infer placement among the sibling tools.

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 of disclosing behavior. It explicitly warns that this places a real trade and says to use caution, which is the critical behavioral trait for a financial mutation. It does not cover order lifecycle or permission requirements, but the most important risk is disclosed.

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 short sentences with no wasted words. The primary purpose is front-loaded, the supported order types follow, and the risk warning is placed at the end for emphasis.

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 9-parameter order tool with no output schema and no annotations, the description is lean but sufficient: it states the action, supported types, and real-trade risk, while the schema itself thoroughly documents parameters like amount, contracts, price, and time_in_force. The main gap is the lack of explicit guidance about expected response or prerequisites, but the core invocation context is present.

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?

The input schema covers all 9 parameters with descriptive meanings, so the baseline is 3. The description adds little parameter-level detail beyond restating the order types already present in the schema's enum.

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 action as placing a sell order on Deribit and enumerates the four supported order types. It is distinguishable from sibling tools like buy, cancel_order, and edit_order because it explicitly names the sell order action.

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 purpose implicitly tells an agent to use this tool when placing a sell trade, and the warning 'places a real trade' conveys caution. However, it does not explicitly state when not to use it or mention the buy tool as the counterpart alternative, so the guidance is only implied.

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