Hyperliquid perp data (funding, whale liq levels, positioning, brief) + token safety, x402 per call.
Scored across 10 tools
Most tools target clearly distinct resources: free discovery helpers (get_payment_quote, list_sample_reports, get_sample_report, hyperliquid_feed_status) versus paid data calls, plus separate Robinhood and Solana safety checks. The one real overlap is hyperliquid_market_brief, which explicitly bundles funding extremes, whale positioning, and liquidation clusters already offered as three standalone paid tools, forcing an agent to choose aggregate vs. individual. Descriptions largely resolve this by framing the brief as a one-call LLM-ready aggregate, so confusion is limited.
All names use snake_case and are domain-prefixed in a predictable way (hyperliquid_*, robinhood_/solana_..._token_safety_check, and get_/list_ helpers). The verb pattern is not uniform—some names are verb_noun (get_payment_quote, list_sample_reports) while the paid data tools are noun phrases with no verb (hyperliquid_funding_extremes, robinhood_token_safety_check). Still readable and easy to group, just not a single consistent convention.
Ten tools is well-scoped for a combined perp-data plus token-safety service, with each tool earning its place across discovery, freshness checking, individual data calls, an aggregate brief, and two chain-specific safety checks. No redundancy that suggests trimming, and no obvious missing sibling that would demand expansion.
The surface covers the stated domain well: feed freshness, funding extremes, whale positioning, liquidation levels, an aggregated market brief, and pre-trade safety checks for Robinhood Chain and Solana tokens, with free discovery/receipt tools supporting the paid flow. Minor gaps exist—no historical or time-series access, no other EVM/Base token-safety coverage, and no per-coin detail beyond what the aggregate and safety tools expose—but agents can work around these.
Free. Returns the unpaid HTTP 402 offer (networks, USDC amount, payTo, raw PAYMENT-REQUIRED) for a token check or a Hyperliquid data call.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| address | No | Optional mint/token to quote the exact resource URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new context: the call is free, the returned offer is unpaid, and the payload includes a raw PAYMENT-REQUIRED header. That tells an agent the operation has no cost and no side effect, and hints at the payment handshake. It stops short of explaining how to act on the returned offer.
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 the most decision-relevant fact ("Free.") front-loaded. The parenthetical field list is dense but earns its place by previewing the return payload in the absence of an output schema. 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 does carry the burden of describing returns and partially does so by listing the offer fields. But it omits what an agent should do with the offer (how to satisfy the 402), and the six chain values remain unmapped, leaving real gaps for a tool whose whole purpose is a payment handshake.
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 50%: address is documented in-schema, but the chain enum values carry no descriptions. The phrase "a token check or a Hyperliquid data call" loosely maps the enum into two groups (solana/robinhood vs hl_*), which adds some meaning, but it does not disambiguate individual values like hl_funding vs hl_whales vs hl_brief. Partial compensation only.
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 the unpaid HTTP 402 offer, and enumerates what the offer contains (networks, USDC amount, payTo, raw PAYMENT-REQUIRED). This is clearly a pricing/quote tool, distinguishable from the sibling data tools. It does not explicitly name a sibling, but the resource is specific enough to stand apart.
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?
"for a token check or a Hyperliquid data call" implies the context in which a quote is needed, which is useful routing information. However, it never says to call this before paying, never states when-not to use it, and never names an alternative tool. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Returns one full recorded paid response by id, e.g. rh-musebook-2026-09-24 or sol-bonk-2026-09-24.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 useful context by noting the tool is free and returns a full recorded paid response, though it does not address failure behavior or return structure.
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 extremely compact and front-loaded: 'Free.' immediately signals cost, followed by the core behavior and illustrative examples. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with annotations and ID examples, the description is largely sufficient. The only notable omission is guidance on how to obtain valid IDs or what happens on lookup failure, but these are minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry parameter meaning, and it does: it explains that id identifies a sample report and provides realistic examples like rh-musebook-2026-09-24 and sol-bonk-2026-09-24. This goes well beyond the bare string pattern.
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 and resource: 'Returns one full recorded paid response by id', and reinforces it with concrete ID examples. It clearly distinguishes this from sibling tools like list_sample_reports by emphasizing singular retrieval by ID.
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 implicitly suggests use when you already have an ID, but it gives no explicit when-to-use or when-not-to-use guidance. It does not mention list_sample_reports as the way to discover IDs, nor does it contrast with get_payment_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Shows when the Hyperliquid feed was last refreshed and whether it is fresh enough to be sold.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 useful non-annotation context: it is 'Free' and the output carries a sellability verdict. It stops short of defining the freshness threshold or the exact return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with pricing front-loaded ('Free.') and no filler. The fragment style is efficient, though it is brief enough that some behavioral detail could have been added without bloat.
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 partially compensates by naming what is returned (last refresh time and a freshness verdict). For a simple zero-parameter status tool this is close to sufficient, though the freshness criterion itself is left undefined.
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 schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter 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?
States a specific verb ('Shows') and resource ('Hyperliquid feed was last refreshed') plus the freshness verdict, so an agent can tell this is a status/freshness probe rather than a data-retrieval tool. It does not explicitly name sibling alternatives, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'fresh enough to be sold' implies the use case (validate freshness before selling/using the feed), which is a reasonable contextual cue. However, there is no explicit when-to-use statement or comparison to siblings like hyperliquid_market_brief, so guidance remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked funding-rate extremes across all Hyperliquid perps (top positive / top negative hourly funding, annualized), or one coin. Hyperliquid public data only, refreshed ~every 3 min; stale data (>15 min) is never charged. $0.002 USDC via x402 (Base or Solana) from YOUR wallet. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional Hyperliquid perp ticker, e.g. BTC, ETH, SOL | |
| limit | No | Optional rows per side | |
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
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 by structured fields. The description adds genuinely useful non-annotation behavior: public data only, ~3 min refresh, stale (>15 min) never charged, and the $0.002 USDC x402 payment flow from the caller's own wallet. This is richer than the annotations alone and helps the agent understand cost and freshness risk.
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 core capability before the freshness, pricing, and disclaimer clauses, and every sentence carries distinct information (scope, data policy, payment, disclaimer). The 'Not financial advice' boilerplate is the only filler, but it is defensible for a financial-signal tool.
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, so the description must carry the return semantics, and it does name the shape (ranked top positive/top negative hourly funding, annualized, per side). Combined with the freshness and payment rules, an agent has enough to call it correctly, though the exact response structure and the 402 challenge/retry flow could be spelled out more.
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 coin, limit, and payment_signature are already documented in the schema. The description adds only marginal semantics: that omitting coin yields the all-perps ranking and that results are 'per side' (implying limit applies per side). Baseline 3 is appropriate when the schema carries the 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 verb and resource (rank funding-rate extremes across all Hyperliquid perps) plus the exact metric (top positive/negative hourly funding, annualized) and the optional single-coin scope. An agent can distinguish this from siblings like hyperliquid_whale_positioning or hyperliquid_market_brief without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'all perps ... or one coin' phrasing implies when the coin parameter applies, and the staleness/charging rules tell the agent the data must be fresh. However, it never explicitly contrasts itself with the sibling tools (market_brief, whale_positioning, feed_status) or states when to prefer one over the other, so usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call LLM-ready Hyperliquid perp market brief: funding extremes, whale positioning and liquidation clusters in one compact JSON. Hyperliquid public data only, ~3 min refresh, stale data never charged. $0.008 USDC via x402 from YOUR wallet. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds material operational facts beyond them: data scope ('Hyperliquid public data only'), freshness window ('~3 min refresh'), a billing guarantee ('stale data never charged'), the payment rail and payer ('$0.008 USDC via x402 from YOUR wallet'), and a disclaimer. For a paid tool this is exactly the kind of cost/freshness disclosure an agent needs before invoking.
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?
Dense but front-loaded: the deliverable and its contents come first, then data freshness, then price/payment, then the disclaimer. Each clause carries information; 'Not financial advice' is boilerplate but short and conventional for a paid market-data tool.
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 must characterize the return value, and it does ('one compact JSON' covering funding extremes, whale positioning, liquidation clusters). The main remaining gap is the absence of any mention of symbol/asset scoping — it is unclear whether the brief covers all perps or a specific market — which matters for a market-data tool with no parameters to narrow 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?
Schema description coverage is 100% for the single optional payment_signature parameter, and that schema text already explains the omit-to-receive-402 behavior. The description's 'via x402 from YOUR wallet' reinforces the payer identity but adds no syntax or format detail the schema lacks, 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?
Names a specific composite deliverable ('one-call ... market brief') and enumerates its contents: funding extremes, whale positioning, liquidation clusters. This implicitly separates it from the sibling single-signal tools (hyperliquid_funding_extremes, hyperliquid_whale_positioning, hyperliquid_whale_liquidation_levels), though it never names them 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?
The phrase 'one-call' implies this is the aggregated alternative to the three per-signal siblings, so the usage intent is inferable. However, there is no explicit when-to-use/when-not statement, no guidance on choosing this over hyperliquid_funding_extremes or the positioning tools, and no prerequisite framing beyond what the schema already says about payment_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange-reported liquidation prices of large tracked Hyperliquid accounts clustered near the current price, per coin. Hyperliquid public data only, ~3 min refresh, stale data never charged. $0.003 USDC via x402 from YOUR wallet. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional Hyperliquid perp ticker, e.g. BTC, ETH, SOL | |
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, yet the description adds real context: public-data-only sourcing, ~3 min refresh cadence, the 'stale data never charged' billing guarantee, and the x402 wallet-payment requirement. This is meaningful disclosure beyond the annotations, though it doesn't describe response shape or clustering thresholds.
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?
Four short sentences, front-loaded with what the data is, then freshness/billing, payment, and disclaimer. Every sentence carries information relevant to a paid data tool, with only the 'Not financial advice' line being borderline boilerplate.
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, two-parameter tool with no output schema, the description covers the data source, scope, freshness, pricing model, and payment mechanics. It omits detail on what 'clustered near the current price' quantitatively means and what the returned structure looks like, but nothing critical to invoking 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 (coin, payment_signature) are already fully documented, which sets the baseline at 3. The description implies the per-coin grouping and the payment flow but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'exchange-reported liquidation prices of large tracked Hyperliquid accounts clustered near the current price, per coin.' This is clearly distinguishable from generic market data. It does not explicitly route against the close sibling hyperliquid_whale_positioning, 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 ('clustered near the current price') and there is a partial workflow hint about omitting payment_signature to receive the live 402 offer. However, there is no explicit when-to-use vs alternatives guidance or when-not guidance relative to hyperliquid_whale_positioning or hyperliquid_funding_extremes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Net long/short positioning of large tracked Hyperliquid accounts per coin (notional, counts). Hyperliquid public data only, ~3 min refresh, stale data never charged. $0.005 USDC via x402 from YOUR wallet. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional Hyperliquid perp ticker, e.g. BTC, ETH, SOL | |
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description carries real extra weight: it discloses cost ($0.005 USDC), the payment source (the caller's own wallet via x402), the ~3 min refresh cadence, and a 'stale data never charged' guarantee. These are genuine behavioral facts beyond the annotations, though response shape and behavior when coin is omitted remain unstated.
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, front-loaded with what the tool returns, followed by freshness, price, and a short disclaimer. Nothing is redundant; the 'Not financial advice' line is boilerplate but defensible for a paid market-data tool.
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-required-param, no-output-schema tool, the description covers the essential decision inputs: cost, data provenance, freshness, and payment authorization. The only gap is the semantics of the optional coin filter (all coins vs. one), which neither the description nor schema resolves.
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 are already documented, including the x402 payment_signature mechanics. The description adds nothing about coin (e.g., what is returned if it is omitted) and only echoes 'per coin', 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 resource and scope: net long/short positioning of large tracked Hyperliquid accounts, per coin, returning notional and counts. It is clearly distinguishable from siblings like hyperliquid_whale_liquidation_levels or hyperliquid_funding_extremes, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the agent learns the price, the data source, and the staleness policy, which helps decide whether it is worth paying for. However, there is no explicit when-to-use/when-not guidance relative to the other Hyperliquid tools, and the 402/payment flow is only explained in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Lists immutable recorded paid responses (request, time, Base tx, sha256, verdict).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not repeat safety. It adds the 'immutable' property of the data and the 'Free' cost note, plus the fields returned. However, it omits pagination, ordering, or any indication of the response size or format, which would be useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the key point ('Free' and 'Lists') and efficiently packs the response contents. No wasted words; the description is compact and immediately informative.
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 parameterless list tool with no output schema, the description adequately states what it returns (the fields). It does not mention pagination, limits, or ordering, but these may be less critical given the simple nature. The tool is likely to return all records; a mention of any maximum or sorting would be a minor enhancement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%) and the description does not need to explain arguments. The baseline of 4 applies; no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists immutable recorded paid responses with specific fields (request, time, Base tx, sha256, verdict). This is a distinct verb-resource pair and differs from siblings like get_sample_report (which likely retrieves a single report) and the token safety checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It says 'Free' and lists contents, but does not mention get_sample_report as the option for retrieving a specific report, nor does it define any conditions for choosing this listing over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-trade safety grade for a Robinhood Chain (4663) ERC-20: signal, verdict, tier, owner type (Doppler-aware), clone/proxy detection, privileged functions, deployer+age, v2/v3/v4/Doppler liquidity, holder concentration, GoPlus honeypot cross-check. $0.01 USDC via x402 from YOUR wallet. Heuristic, not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ERC-20 address on Robinhood Chain | |
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the paid nature ($0.01 USDC via x402 from YOUR wallet), the heuristic nature ('not financial advice'), and a detailed list of checks performed. This gives the agent a strong behavioral model of what will happen when invoked, including a financial side effect.
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 dense but efficient: three sentences pack the purpose, checks, payment model, and disclaimer. It front-loads the core purpose before the enumeration. Slightly long but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, multi-faceted tool with no output schema, the description covers the request mode (token + optional payment signature), the payment mechanism, and the content of the report. It does not describe the exact return structure, but the enumeration of signals/verdicts/tiers gives a good picture. The schema fills the remaining gap about the 402 offer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters fully (100% coverage), so the baseline is 3. The description adds meaningful context by explaining the payment flow and pointing to get_payment_quote for signing the payment signature, going beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Pre-trade safety grade for a Robinhood Chain (4663) ERC-20', then enumerates the exact checks performed. It clearly differentiates from the Solana sibling by naming the chain directly, leaving no ambiguity about scope.
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 context is clear: use this before trading a Robinhood Chain token, and it is paid via x402. It references get_payment_quote for signing the payment signature, but does not explicitly state when to use alternatives like the sample reports or the Solana version. This is clear context without explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-trade safety grade for a Solana SPL mint: signal PASS/FLAG/FAIL, verdict, tier, authorities, RugCheck risks, LP lock, holders/top-10, Jupiter liquidity, momentum, sell-route honeypot check. $0.01 USDC via x402 (Base or Solana) from YOUR wallet. Heuristic, not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana SPL token mint (base58) | |
| payment_signature | No | Optional. Base64 x402 v2 PAYMENT-SIGNATURE you signed with your own wallet for this exact request (see get_payment_quote). Omit to receive the live 402 offer; nothing is charged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: readOnlyHint=true conflicts with the description's explicit statement that the call is paid and charges $0.01 USDC via x402 from the user's wallet, which is a side effect. The description does transparently disclose the heuristic nature, but the contradiction with the read-only annotation dominates this dimension.
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: the first front-loads the core output and scope, the second covers cost, payment mechanism, and disclaimer. Every sentence earns its place with no 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 paid, no-output-schema tool, it lists the key return fields, payment cost and mechanism, and the optional payment_signature path. The schema's payment_signature description references get_payment_quote, so an agent has the full workflow needed to invoke 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 schema already defines mint and payment_signature adequately. The description adds contextual payment information but no new parameter-level semantics beyond what the schema provides, hence 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?
The description uses a concrete verb and resource ('Pre-trade safety grade for a Solana SPL mint') and enumerates a specific output list (PASS/FLAG/FAIL, verdict, tier, authorities, RugCheck risks, etc.). The 'Solana' qualifier and safety-grade focus distinguish it from sibling robinhood_token_safety_check.
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 clearly frames when to use the tool: before a trade on a Solana SPL mint, and it explains the payment flow (omit payment_signature to receive an offer). It does not explicitly name alternatives or exclusions, but sibling context and the Solana-specific framing provide enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_payment_quote1 field changedInput schema / properties / chain / enumPrevious value: -[
- "solana",
- "robinhood"
-]New value: +[
+ "solana",
+ "robinhood",
+ "hl_funding",
+ "hl_liq_levels",
+ "hl_whales",
+ "hl_brief"
+]hyperliquid_feed_statushyperliquid_funding_extremeshyperliquid_market_briefhyperliquid_whale_liquidation_levelshyperliquid_whale_positioningget_payment_quoteget_sample_reportlist_sample_reportsrobinhood_token_safety_checksolana_token_safety_checkHyperliquid perp funding, OI, preflight & news sentiment for agents. Pay per call in USDC (x402).
Read-only Hyperliquid analytics: orderflow, liquidation levels, whale positioning, funding.
Live Hyperliquid perps analytics for agents: funding, OI, whale prints, leaderboard, wallet risk.
Read-only Hyperliquid funding screens via x402 v2/Solana; not positions or returns.
Add one secure layer between your agents and this server.