ensotrade

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses live order-flow and positioning, and returns a sentence plus structured signals. This is sufficient transparency for a read-only query 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?

The description is three sentences with no fluff. It is front-loaded with the purpose and provides all necessary context efficiently.

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 has one parameter, an output schema (implied), and clear usage examples, the description is complete. No gaps remain for the agent to select and 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 description coverage is 0%, but the description explicitly defines the parameter: 'coin = ticker like btc, eth, sol.' This adds full meaning beyond the schema's type-only specification.

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 explains WHY a crypto coin is moving using live data. It provides example questions and distinguishes itself from siblings like get_funding or market_snapshot by focusing on causal explanation.

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 'Use this for...' and gives examples of when to invoke it. It does not explicitly mention alternatives or when not to use, but the context with sibling tools makes it clear.

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?

Without annotations, the description carries the full burden. It explains that the tool returns current funding rate and crowding information, and indicates whether longs or shorts are paying/crowded. However, it does not disclose potential side effects (likely read-only), error handling, or rate limits, leaving some behavioral aspects unclear.

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 short and to the point, with two sentences plus a parameter note. It is front-loaded with purpose and examples. Could be slightly more structured, but overall concise with 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?

Given a single parameter and an output schema present, the description adequately covers the tool's purpose and usage. It explains the kind of data returned (funding rate and crowding). It lacks details on prerequisites or error scenarios, but for a simple read tool this is sufficient.

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 0% as the parameter 'coin' has only a type string with no description. The tool description adds 'coin = ticker e.g. 'btc'', which provides meaningful context and an example, compensating for the lack of schema 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 clearly states the tool retrieves the current perpetual funding rate and crowding read for a crypto coin, with examples like 'funding rate on <coin>' and 'is funding positive'. It distinguishes itself from siblings which likely focus on other aspects like order flow or market snapshots.

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 usage contexts: 'Use for "what's the funding rate on <coin>", "is funding positive".' This helps the agent know when to invoke it. However, it does not explicitly mention when not to use or mention alternatives, but the sibling tools list provides implicit differentiation.

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 are provided, so the description must cover behavioral aspects. It mentions the output conceptually (interpretation of moves) but lacks details on data freshness, error handling, or any side effects. This is adequate but not exhaustive.

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 plus a concise parameter note. Every part adds value, no redundancy. The key functionality 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 description covers input, output concept, and use cases. With an existing output schema, return values are separate. A single parameter makes this complete and self-contained.

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 coverage, the description adds needed meaning: it defines 'coin' as a ticker with example 'btc'. This compensates well for the missing schema documentation, though format specifics are omitted.

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 explicitly states it provides 'positioning regime + open interest + recent taker imbalance' for a crypto coin, and distinguishes from siblings by focusing on order flow analysis rather than general market snapshot or funding rates.

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 suggests use cases like 'crypto order flow', 'open interest change', 'is this a short squeeze', which is clear guidance. However, it does not explicitly contrast with sibling tools or state when not to 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?

With no annotations, description carries burden. It indicates live, real-time data and lists metrics, but does not disclose potential side effects, rate limits, data freshness, or authorization needs. Adequate but not rich.

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, zero waste. Front-loaded with purpose and key metrics. Parameter explanation integrated efficiently.

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 output schema existence (relieves need to explain returns), description lists metrics. Missing details like error handling or authentication, but sufficient for a simple snapshot 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 has 0% description coverage; description compensates by explaining the 'coin' parameter with example format ('e.g. 'btc''). Clearly defines what user must provide, though no additional constraints like allowed values.

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 provides a combined live snapshot for a crypto coin, listing specific metrics (price, 24h change, funding, open interest, perp basis, positioning regime). It distinguishes from siblings which are more specialized tools (explain_move, get_funding, etc.).

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 when an overall market view is needed ('One combined live snapshot'), but does not explicitly state when to use versus alternatives, nor provide when-not scenarios or prerequisites.

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 are provided, so the description bears full responsibility. It states the tool returns data 'right now' but does not disclose the time horizon (e.g., 24h), metric type (percentage vs absolute), or how the 'limit' parameter affects results. Missing details on ordering and error states reduce 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?

The description is extremely concise, consisting of two efficient sentences. The first sentence delivers the core purpose immediately, and the second provides example queries. Every word 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?

Although an output schema exists (which may clarify return values), the description omits critical context: the time period for moves, whether gains/losses are percentage or absolute, and how results are sorted. For a tool with one optional parameter and no annotations, this leaves significant gaps for correct invocation.

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 0% for the only parameter 'limit', and the description does not explain it. The agent must infer that 'limit' controls the number of results, but no unit or default behavior beyond the schema's default of 10 is clarified. The description adds no value over 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?

The description clearly states it provides top gaining and losing crypto perpetuals, ranked across the whole market. It distinguishes from sibling tools like 'explain_move' or 'market_snapshot' by focusing specifically on movers. However, it does not specify whether the ranking is by percentage or absolute change, which slightly reduces clarity.

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 includes example queries like 'top crypto movers' and 'biggest crypto gainers and losers today', which imply appropriate usage contexts. However, it does not explicitly state when to use this tool versus alternatives like 'market_snapshot', nor does it mention 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.