hypernatt-terminal

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

Without annotations, the description carries full behavioral disclosure. It states the tool returns a catalog with live usage stats and proof of edge, implying a read-only operation. It does not mention side effects, which is appropriate. The 'Free.' note hints at no cost. A slightly higher score would require explicit read-only declaration.

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, concise sentence that front-loads the key directive ('Start here'). Every word serves a purpose, with no redundancy. Highly 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers its main purpose and contents. It could mention that it returns the list of sibling tools, but the provided context is sufficient for an agent to understand its role as a starting point. Slight gap in not specifying return format.

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

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

The input schema has one optional parameter (locale) with 100% description coverage. The tool description does not mention the parameter, adding no additional meaning beyond the schema. Baseline 3 is appropriate since schema already describes it adequately.

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 is an entry point ('Start here') that provides a catalog of 9 terminal tools with prices, usage stats, and proof of edge. It uniquely distinguishes from sibling tools (which are the tools being cataloged) and specifies the resource and outcome.

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 'Start here,' indicating it should be used before other tools. It implies the context as an introductory or discovery tool. While it doesn't provide explicit when-not-to-use or alternatives, the context is clear given the tool's role as a catalog.

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

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

The description fully discloses behavioral traits: return structure (v1/v2 with chain_snapshot, etc.), cost ($0.001 via x402), side effects (none), and special behavior for HOLD direction (not charged). Since no annotations exist, the description carries the full burden and meets it completely.

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 and well-structured with clear sections (USE WHEN, NOT WHEN, RETURNS). Every sentence provides useful information without redundancy. Slightly verbose for the cost/return details, 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?

Given the complexity (payment, multiple params, no output schema), the description covers return values, usage conditions, and side effects adequately. The lack of detailed output structure is mitigated by mentioning key fields. Could benefit from explaining 'hypernatt_mimo_cycle_state_v1' but acceptable.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the effect of full_payload (per-leg detail) and the payment flow for x_payment. This goes beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: providing a real-time Mimo cycle signal (LONG/SHORT/HOLD) for aligning with the BTC vault. It uses specific verbs and explicitly distinguishes from siblings like get_mm_trap_state.

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?

Explicit 'USE WHEN' and 'NOT WHEN' directives are given, including specific conditions and naming an alternative sibling tool (get_mm_trap_state). This provides clear guidance on appropriate use.

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?

No annotations provided, so description carries full burden. Discloses read-only nature ('Redacted, read-only'), cost ($0.001 flat via x402), and side effects ('none'). However, 'Redacted' is somewhat vague; more detail on what is redacted would improve transparency.

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?

Single paragraph front-loads purpose, then provides usage guidance, return structure, cost, and side effects. Every sentence adds value; no filler. Efficient and well-structured.

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?

No output schema, so description must describe returns. It lists the return object (hypernatt_liq_radar_v1) and key fields (magnet_score, magnet_bias, etc.). However, it doesn't explain the meaning of each field, which might be needed for an agent to interpret the data correctly. Still, for a well-named tool, this is good.

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 100% schema coverage, the schema already documents both parameters. The description adds crucial context: for x_payment, explains the payment flow (omit first call to receive 402 instructions); for agent_wallet, explains optional quota alternative. This exceeds the schema's basic descriptions.

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

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

Clearly states it provides 'Raw BTC liquidation radar' with specific data points (magnet score, OI build-up, ratios, clusters). Distinguishes from sibling tools by naming alternatives (get_mm_trap_state, get_mm_hunt_score).

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

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

Explicitly states 'USE WHEN' and 'NOT WHEN' with sibling tool names, providing clear context for selection. No ambiguity about when to use this tool vs alternatives.

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 burden and provides cost, side effects, and return structure. It lacks explicit authentication details, but the payment info implies the access model.

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, well-structured with clear sections, and front-loaded with the core purpose. Every sentence adds value without 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?

Given no output schema, the description thoroughly documents the return fields, cost, side effects, and usage guidance. It provides all necessary context for an agent to invoke the tool 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 coverage is 100% and the inputs are self-descriptive. The description adds no additional parameter semantics beyond what the schema already provides, meeting the baseline.

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

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

The description clearly states the tool's purpose: assessing MM hunting pressure with a one-line liquidation summary. It distinguishes from siblings by specifying alternative tools for different use cases.

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?

Explicit 'USE WHEN' and 'NOT WHEN' sections provide clear guidance on when to use this tool vs. alternatives (get_mm_trap_state, get_liq_radar), which is exemplary.

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?

No annotations provided, but the description fully covers behavioral aspects: read-only, no trade advice, side effects none, cost, and lists all return fields.

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

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

