TNT House Risk-Data API

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

With no annotations, the description carries the full burden. It discloses the substantial outputs and implies a read-only, pre-trade check by saying 'Returns' and 'before recommending or executing a trade.' It does not cover rate limits, data freshness, or possible failure modes, but the core behavior is well conveyed.

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 sentence that packs a wealth of specific detail (score, clusters, authority, concentration, price/liquidity/volume) plus a clear usage directive. It is dense but well-organized, with no filler or repetition.

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 covers the main return items and usage intent, and clarifies the tool handles a single mint (distinguishing it from batch). Since there is no output schema, the description adequately outlines what to expect, though it omits exact structure or error behavior. Overall quite complete for a simple one-parameter check.

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 describes the 'mint' parameter fully ('The Solana token mint address to check'). The description adds only that it is for a 'single' token mint, which is minor and does not materially enhance the schema's semantic coverage. 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?

The description clearly states the tool returns a specific safety score (0-100) and multiple on-chain analytics (insider clusters, authority status, holder concentration, price/liquidity/volume) for a single Solana token mint. The phrase 'single Solana token mint' also distinguishes it from the sibling batch and history 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?

The description gives an explicit when-to-use directive: 'Use before recommending or executing a trade on any Solana token.' However, it does not mention alternatives like check_token_risk_batch or get_token_risk_history, nor any when-not-to-use scenarios, so it falls just short of a 5.

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 adds valuable behavioral context: batch charging (N mints as N calls), no bulk discount, and all-or-nothing quota/credit enforcement. It does not explicitly state whether the operation is read-only, but 'check risk' implies a read operation and the pricing/all-or-nothing rules are useful disclosures.

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, front-loaded with the core purpose, and every sentence adds value: batch size, pricing, and all-or-nothing behavior. No fluff.

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 batch tool, the description covers batch limit, pricing, and failure behavior. It relies on the sibling tool for deeper semantics, which is acceptable. No output schema exists, but the description doesn't need to explain return values since it is identical to check_token_risk.

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 'mints' described as '1-25 Solana token mint addresses', so the schema already explains the parameter. The description adds little beyond referencing check_token_risk for semantics and the batch limit, which is already in maxItems. 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 clearly states it is the batch version of check_token_risk for up to 25 mints in one call, with a specific verb ('check risk') and resource ('multiple Solana tokens'). It also distinguishes from sibling check_token_risk by emphasizing the batch capability.

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 explicitly says 'Same as check_token_risk' and specifies the batch context, which implies using this when checking multiple tokens. It mentions no bulk discount and all-or-nothing behavior, but does not explicitly name alternative tools or when not to use it.

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. It discloses that the tool is a pure read from stored history, does not make a live upstream call, and does not count against quota. It also notes the hourly granularity and max 90 days, which are useful behavioral details. It does not mention error handling or edge cases, but the coverage is solid for the tool's simplicity.

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 concise sentences. The first sentence covers the core purpose and outputs, the second explains the quota and upstream behavior. Every clause adds value, and the most important information is 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?

The tool has a simple interface (2 params, no output schema), and the description lists the returned data fields, which partially compensates for the missing output schema. It explains the time range and quota behavior. It could mention potential default behavior (e.g., default days=30) or pagination, but these are already in the schema for the parameter. Overall, it is adequately complete for the tool's 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?

Schema coverage is 100%, with both 'mint' and 'days' having descriptions in the input schema. The description adds no new parameter-level semantics beyond reinforcing that 'days' is capped at 90, which is already in the schema. Therefore, the description meets the baseline but does not exceed it.

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 hourly historical data points with a specific list of fields (safety_score, insider_cluster_count, holder_count, price, liquidity, volume) for a mint, over a time range. It distinguishes itself from siblings (check_token_risk, check_token_risk_batch) by emphasizing the historical nature and the absence of a live upstream call.

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 clear context for when to use this tool: when you need historical data without consuming quota or making a live call. It implicitly contrasts with the sibling tools that likely perform current checks, though it does not explicitly name alternatives or say 'use this instead of X when Y'.

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