MCPify

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

The description clarifies the tool targets resting or trigger orders and that the oid comes from get_my_open_orders, adding some context beyond the annotations. It does not contradict the destructiveHint and idempotentHint annotations, though it does not elaborate on consequences or failure 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?

A single sentence fully conveys the purpose, target order type, and required identifier source with no wasted words. The condition is front-loaded, making it easy for an agent to scan and apply.

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 tool's simple one-parameter interface and annotations already indicating destructive, non-idempotent behavior, the description is nearly complete. It explains what to cancel and where the oid comes from; only a brief note on expected outcome or error cases would make it fully self-contained.

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 documents the single required parameter, including its type and source. The description adds no new parameter semantics beyond restating what the schema provides, so the schema-heavy 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?

States a specific verb ('cancel'), a precise resource ('resting or trigger order'), and the required identifier source ('oid from get_my_open_orders'). This clearly distinguishes it from sibling tools like place_order and close_position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when the user asks to cancel a resting or trigger order', providing a clear condition for invocation. However, it does not mention alternatives or explicitly state when not to use this tool versus siblings like close_position.

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?

The description adds behavioral context beyond the annotations: it is explicitly risk-reducing and available when agent trading is armed. This complements the destructiveHint=true annotation by explaining that the destructive action is a position reduction, not an unrelated destructive operation.

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, purposeful sentences. The primary trigger condition is front-loaded, and the risk/availability note adds useful guidance without waste.

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 tool with clear annotations and full schema coverage, the description covers the key invocation context and behavior. It does not describe return values, but the absence of an output schema and the simple nature of the operation make this acceptable.

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 well. The description's mention of 'fully or partially' loosely maps to the size parameter but does not add new meaning beyond the schema's existing descriptions.

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 (close), a specific resource (an open Hyperliquid position), and the exact user intent that triggers it (fully or partially). It is clearly distinguishable from siblings like place_order or cancel_order.

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 the condition for use ('when the user asks to close...') and adds the operating condition ('works whenever agent trading is armed'). It does not explicitly mention when not to use it or name an alternative, but the trigger condition is clear and specific.

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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the 'perp market' scoping and the analysis/charting use case, but it does not disclose additional behavioral details such as ordering, pagination, or whether the current incomplete candle is included.

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. The trigger condition 'Use this when the user wants...' is front-loaded, and every phrase contributes to purpose or usage 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?

For a simple read-only tool with three well-documented parameters and safety annotations, the description is largely complete. The main gap is the lack of any explicit return-format hint or statement about which time window is returned, though 'OHLCV candle history' communicates the core output adequately.

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 symbol, limit, and interval are already documented in the schema. The description does not add parameter-level meaning beyond the schema, and the OHLCV framing is too broad to count as extra 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 verb/resource combination: retrieving OHLCV candle history for a Hyperliquid perp market. It clearly distinguishes this from sibling tools like get_price or get_orderbook by focusing on historical candle data for analysis or charting.

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 states when to use the tool: when the user wants OHLCV candle history for a Hyperliquid perp market. It does not mention explicit exclusions or alternatives, but the usage context is clear enough to route correctly.

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 already cover read-only/idempotent safety. The description adds useful behavioral context by scoping the data to MCPify (Hyperliquid) perpetuals and disclosing the returned data fields. No side effects or hidden behavior are omitted that matter for this read-only list.

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 sentence front-loads the use case and packs the returned-field summary with no filler. Every phrase adds 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?

For a simple read-only list tool with no required parameters, the description plus schema and annotations is fully sufficient: use case, data scope, output fields, and parameter constraints are all covered.

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?

All three parameters have descriptions in the schema (100% coverage). The description adds no extra semantics about sort, limit, or search, so it does not raise the baseline score, but it also does not need to.

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 verb and resource: listing tradable perpetual markets and providing a market overview. It explicitly lists the fields (prices, 24h change, volume, funding, max leverage), making it easy to distinguish from price, candle, and orderbook siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit triggers ('when the user asks which perpetual markets are tradable' or 'for a market overview'). However, it does not mention when-not-to-use or point to alternatives like get_price or get_candles, so it falls short of a full routing contract.

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 already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds useful context about what data is returned, but does not disclose additional behavioral traits such as response format, whether data is real-time, or any auth/availability assumptions.

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 well-structured sentence that front-loads the usage condition and then lists the concrete data types. There is no filler, repetition, or redundant restatement of the tool name.

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, read-only account retrieval tool, the description covers the main content areas a user would ask about. It could be more complete by explicitly distinguishing itself from order/trade-history tools, but the sibling names and the specificity of 'open positions' largely cover that gap.

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 and schema coverage is 100%, so there is no parameter information to supplement. The description compensates by explaining what the tool returns, which is the relevant semantic content for a no-input tool.

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 explicitly ties the tool to a specific user intent: asking about the user's MCPify account. It enumerates the exact data categories (balance, withdrawable, open positions with PnL/liquidation prices, and whether agent trading is armed), which clearly distinguishes it from account-history siblings like get_my_open_orders and get_my_trade_history.

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 opening phrase 'Use this when the user asks about THEIR MCPify account' provides a clear trigger condition. It does not explicitly state when not to use it or name alternative tools, but the sibling list and the enumerated account-specific scope make the intended use reasonably 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?

