netintel_crypto_ohlc

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

With no annotations the description carries the full burden, and it does disclose meaningful traits: data provenance (Coinbase Exchange with Kraken fallback), no API key required, and a hard cap of 300 candles. It says nothing about rate limits, failure behavior when both sources miss, or the shape of the returned data, leaving real gaps for a data-fetch 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?

Dense and front-loaded — the primary purpose and its limits come first, with the alternate mode last. It is appropriately short for the information conveyed, though the final clause trails off ('for…'), leaving an unfinished thought that slightly hurts the structure.

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 and no annotations, so the description is the only source of truth for a 5-param tool with 0% schema coverage. It covers purpose, sources, limits, and two modes but is truncated mid-sentence and never resolves the remaining parameters, so an agent still cannot call it confidently.

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% across 5 params, so the description must compensate. It supplies the date format (YYYY-MM-DD), the interval values (hourly/daily), the candle ceiling, and the asset scope for symbol, but leaves 'vs' (quote currency) and 'days' completely unexplained. Partial compensation, not full.

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: 'Historical OHLC candles for any major crypto asset,' with scope qualifiers (hourly or daily, up to 300 candles) and a named second mode. It is clearly distinguishable from spot-price tools like netintel_crypto_price in substance, but it never names a sibling to route against, so it stops short of a 5.

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?

Gives operational guidance for the primary mode (interval granularity, candle cap) and shows the alternate invocation ('pass date=YYYY-MM-DD'), which is implied when-to-use. However it never says when to prefer this over netintel_crypto_price / netintel_crypto_market, nor any exclusions or prerequisites, so guidance remains implied rather than explicit.

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