AgentZ

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: it is 'free', covers a fixed 30-day window, operates on public data, and explicitly avoids advice. It does not mention rate limits or output format, but given the annotations and the tool's read-only nature, the added context is meaningful.

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: a front-loaded scope statement followed by a clear disclaimer. Every clause earns its place by either defining the resource, listing the returned metrics, or disambiguating advice versus facts. 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?

There is no output schema and only one parameter, so the description carries the burden of explaining what the tool returns, which it does by enumerating the metrics. It also clarifies the safety profile beyond annotations. It stops short of explaining the comparison capability or output format, but it is nearly complete for a read-only diagnostic tool.

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

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

Schema coverage is 100% and the single parameter 'wallet' is fully described in the schema. The description adds no syntax or format details beyond what the schema provides (e.g., it does not restate the 0x… format). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and resource: 'A factual review of any wallet's public Hyperliquid perp trading over the last 30 days'. It then enumerates the exact metrics returned (volume, realised P&L, win rate, fees, holding time, weekend vs weekday, largest fill vs market volume, builder-code share), making its scope unmistakable among siblings like risk_check or get_track_record.

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 'Describes and compares only; not advice' and 'Free', which implies this is a diagnostic/analysis tool rather than an action tool, but it does not explicitly state when to use it versus alternatives such as risk_check or get_track_record. Usage context is implied rather than spelled out.

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 openWorldHint=false, so the safety profile is covered. The description adds an important behavioral constraint not in the annotations: 'Requires signed wallet proof,' which is essential for invoking the tool correctly.

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 compact sentence with the core action front-loaded, followed immediately by the authentication prerequisite. There is no filler or 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 four-parameter, read-only assistant tool with complete schema descriptions and no output schema, the definition covers purpose, auth requirements, and question scope. It could be stronger by clarifying expected answer format or routing relative to sibling tools, but the essential 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?

Schema description coverage is 100%, so the baseline is 3 even without description-level parameter detail. The description adds meaning by indicating acceptable question domains ('record, prices, risk, integration') and by reinforcing the signed wallet proof requirement, which maps to the wallet/message/signature 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 ('Ask') and resource ('the AgentZ assistant'), and names four question domains: record, prices, risk, integration. It is clear enough to distinguish from data-fetching siblings, though it does not explicitly contrast itself with alternatives.

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

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

The parenthetical question domains imply when the tool is useful, and 'Requires signed wallet proof' gives a prerequisite. However, it does not say when to use this versus siblings like get_owner_brief or risk_check, nor does it state any when-not 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?

With annotations covering only readOnly/openWorld, the description adds substantial behavioral context: the output is unsigned and user-signed ('AgentZ never holds your keys'), it is free, it carries a 5 bps builder code, and it performs a builder-fee approval check as a side effect. These details go well beyond the structured hints and clarify that nothing is executed server-side.

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?

Front-loaded with the salient points ('Free', what is returned) and dense with no filler; each clause carries distinct information. The single long sentence for the order contents is slightly packed but overall efficient.

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?

An output schema is absent, and the description compensates by describing the return artifact (entries, protective stop, leverage action) and its signing semantics. For an 8-parameter, high-coverage, no-output-schema tool, an agent has enough to call it and interpret the 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 88% (high), so the baseline is 3, but the description adds genuine semantic value by explaining order_type behavior ('limit-first post-only at the best price, with a market fallback, or market') and the optional nature of the protective stop and leverage action, which the bare schema does not fully convey.

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 definition opens with a specific verb and resource: it returns a 'ready-to-sign Hyperliquid order.' It then enumerates the exact components produced (entry, optional protective stop, leverage action) and the builder-code scope, so an agent knows precisely what artifact it gets back 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?