Annotations already establish read-only, non-destructive behavior, so the description need not repeat that. The description adds valuable context by noting that the tool covers TP/SL trigger orders and returns oids specifically for cancellation, which is useful behavioral detail beyond the annotation fields.

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 filler. The trigger condition is front-loaded, and the second sentence adds a concrete, useful detail about the return value. Every part of the description contributes to correct tool selection and invocation.

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, read-only tool with annotations covering safety and an empty schema, the description is complete. It states the purpose, the trigger, the scope (including TP/SL orders), and the key return information needed for the likely follow-up action (cancellation).

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 and 100% schema coverage, so there is nothing for the description to clarify about inputs. The description still clarifies the implicit scope ('my' open orders) and the inclusion of trigger orders, which compensates for the absence of 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 uses a specific verb ('get') and resource ('my open/resting orders on Hyperliquid'), and explicitly includes TP/SL trigger orders, which distinguishes it from historical order records or trade history. It clearly identifies what the tool returns (each order's oid) and the intended use case.

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 opens with 'Use this when the user asks for their open/resting orders,' providing a clear, explicit trigger for invocation. It does not explicitly name alternatives or exclusion criteria, but the phrasing and inclusion of trigger orders give enough context to route to this tool over siblings like get_my_order_records.

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 already declare readOnlyHint and non-destructive behavior. The description adds that the tool returns audit records including successes and rejections and shows the placing source, which helps the agent set expectations about the data scope beyond the annotation's safety profile.

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 sentence that leads with the trigger condition and packs in the key scoping details (MCPify audit, source types, successes/rejections). No filler or repetitive content.

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 list tool with two optional parameters and no output schema, the description adequately conveys what the records are and when to use it. It could be slightly more explicit about the return shape, but the term 'records' and the audit context are sufficient 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%, so the input schema already documents both limit and action parameters. The description does not add any parameter-specific meaning, meeting the baseline for schema-covered 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 uses a specific verb and resource: retrieving order records placed through MCPify, and explicitly defines the scope as audit records with source attribution (web, mcp agent, admin). This clearly differentiates it from siblings like get_my_trade_history.

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 exactly when to use the tool ('Use this when the user asks what orders were placed through MCPify'). It provides clear context but does not explicitly name alternative tools or state when not to use it, so it stops short of a full when/when-not distinction.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the live venue returning truthful price, size, fee, and realized PnL, which is valuable given there is no output schema.

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 immediately states when to use the tool and what it returns. Every word earns its place, with no filler or redundant restatement of the tool name.

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 tool with one optional parameter and annotations covering safety, the description is nearly complete. It names the key returned fields and the live-venue context, though it could make explicit that the result is an array of fills.

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, limit, is fully described as 'Number of fills' with default, min, and max. The description adds no additional parameter-level meaning, so 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 ('get'), resource ('trade history'), and distinguishes the operation as fills/executions rather than orders. The mention of 'Hyperliquid' and 'live venue truth' differentiates it from related order-record tools without ambiguity.

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 says 'Use this when the user asks for their recent fills/executions', giving clear context. It does not explicitly name alternatives or exclusions, but the fills/executions wording sets it apart from siblings like get_my_order_records.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the burden on the description. The description adds that the data is live and consists of bids/asks for perp markets, but it does not disclose response structure, depth semantics beyond the schema, or any potential rate-limit or market-specific 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?

A single sentence that front-loads the usage trigger and efficiently packs in the market scope (Hyperliquid perps) and data type (bids/asks). There is no filler, repetition, or unnecessary detail.

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 two fully documented parameters and clear safety annotations, this description covers the essential what, when, and where. It specifies the exact market type and return content (bids/asks), which is enough for an agent to select and correctly invoke the 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% — both symbol and depth have clear descriptions in the schema itself. The tool description adds no parameter-specific meaning 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?

The description explicitly states the tool gets 'the live order book (bids/asks) for a Hyperliquid perp market' — a specific verb, resource, and market domain. It is clearly distinguishable from siblings like get_price and get_candles, which serve different data needs.

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 opening 'Use this when the user wants...' provides an explicit activation condition tied to a user request for live order-book data. It does not name alternatives or exclusions, but the condition alone is sufficient to route an agent to this tool for order-book queries.

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 already cover read-only and non-destructive behavior with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the returned data fields (mark price, 24h change, volume, funding), but does not disclose other behavioral details such as response structure or error conditions.

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, front-loaded with the trigger condition, and the parenthetical enumerates the returned metrics efficiently. No redundant words or repetition of the tool name or 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 simple one-parameter read-only tool, the description is sufficiently complete: it names the resource, the data points returned, and when to invoke it. No output schema exists, so the listed fields partially compensate, though it leaves edge cases (invalid symbol, unavailable market) unaddressed.

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 the symbol parameter is well described with examples and an exclusion ('not BTCUSDT'). The description adds no parameter-specific meaning beyond the schema, 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 clearly states the tool's function: retrieving the current price of a specific coin on Hyperliquid. It distinguishes itself from siblings by focusing on 'a specific coin' and 'current price', and clarifies the included data (mark price, 24h change, volume, funding), making it easily differentiated from get_markets or get_candles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this tool when the user asks for the current price of a specific coin. It gives clear context for when it applies, though it does not mention alternatives or scenarios where another tool should be used, such as get_markets for all markets.

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 already signal destructiveness and non-idempotency, but the description adds crucial behavioral context: real funds are at stake, the tool refuses to execute without a recent matching preview, and explicit user confirmation is mandatory. This goes well beyond the structured annotations and is highly valuable for safe agent 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?

The description is compact and well-structured: the use case is stated first, followed by the mandatory safety workflow and the configuration prerequisite. Every sentence carries essential information with no 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 destructive, real-funds tool, the description covers the critical operational context: the preview requirement, confirmation requirement, preview freshness window, and settings prerequisite. It does not describe the response/return shape, but the schema and the described workflow largely compensate for this omission.

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 documents all 9 parameters with descriptions, enums, defaults, and constraints, achieving 100% coverage. The description adds no additional parameter-level meaning, 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 the tool's purpose: opening a perp position or placing an order on Hyperliquid via MCPify when the user explicitly requests it. It also distinguishes itself from preview_order by emphasizing that place_order is the final execution step.

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 explicit when-to-use guidance: only when the user explicitly asks to open a position or place an order. It also provides a precise mandatory workflow: call preview_order first, show the proposal, get confirmation, and only proceed if the preview ran within 10 minutes. It further names the prerequisite of Agent Trading being enabled.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond that: it validates and sizes the order (fresh est. entry, size after rounding, est. liquidation, TP/SL sanity, MCP caps) and shows a proposal card. This is useful context without contradicting the annotations.

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 dense sentences with no filler. It front-loads the most important usage instruction ('Use this BEFORE place_order...') and puts the safety note ('Read-only and always safe to call') near the end. Every phrase 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 tool with 9 parameters, no output schema, and no nested objects, the description covers all essential context: when to call it, what it does, what it doesn't do, and what happens next. The proposal card is described, and the follow-up path to place_order is explicit. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 9 parameters already have descriptions in the schema. The tool description adds no parameter-specific meaning beyond saying that the same arguments should be passed to place_order. Per the calibration baseline, 3 is appropriate when the schema 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?

The description names a specific action (preview an order before placement) and a specific resource (the order being opened). It explicitly differentiates itself from place_order by stating it 'validates and sizes the order' and does so 'WITHOUT placing anything'. This makes the tool's role unambiguous among its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit directive: 'Use this BEFORE place_order whenever the user wants to open a position'. It also provides the follow-up action ('If the user confirms, call place_order with the same arguments'), making the workflow clear. No alternative or exclusion is left ambiguous.

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 already mark this as destructive and non-read-only, and the description adds valuable behavioral context by stating that existing TP/SL triggers are replaced. This goes beyond the annotation by specifying exactly what gets overwritten, which is particularly useful for a 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?

Two short sentences carry all essential information: when to use the tool and what behavioral side effect to expect. There is no fluff or repetition of schema details, and the most important usage guidance 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?

The description is complete for the core use case: it states the trigger condition, the action, and the destructive overwrite behavior. It could additionally clarify return behavior or what happens when only one of stop_loss or take_profit is provided, but the schema and annotations cover enough that an agent can 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 parameters are already well documented in the input schema. The description does not add significant parameter-level detail, but it does reinforce that stop_loss and take_profit are trigger prices on an open position. This meets the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('set or update take-profit / stop-loss') on a specific resource ('open Hyperliquid position'), and adds the defining behavior 'replaces any existing TP/SL triggers'. This makes it clearly distinguishable from sibling tools like place_order or close_position 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?

The description gives an explicit trigger condition: 'Use this when the user asks to set or update take-profit / stop-loss on an open Hyperliquid position.' It lacks an explicit when-not-to-use or mention of alternatives, but the clear scope is sufficient for an agent to route correctly in most cases.

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