Every sentence is valuable and well-structured: purpose, use cases, returns, cost, side effects. No wasted words.

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

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

The description is complete despite no output schema, covering all necessary context for a state-checking tool with payment and quota.

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 description adds significant context: payment flow (omit header for instructions), quota system, and parameter purpose beyond schema descriptions.

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

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

The description clearly states the tool checks if the MM is trapping BTC, and distinguishes from siblings by noting it's not raw cluster data. It uses specific verbs and resources.

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 provides explicit USE WHEN and NOT WHEN conditions, naming sibling tools get_mm_hunt_score and get_liq_radar for contrast.

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?

No annotations provided, so description carries full burden. It discloses cost ($0.001 flat via x402 on Base), side effects (none), return structure, and warns against misinterpreting similarity_pct as win probability. Lacks details on rate limits or authentication, but overall 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?

Description is well-structured with sections (purpose, usage, returns, warnings, cost, side effects) and front-loaded with the key question. Every sentence adds value, though slightly verbose.

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?

Despite no output schema, the description details the return structure (hypernatt_similarity_match_v1 with fields) and includes cost, side effects, and warnings. For a tool with 3 optional params, this is highly 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 has 100% coverage of 3 parameters with clear descriptions. The description does not add significant new information about parameters beyond what schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns top-3 historical regime matches based on BTC microstructure with about 4h BTC outcomes. It distinguishes from siblings like get_btc_usdc_signal and get_mm_trap_state by explicitly stating when to use and not use.

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?

Provides explicit USE WHEN ('analogies / regime context only') and NOT WHEN ('trade direction, live trap, or sizing') with specific alternative tool names (get_btc_usdc_signal, get_mm_trap_state), giving clear 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?

Description discloses output content and that it's free, but no annotations exist. For a zero-parameter read-only tool, behavioral traits are minimal; description adequately covers what the tool does.

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, front-loaded with a catchy phrase. While effective, the first sentence could be slightly more direct; overall concise and clear.

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

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

Given no output schema and no annotations, description satisfactorily explains what the tool returns. Lists three key elements. Could mention formal output type, but adequate for a simple proof retrieval.

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?

No parameters, so schema coverage is 100%. Description adds meaning by enumerating the proof components (vault address, URLs, signed hash), which is more informative than an empty 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?

Description clearly states the tool provides a 'proof' with specific elements (on-chain vault address, public URLs, signed cycle hash) and its purpose (verify live BTC trades). Verb 'get' and resource 'vault proof' are explicit, distinguishing it from sibling tools.

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 use case ('Verify our live BTC trades yourself'), but lacks explicit when-to-use/when-not-to-use or alternatives. Since no sibling tool directly competes, guidance is adequate but not fully explicit.

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?

Discloses key behaviors: free (no x402), no side effects, returns quote JSON. Lacks details on error responses or network dependency, but adequately covers cost and safety for a read-only quote tool.

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

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

Three focused sentences front-loaded with purpose, usage, and return info. No redundancy, every sentence adds value.

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?

Covers purpose, usage, return type, cost, and side effects. Without output schema, the return description helps. Minor gaps: no mention of freshness or caching, but adequate for a preview quote 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 covers 100% of parameters with descriptions. The description adds no per-parameter value beyond the schema. Baseline 3 is appropriate.

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

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

Clear verb+resource: 'swap quote'. Explicitly contrasts with swap_via_nattswap, stating it returns raw JSON without execution steps. Distinct from sibling tools.

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?

Explicit 'USE WHEN' and 'NOT WHEN' with direct reference to sibling swap_via_nattswap for step-by-step execution. Provides clear decision context.

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?

No annotations provided, so description shoulders full burden. It discloses side effects (MCP read-only until wallet signs), costs (gas + integrator fee), and return format. Could be more explicit about post-signing execution, but overall adequate.

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?

Paragraph is dense but covers purpose, usage, returns, costs, and side effects without redundancy. Slightly unstructured but 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?

No output schema, but description specifies return items (route JSON, step-by-step instructions, recommended_action). For a swap tool, this is sufficient context given sibling swap_quote provides quotes.

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 each parameter documented. The description adds context about the overall swap capability but does not enhance individual parameter meanings beyond 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?

Description clearly states it performs cross-chain token swaps via Li.Fi across 70+ chains, including Hyperliquid, and explicitly mentions any pair not limited to BTC/USDC. It distinguishes from sibling tools like get_btc_usdc_signal by specifying 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?

Explicitly lists USE WHEN scenarios (bridge, fund gas, treasury routing) and NOT WHEN scenarios (Decision Core BTC reads), providing clear guidance on when to invoke this tool vs. siblings.

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