Carry Intel — Hyperliquid funding screens

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

With no annotations, the description carries the full burden, and it does disclose meaningful behaviors: it is a read of the latest daily digest, in markdown, and it incurs a $0.02 per-call x402 charge. It omits any auth/settlement detail beyond the price and says nothing about pagination or caching, which keeps it from a 5.

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 tight sentences. The core capability and format are front-loaded, and the free-alternative note is a compact, high-value trailing clause. 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 zero-parameter read with no output schema, the description supplies format (markdown), freshness (latest daily), source (public track record), and cost. Without an output schema the markdown callout is especially useful. Minor gaps (settlement/auth mechanics, sample-vs-latest content differences) remain but are not blocking.

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, and there is no schema content to describe, so the parameter baseline of 4 applies. The description correctly adds no (unnecessary) parameter detail.

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 (latest daily settled-prints funding digest) with format (markdown) and provenance (public track record), so an agent knows exactly what it returns. It gestures at the free sibling by naming the free alternative path, though it doesn't name carry_free_sample directly.

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?

Gives the practical selection cue: this costs $0.02/call while an older dated sample is free at /carry/digest/free when available. That effectively routes cost-sensitive or historical-sample callers elsewhere. It stops short of stating explicit when-not conditions or naming the sibling tool.

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 it does meaningful work: it discloses cost (free, no payment), availability limits ('when available'), and the payload contents (exact sample and latest-report dates). It does not describe return format or size, but for a zero-parameter read-only retrieval tool this is solid 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 short sentences with zero filler, and the most decision-relevant fact ('FREE (no payment)') is front-loaded before the content and usage clauses. No sentence is redundant.

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-param tool with no output schema and no annotations, the description covers the essentials: what the caller gets, what it costs, when it is unavailable, and the decision it supports. Only minor gaps remain, such as the format or size of the sample digest.

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 no parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming the call needs no input, which it implicitly does.

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 resource ('previous published funding digest') and its distinguishing trait ('FREE (no payment)'), and lists what the sample contains (exact sample and latest-report dates). It implies a paid counterpart among siblings (carry_digest, carry_opportunities, carry_verdicts) but never names one, so sibling differentiation is only implicit.

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 a clear condition for use: 'Use this to verify data quality before paying.' That is actionable guidance. It stops short of naming the specific alternative tool to invoke after the free check (e.g., carry_digest or carry_opportunities), so routing among siblings is left 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 full behavioral burden; it does disclose the payment requirement ($0.50/call via x402) and the scan scope, which is real value beyond structured fields. It stops short of stating that this is a read-only/non-destructive operation or anything about latency or auth beyond payment.

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 dense sentence that front-loads the scan type, scope, and ranking before closing with cost. Every clause earns its place, though the ranking parenthetical is packed tightly enough to read slightly tersely.

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 no-annotation, no-output-schema scan tool, the description covers purpose, scope, ranking, and cost but says nothing about the shape of the return (a ranked list of perps with funding rates?). The missing return-format cue leaves a modest 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?

Zero parameters, so there is nothing to document; baseline of 4 applies. The description appropriately spends no words on parameter syntax.

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 ('carry scan') with precise scope ('full-universe Hyperliquid', 'every positive-funding perp') and a ranked criterion ('spot-hedgeability'). It hints at contrast with the free-tier sibling via 'full-universe' but never names carry_free_sample, carry_digest, or carry_verdicts 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 when-to-use or when-not-to-use guidance. The $0.50/call price and 'full-universe' scope imply an agent should reach for carry_free_sample as a preview, but that inference is left entirely to the reader.

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 does add genuine context: it declares the operation read-only, warns that 'positions, trades, and returns are not verified', and discloses a per-call cost ($0.10 via x402). However, it says nothing about what a 'verdict' contains, latency, or how tracked markets are defined, leaving notable behavioral gaps.

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 sentences with no waste: purpose first, then the verification caveat, then pricing. The information is front-loaded and each sentence earns its place, though the cost clause could arguably be trimmed in favor of usage guidance.

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 annotations and no output schema, the description is the only source of truth, and it partially covers the ground by naming the returned components (basis, 24h sample context) and disclaiming verification. It still omits return shape/structure and any routing distinction from the three sibling tools, so it is adequate but incomplete.

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 (empty schema), so there are no parameter semantics to explain and the baseline is 4. The description correctly does not invent parameters or claim configurability.

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 ('Read-only Hyperliquid funding verdicts') plus scope ('tracked markets'), so an agent knows it retrieves funding verdict data. It does not explicitly differentiate itself from siblings like carry_opportunities or carry_digest, though the 'verdicts' framing implies a distinct 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?

No when-to-use guidance, no exclusions, and no direction toward alternatives such as carry_free_sample or carry_opportunities. The 'tracked markets' scope is implied but there is nothing telling the agent when this tool is the right choice over its three siblings.

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