Cost context ('Free') and the security posture are stated, and usage for 'your own wallet or API wallet' is implied, but there is no explicit when-to-use, when-not, or routing to an alternative tool. No sibling competes directly for order-building, so the omission is tolerable but leaves usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond them: the call is free (no credit cost), the data is sourced from four named venues, and funding is reported both per-8-hour and annualised. It does not say what happens if a coin is not listed on all venues or whether requests are rate limited.

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 scope and data types are front-loaded. The fragment 'Free.' is abrupt but does carry the cost signal, so nothing is wasted.

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-only tool with no output schema, the description covers what is returned (funding per 8h and annualised, open interest), the granularity, and the data sources, which is close to sufficient. It leaves return shape (per-venue rows) and unavailable-data behavior unstated, which are minor gaps.

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 single 'coin' parameter is documented with examples (BTC, ETH, SOL), so the schema does the heavy lifting. The description only restates that the input is a crypto coin and adds the venue context, which is the expected 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 names the exact data (funding per 8 hours and annualised, plus open interest), the exact scope (a single crypto coin), and the exact venues (Hyperliquid, Bybit, OKX, Binance). No sibling tool covers funding/OI data, so an agent can distinguish it immediately.

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 no when-to-use guidance, no prerequisites, and names no alternatives among siblings such as trade_conditions or risk_check. The 'Free' tag hints at a cost advantage but never states when this tool should be selected over anything else.

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 openWorldHint=true, so safety and scope are covered. The description adds 'Free', a pricing/cost trait not present in the structured fields, but says nothing about pagination, refresh cadence, timezone/timestamps, or rate limits despite the open-world data source.

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 compact sentences, no filler, with the resource enumeration and the optional filter both front-loaded. Every clause carries 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 two-param, read-only listing tool with annotations covering safety and a schema covering both parameters, the definition is nearly sufficient. Minor gaps remain — no mention of time horizon semantics beyond the schema's day range, and no hint about the shape of returned events — but nothing an agent needs to call it is missing.

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

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

Schema description coverage is 100%, so both parameters (days range/default 14, market string) are fully documented in the schema; baseline is 3. The phrase 'filtered to what affects one market' adds a small interpretive nudge about the market parameter's purpose but no format or syntax detail beyond the schema example.

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 resource (scheduled market-moving releases) and enumerates concrete examples (Fed decisions, CPI, jobs report, PPI, JOLTS, EIA oil/gas), so an agent knows exactly what it returns. It does not explicitly contrast with any sibling, but the siblings are functionally unrelated (trading/positioning tools), so disambiguation is not really at risk.

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 is implied by the content — this is the tool for looking up upcoming scheduled releases — and 'Optionally filtered to what affects one market' hints at the filter case. However, there is no explicit when-to-use guidance, no prerequisites, and no named alternative, leaving the agent to infer the scenario.

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 readOnlyHint=true and openWorldHint=false, and the description usefully adds traits beyond that: the message is valid 24 hours, the call is free, and signing cannot move funds. That cost/validity/safety context is exactly the kind of added disclosure expected when annotations carry the 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?

Three tight clauses with the cost qualifier ('Free.') front-loaded, followed by the action and a safety reassurance. No filler; 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 one-parameter tool with no output schema, the description covers the essential return (a message to sign) and its validity window. It stops short of explaining what to do with the signed result, but that is arguably outside this tool's scope.

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?

Only one parameter exists and schema coverage is 100%, so the schema already fully documents 'wallet'. The description adds no syntax or format detail 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?

States a specific verb and resource: 'Returns a message for your wallet to sign.' An agent can immediately tell it produces a signable payload rather than performing a trade or read. However, it does not differentiate itself from any sibling or clarify its place in a signing/auth flow.

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 is only implied: the description notes the message is for the wallet to sign and is free, hinting this is a prerequisite step before an authenticated action, but it never states when to call it, what depends on it, or which alternative to use instead.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the output size varies by market regime (8 vs 4) and access requires a signed wallet proof, which tells the agent this is gated and non-static.

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 dense sentences, front-loaded with the payload description and followed by the two facts that affect invocation (cadence variability and auth requirement). 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?

