hypernatt-terminal

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that it's free, includes trial status, and that detail=full adds quota/pass/onboarding, which is useful. However, it never explicitly states the operation is read-only, side-effect-free, or idempotent, nor does it warn about rate limits or token consumption. For a simple manifest retrieval this is acceptable but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, dense sentence that front-loads the critical 'Start here (free)' signal, then lists contents, guidance to siblings, and parameter semantics. Every clause adds value; no fluff. The structure is logical and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has only 2 parameters, both fully described in the schema, and no output schema. The description explains what the manifest contains (tools, prices, trial status, journeys) and how to adjust detail level. It does not specify the exact return format, but for an overview tool that's a minor omission. Given the simplicity, the description is reasonably 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%: both 'detail' and 'locale' are described. The description adds a small extra semantic by noting 'Compact includes arguments' (the schema only says 'Default compact' without specifying contents). It also reiterates the 'full' behavior, which is redundant. Overall it adds marginal value beyond the schema, but not enough to raise above 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 a specific verb+resource: 'Start here' and 'get_agent_manifest' clearly indicates fetching the manifest of the 4 tools, including prices, trial status, and journeys. It explicitly names the three sibling tools, distinguishing itself as the overview rather than the individual tools. No ambiguity.

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

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

The description says 'Start here (free)' which tells the agent this is the entry point, and 'Choose liquidation radar, native BTC/ETH depth or Li.Fi swap' indicates that after retrieving the manifest, the agent should select one of those tools. It does not explicitly say 'use this when you need to decide which tool to use' or exclude cases, but the intent is clear. It lacks explicit alternatives or when-not-to-use guidance beyond the implicit start-here positioning.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses cost, side effects, return object name, and the 'not a trade signal' caveat, plus interpretation rules for output classes. It does not explain authentication or payment flow, but the schema covers that, and the description adds meaningful 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?

The description is compact with labeled sections, but the middle is a dense run of fragments ('Also magnet, OI, L/S, clusters, real liqs.') that is hard to parse. It is not bloated, but it sacrifices clarity for brevity and does not front-load the core purpose.

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 explain what the agent receives and how to interpret it. It names the return object and some class semantics, but leaves central terms like liq_radar, cluster_grammar, magnet, OI, and L/S undefined. An agent unfamiliar with this domain cannot fully judge whether the tool fits the task.

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

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

Schema description coverage is 100%, so the schema already documents symbol, x_payment, and agent_wallet in detail. The description's whitelist and 'omit=BTC' largely duplicate the symbol enum rather than adding new parameter semantics. 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 never states a clear verb+resource. It opens with an opaque instruction about cluster_grammar and only later says 'RETURNS: hypernatt_liq_radar_v2.' The 'USE WHEN: terrain / timing / sizing' hint implies the tool provides liquidity terrain data, but an agent would struggle to state confidently what this tool does.

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

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

The description gives explicit usage context with 'USE WHEN: terrain / timing / sizing' and an exclusion with 'NOT a trade signal.' It also advises reading cluster_grammar first when present. However, it does not name sibling alternatives or explain when another tool would be preferable.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it warns that aggregated views see wider price ranges at coarser precision, that volumes should never be summed across views, that there is no strategy signal, no full-book claim, and no fill guarantee. It also discloses the price per call. This is strong added context, though it doesn't detail the exact output shape 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?

The description is dense but well-structured: it front-loads the core resource and views, then adds usage warnings, then pricing. Every sentence carries information, though the density of domain-specific terms (REF, M2, M5, AGG4) without expansion slightly reduces accessibility. It earns a 4 rather than 5 because a bit of structural separation (e.g., a sentence on when to use vs. siblings) would improve scannability.

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 market-data tool with no output schema, the description covers the key context: what data is included, the time windows, the aggregation caveat, the companion tools, and the payment method. It doesn't describe the exact response format, but the description's explicit caveats and usage guidance make it complete enough for an agent to invoke correctly. A 5 would require a bit more on the return structure or a clearer when-to-use statement relative to siblings.

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 83%, so the schema already documents most parameters. The description adds semantic context by explaining the lookback window (30s/300s) and the meaning of the four views, which helps an agent understand how quantity_base, side, and symbol relate to the returned data. It doesn't add much beyond the schema for individual parameters, but the baseline is 3 and the description's market-context framing adds value.

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

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

The description names a specific resource (BTC/ETH perpetual market context) and a specific verb (get/read), and enumerates the four liquidity views (REF, M2, M5, AGG4), size coverage, wall changes, and aggressor flow. It clearly distinguishes itself from siblings by describing a market-data read tool, not a manifest, radar, or swap tool.

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

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

The description explicitly says to combine with liquidation radar, read agent_readout and quality first, and warns against adding overlapping volumes in aggregated views. It also states the pricing/payment context (x402 Base/Solana or credits) and the 30s/300s window choice, giving an agent clear when-to-use and how-to-use guidance.

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

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

With no annotations, the description carries the full burden and does so well: it discloses cost structure (gas + HyperNatt 0.25% integrator fee, possible Li.Fi cut, plus where to read it), the guidance to sign swap_actions_v1 in order, and the crucial safety fact that the MCP is read-only until the wallet signs.

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 purpose, then labeled USE WHEN / RETURNS / cost / side-effect blocks, so an agent can scan it quickly. The fee sentence is dense with nested parentheticals but still 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 7-required-param swap tool with no output schema, it covers the return shape (Li.Fi route, execution_readiness, swap_actions_v1), the signing order, and the cost model. Minor gaps remain around error/quote failure handling and slippage defaults.

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 every parameter is already documented in the schema. The description adds no syntax, format, or default detail beyond that (e.g. slippage defaults, chain-id discovery), 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 (swap) and resource (cross-chain tokens) plus provider (Li.Fi) and scope (70+ chains incl. Hyperliquid). Given the siblings are manifest/liquidity-depth readers, no further differentiation is needed for an agent to select this one.

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?

"USE WHEN: bridge, fund gas, treasury routing, or rebalance" gives explicit trigger scenarios. It stops short of naming when NOT to use it or pointing to an alternative, so it falls just under a 5.

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