jarvis-market-signals

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 data source (DefiLlama), safety filters, and output format (ranked list with verdict). However, it lacks details on update frequency, caching behavior, or potential side effects. The tool appears read-only, and the description does not contradict this.

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 and conveys essential information clearly. It could be slightly more concise (e.g., 'live data (DefiLlama)' could be integrated), but overall it is efficient and front-loaded with the most critical information.

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 tool with one optional parameter and no output schema, the description covers purpose, usage context, data source, and key criteria. It lacks a precise description of the return format (e.g., list of protocol names with APY values), but the mention of 'ranked by emission-discounted APY' gives a reasonable expectation.

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 0% description coverage for the single parameter principal_usd. The description does not mention this parameter or explain how it affects the output. With low schema coverage, the description must compensate, but it fails to do so, leaving the agent unsure about the parameter's role.

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 defines the tool's output: safe stablecoin lending yields with specific criteria (no IL, audited protocols >$50M TVL, ranked by APY, compared to T-bill floor). It clearly distinguishes from sibling tools like coin_liquidations and convert_currency, which address different financial needs.

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 explicit usage guidance: 'Use when an agent needs a current, risk-graded read on where idle stablecoins can safely earn.' It provides context but does not explicitly list when not to use or name alternatives. However, given the distinct nature of siblings, this is sufficient.

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 must carry behavioral disclosure. It mentions live streaming data, implying real-time/non-destructive. However, lacks details on rate limits, data retention, or whether it's historical or only recent. Not contradictory but incomplete.

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 concise sentences with key information front-loaded. No redundant words. Each sentence adds value: first explains output, second adds source context.

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 and no annotations, description should compensate. Lacks details on output format (e.g., list of liquidations, units), max/min values for window_minutes, or whether results are paginated. Incomplete for an agent to use reliably.

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% coverage (no parameter descriptions). Description adds meaning for coin (examples BTC, ETH, SOL) but only vaguely for window_minutes ('over the last N minutes'). Does not specify format, constraints, or that both parameters are simple types.

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 recent perp liquidations for one coin, with breakdown by long/short notional and count, plus largest single liquidations. Source (Bybit streaming data) is specified. Distinguishable from siblings like liquidation_summary (aggregated) and 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?

No explicit guidance on when to use this vs siblings. Does not state prerequisites or typical use cases. Only implies focus on single coin, but no 'when not to use' or alternative tool recommendations.

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 exist, and the description only mentions 'deterministic and current' and 'ECB rate'. It lacks disclosure on rate update frequency, supported currencies, or potential fees.

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, both front-loaded with purpose and a memorable hook. No unnecessary 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?

Despite low complexity, the lack of parameter details, output schema, and behavioral context makes it incomplete. An agent needs more information to use it 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 0%, and the description does not explain any parameters. It only says 'Convert an amount between fiat currencies', with no details on currency code format, amount constraints, or required format.

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 converts fiat currencies using live ECB mid-market rate. It distinguishes from sibling crypto tools by focusing on fiat currency conversion.

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 implies usage for fiat conversion but does not provide explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned.

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 discloses live data and the selection of stretched rates, and explains the meaning of positive/negative funding. However, it does not detail data limits, pagination, caching, or the exact number of rates returned, 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 concise with two efficient sentences that front-load the main purpose and add useful context without 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?

The description gives good context for usage and basic behavior, but lacks a description of the output format or fields returned, which is important since there is no output schema.

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 description explains the 'coin' parameter with an example, but does not mention the 'limit' parameter or its default value, leaving a significant gap given the 0% schema description coverage.

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 current perpetual-futures funding rates from Bybit, with a focus on the most stretched rates. It distinguishes from sibling tools like best_stable_yield and coin_liquidations by specifying its exact resource and signal nature.

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 explains the tool as a crowding/sentiment and carry signal for trading agents, and mentions optional filtering by coin. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for appropriate invocation.

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 discloses key behavioral traits: live Bybit feed, 24/7 updates, window_minutes capped to 24h buffer, and that data is streaming (not cached). With no annotations, this provides good transparency, though it omits potential rate limits or error handling details.

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 slightly verbose but front-loads the main purpose and includes valuable context (e.g., cascade/short-squeeze signal). Every sentence adds value; though it could be more terse, it remains 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 lack of annotations and output schema, the description provides a solid overview of inputs, behavior, and returned data elements (total LONG/SHORT, event count, etc.). It does not specify exact output structure, but the summary is sufficient for most agents.

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 only defines window_minutes with a default, lacking description (0% coverage). The description adds meaning by explaining it's 'over the last N minutes' and 'capped to the rolling 24h buffer', effectively compensating for the schema gap.

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 a live market-wide crypto perp-liquidation summary over the last N minutes, listing specific data points (total LONG vs SHORT, event count, dominant side, top coins). It distinguishes itself from sibling tools like coin_liquidations by focusing on aggregated summary data and real-time updates.

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 implies use for real-time liquidation monitoring, stating 'Fresh streaming data a static model can't know', but does not explicitly contrast with sibling tools or state when not to use it. No alternative guidance is provided.

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 fully handles behavioral disclosure. It states the data source (Bybit), update frequency (24/7), key inputs (OI, funding, liquidations), and the window_minutes cap. It does not cover authentication or rate limits, but the core behavior is well explained.

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 moderately dense but efficiently conveys all critical information in a few sentences. It front-loads the purpose and key differentiator (live vs. static model). Could be slightly more concise, but no unnecessary 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 the lack of annotations and output schema, the description provides sufficient context for a signal tool with two parameters. It could mention the return format or what happens with no data, but overall it is complete enough for an AI agent to understand usage.

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%, so the description must add meaning. It explains 'coin' as an optional filter (e.g., 'BTC') and 'window_minutes' as capped to a rolling 24h buffer with a default of 240. This adds context beyond the schema's type and default.

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 a 'Live crypto perp POSITIONING signal' that tells whether leveraged positions are building or unwinding, combining OI change, funding rate, and liquidations. It distinguishes itself from sibling tools like 'funding_rates' and 'liquidation_summary' by offering a synthesized signal.

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 explains when to use the tool (to assess positioning buildup, squeeze risk, deleveraging) and mentions optional filtering by coin and the window_minutes cap. It does not explicitly state when not to use it versus alternatives, but the context is clear.

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