With no output schema, the description usefully enumerates the returned order fields, and it discloses the auth prerequisite. It stops short of explaining the signing flow end-to-end or error behavior, but for a read-only, gated retrieval tool it is nearly 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 wallet, message, signature and risk_pct are all documented in the schema itself. The description adds no parameter-level detail (e.g., it never mentions risk_pct or the default/max bounds), 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 gives a specific verb-and-resource ('Today's assigned AgentZ basket as execution-ready Hyperliquid orders') and enumerates the returned fields (symbol, entry reference, stop, exit time, max size in USD). An agent can distinguish this from get_open_calls or build_order by the 'today's assigned basket' framing, 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?

It states the daily cadence ('8 calls on normal days, 4 on defensive days') and the prerequisite ('Requires signed wallet proof'), which is useful context. However it never says when to prefer this over alternatives like get_open_calls or build_order, nor does it name get_access_message as the source of the message parameter.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful non-annotation detail: 'Requires signed wallet proof', telling the agent authentication is mandatory. It stops short of describing return shape or ordering.

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, and the core resource definition is front-loaded ahead of the auth requirement. The phrasing is slightly awkward ('calls your wallet still holds') but nothing is wasted.

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, no-output-schema listing tool the description covers what is returned (held calls past exit time) and the auth prerequisite. Return ordering, quantity, or how to act on results is not addressed, but the essential calling information 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?

Schema description coverage is 100%, with all three parameters (wallet, message, signature) fully documented in the schema, including the reference to get_access_message. The description's 'signed wallet proof' phrase reinforces the message/signature pairing but adds no syntax or format detail beyond the schema, 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?

States a specific verb (get) and resource (calls due to exit) with the scoping condition 'your wallet still holds that have reached their exit time', which implicitly separates it from the sibling get_open_calls. It never names that sibling or explicitly contrasts the two, so it falls short of full 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?

'should be closed now' implies the action context for using this tool, so usage is inferable, but the description offers no explicit when/when-not guidance and does not point to get_open_calls or build_order as alternatives for acting on the result.

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 openWorldHint=false, and the description usefully adds that authentication via signed wallet proof is required along with the 48-hour hold semantics. It is a genuine addition beyond structured data, though it doesn't cover volume, ordering, or pagination.

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, zero filler, with the scope constraint front-loaded before the auth requirement. Nothing here could be trimmed without losing 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?

With no output schema, the description carries the return-value burden and does so by stating the calls are scoped to the 48-hour hold window. Combined with annotations covering the safety profile and an auth hint, it is nearly complete, missing only volume/ordering expectations for a read endpoint.

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 wallet/message/signature are already documented and the baseline is 3. 'Requires signed wallet proof' ties the trio to an auth flow but adds no format or sequencing detail 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 names the resource and its scope precisely ('your assigned calls still inside their 48-hour hold window'), which lets an agent distinguish it from sibling list-like tools such as get_exits_due or get_daily_8. It lacks an explicit verb (list/get) and doesn't name a sibling it is not, so it falls short of a 5.

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 is implied rather than stated: 'Your assigned calls' establishes personal scope and 'Requires signed wallet proof' establishes an auth prerequisite. There is no when-not guidance, no mention of the get_access_message prerequisite flow, and no alternative named for other call views.

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 provide safety profile (not read-only, idempotent, non-destructive, closed-world). Description notes it is 'Free' and that passing the wallet records it, which implies a side effect (recording) beyond a pure read. It doesn't explicitly disclose that this is a write/record operation, which is a notable gap for an agent deciding whether to call it.

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 compact sentences with no wasted words. Front-loads 'Free' and purpose. Could structure the field list more cleanly but is efficient overall.

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?

Without an output schema, the description enumerates the summary's contents, which helps. However, it omits key behavioral details: the recording side effect, whether callers need auth, and how the summary is returned. Adequate but with clear gaps.

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 wallet parameter is fully documented in the schema. Description adds only 'Pass wallet to record it', which hints at persistence but doesn't clarify format or that the parameter is optional.

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 it produces a short factual summary for the human owner covering what AgentZ is, price, record, risks, and revocation. Distinguishable from siblings like get_track_record or agent_health_check, though 'AgentZ' and 'owner' are context-dependent.

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?

Implies usage via 'For the agent's human owner' and 'Pass wallet to record it', but gives no explicit when-to-use vs. alternatives among the many 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that — the data is pre-cost and each month is tagged as replay (simulated) or live — which matters for interpreting a track record, but it is delivered as cryptic fragments without explaining what the record actually contains or its format.

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?

It is maximally short with no wasted words, which is a strength, but the telegraphic sentence fragments are hard to parse and it leads with the least important detail ("Free") rather than the purpose. Structure is efficient but not cleanly 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 zero-parameter read tool with no output schema, the description should tell the agent what the returned record holds. It discloses the pre-cost basis and replay/live labelling but not the shape or scope of the data, leaving a moderate interpretive 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 takes zero parameters, so the schema is empty and complete; per the rubric this is the baseline 4. No parameter-level explanation is needed and none is missing.

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?

"AgentZ's canonical record" broadly identifies the resource and the name get_track_record implies retrieval, but the description never states plainly that it returns a performance/track record. The added fragments ("months labelled replay or live, before costs") hint at content but do not pin down the purpose the way a specific verb+resource statement would.

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 guidance on when to call this tool versus siblings like agent_health_check, get_owner_brief, or risk_check, and no prerequisites or exclusions are named. The only hint is "Free," which implies a cost consideration but stops short of steering 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: the tool is free (no cost to call) and is factual rather than advisory, which sets expectations for how output should be treated. It does not disclose auth requirements, rate limits, or error 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?

Two sentences with no filler, and the cost cue ("Free") is front-loaded where it influences tool selection. The second sentence is a dense but well-organized enumeration of the outputs rather than 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?

There is no output schema, and the description compensates well by enumerating the returned metrics (risk USD/%, margin vs free margin, volume share, comparison to AgentZ limits). What is missing is any note on required inputs or failure modes, but for a read-only computation tool this is largely sufficient.

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 five parameters (market, wallet, size_usd, leverage, stop_pct) are already documented with examples and defaults in the schema. The description references stop, margin, and volume concepts but adds no syntax or format detail beyond what the schema 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?

States a specific operation (risk assessment of a proposed trade) against named resources (the Hyperliquid account and market), and enumerates the concrete outputs: USD risk, % of equity at stop, margin needed vs free margin, and order size vs 24h volume. It never names a sibling such as build_order or trade_conditions, so an agent gets a clear purpose but must infer the boundary itself.

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?

"Describes a proposed trade" implies pre-trade usage, and "Free" plus "Factual, not advice" signals when it is safe to call. However there is no explicit when-to-use guidance, no statement that it does not place an order (versus build_order), and no prerequisites or 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description usefully adds that it is free, that hours are UTC, and that the spread is a live snapshot rather than historical. It says nothing about latency, rate limits, or how much data comes back, which is the remaining gap.

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 opening with 'Free.' and then listing the payload contents; nothing is wasted. The enumeration is dense but each item is a real output, not 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?

With no output schema, the description correctly carries the burden of describing the return content — hourly volume extremes, per-hour volatility, weekend/weekday split, and live spread — which is exactly what an agent needs to decide relevance. Minor omissions are return shape and pagination.

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 only two parameters, both documented in the schema including the 3–30 range and default of 14 for days. The description adds no syntax or format detail beyond confirming the UTC-hour interpretation, so the schema does the heavy lifting.

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

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

Names a specific resource (a Hyperliquid market) and enumerates the distinct outputs — hourly trade intensity, volatility by hour, weekend vs weekday volume, current spread — which lets an agent distinguish it from siblings like weekend_gap and crypto_positioning. It does not explicitly name a sibling, so it falls short of a 5.

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 never states when to pick this tool over alternatives. 'Free' hints at a cost dimension but gives no condition, prerequisite, or exclusion, and the adjacent weekend_gap / crypto_positioning tools are not referenced.

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 readOnlyHint and openWorldHint already covering the safety profile, the description adds real value: it declares the tool is 'Free' and enumerates the metric outputs (gap %, range since, hours to next US open) that the absent output schema would otherwise leave unknown. It remains silent on data source latency and refresh cadence.

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 with no filler, front-loaded with 'Free.' and terminating in a compact colon list of outputs. The elliptical phrasing makes it slightly harder to parse than a plain sentence, but nothing is wasted.

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 metric tool with no output schema, the description supplies the return fields, the comparison basis, and the cost signal. Everything an agent needs to call it and interpret the result 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?

Schema description coverage is 100% and the property documents the market format with concrete examples (xyz:TSLA, xyz:GOLD, xyz:CL), so the schema does the heavy lifting. The description only broadens the category to 'stock, index or commodity' without adding syntax or constraints, matching the baseline 3.

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 the specific computation (a tokenized stock/index/commodity vs its Hyperliquid price at last Friday's US close) and what it yields (gap %, range since, hours to next open). It is distinctive against the sibling list, though the telegraphic phrasing requires a moment to parse. No explicit sibling differentiation, but the resource is unambiguous.

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

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

The mention of 'weekend gap' and 'hours to the next US open' implies the pre-open/weekend context in which this is relevant, and 'Free' signals cost. But nothing states when to reach for this versus event_calendar, trade_conditions, or risk_check, and there are no exclusions or prerequisites.

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