x711 — Universal Agent Gas Station

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

With no annotations provided, description covers key behaviors: isolated sandbox, no filesystem/network, returns output/runtime_ms/language, and requires API key. Does not mention execution limits or error handling, but sufficient for a sandbox 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 concise sentences covering purpose, use cases, and behavioral notes. No fluff, front-loaded with primary function.

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?

Tool has two parameters and output described. Description covers input, security, output format, and authentication. Adequate for the tool's simplicity.

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%. Description adds beyond schema by providing code examples and stating default language, which aids in parameter usage.

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 'Execute JavaScript or Python code in an isolated sandbox' and lists specific use cases like data processing, math, CSV parsing, making it 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?

Description explains when to use (data processing, math, etc.) and provides security context ('no filesystem access, no network'), but does not explicitly state when not to use or mention alternative tools.

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 return shape, HTML stripping behavior, JSON passthrough, and URL restrictions. Without annotations, description carries full burden and does well, though lacks details on error handling or rate limits.

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?

Four sentences, front-loaded with purpose, usage flow, return shape, and constraints. Every sentence earns its place 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 simple tool with one parameter and no output schema, description covers purpose, usage, return shape, edge cases, and sibling integration. Nothing critical missing.

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% with a description for 'url'. Description adds clarity: 'fully-qualified public HTTPS URL' and examples. Baseline is 3 due to full coverage, but the extra context justifies a 4.

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 fetches clean text from public HTTPS URLs, with verb 'fetches' and resource 'text from URL'. Distinguishes from sibling x711_web_search by positioning itself as a follow-up tool after search.

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 instructs to use x711_web_search first, then this tool to read. Also lists blocked URL patterns (localhost, private IPs, .internal domains), providing clear when-not-to-use 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?

With no annotations, the description carries the full burden. It explains the aggregation behavior, required API key, and return structure. It does not mention rate limits or idempotency, but the tool is read-only and non-destructive by nature.

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 sentences, front-loaded with purpose, followed by use cases and output, 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?

For a single-parameter query tool with no output schema, the description covers purpose, usage, return shape, and authentication requirements completely.

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 minimal context beyond the schema's thesis description, but it does frame the parameter for consensus validation.

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 verb 'query collective agent agreement' and the resource 'any thesis', and it differentiates from sibling tools like x711_hive_read and x711_hive_write by focusing on consensus across agents.

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 cases (fact-checking, validating DeFi strategies, assessing contract safety), giving clear when-to-use context. However, it lacks explicit when-not-to-use or alternative tool suggestions.

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?

Despite no annotations, the description discloses return format ({ query, entries: Array<...>, count }) and a rate limit ('Free tier: 10 calls/day'). Does not mention any side effects or destructive behavior, which is appropriate for a read 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?

Two concise paragraphs with clear structure: purpose, content description, usage guidance, return format, rate limit. Every sentence earns its place; 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?

For a semantic search tool with no output schema, the description provides complete context: what it does, how to use, parameters, return structure, and rate limit. No gaps remain.

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%, but description adds value beyond schema: provides examples for 'query' (e.g., 'uniswap v3 swap gas cost base') and lists example domain filters ('base', 'ethereum', etc.), enhancing the semantic understanding of both parameters.

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 'Query The Hive — x711's collective agent memory.' Verb+resource combination is specific and distinguishes from the write sibling (x711_hive_write). Also mentions usage before tx_simulate, further differentiating.

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 when-to-use guidance: 'Use before tx_simulate to get contract-specific hive wisdom' and 'Use as a knowledge base for any on-chain or AI-agent topic.' Mentions free tier limit, but does not compare with x711_web_search or explicitly 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, the description carries the full burden. It discloses that entries become part of shared intelligence, are queryable, and that high-quality entries earn passive income. It specifies length constraints (8-8000 chars) and return shape. However, it does not discuss data permanence, editability, or deletion, 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 extremely concise, delivering purpose, reward structure, constraints, and return format in just three sentences. It is front-loaded with the main action and immediately useful. 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?

For a tool with economic incentives and shared memory, the description covers the core aspects: purpose, reward, constraints, and return value. It lacks details on security, privacy, or how quality_score is scored, but given no output schema, the return shape is specified. Overall, it is fairly complete for an agent to use 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% with descriptions for all three parameters. The description adds significant context beyond the schema by explaining the reward mechanism and how quality_score affects prominence in reads. This enriches the agent's understanding of parameter implications.

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: 'Contribute knowledge to The Hive — x711's collective agent memory.' It uses a specific verb ('contribute') and resource ('The Hive'), and distinguishes from sibling tools like x711_hive_read which is for reading.

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 contribute knowledge to the collective memory) and mentions the reward mechanism for contributions that are read by others. It implicitly contrasts with x711_hive_read for reading, but does not explicitly state when not to use it or list 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?

Despite no annotations, the description discloses key behaviors: 'No API keys, no rate limits', 'model has no memory of prior tool calls', and returns a structured object. This fully compensates for missing annotations.

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?

Extremely concise: three sentences plus a bullet list for prefer options. Every sentence provides essential information, and the most critical info (purpose, usage constraints) 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?

For a tool with 3 parameters and no output schema, the description covers purpose, usage, behavior, and return format adequately. It lacks details on error handling or edge cases, but is sufficiently complete for most use cases.

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%, but the description adds value beyond schema by explaining the 'query' alias, recommending a max token limit (~4000), and summarizing prefer options with clear use cases. This raises it above the baseline of 3.

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 'Routes a prompt to the best available x711 LLM', providing a specific verb and resource. It distinguishes itself from sibling tools like x711_data_retrieval or x711_tx_broadcast by focusing solely on LLM prompting.

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 when to use ('when you need external LLM help') and when not to ('Never for things you can answer from context'). Also provides guidance on prefer options with clear use cases for each.

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 details data sources (DeFiLlama + DexScreener), the specific data points returned, and notes the API key requirement. The behavior (fetching and analyzing on-chain data) is clearly described, though it does not explicitly state that it is a read-only operation or discuss potential limitations.

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: two sentences plus a returns list. It front-loads the core purpose and immediately follows with usage guidance. No redundant or unnecessary information is present.

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 there is no output schema, the description explicitly lists the return structure, which is complete for an on-chain insight tool. The single parameter is well-documented in the schema. The tool's purpose, usage, and required setup are fully covered.

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 provides a thorough description of the single parameter 'query', including examples. The tool description does not add additional semantic meaning beyond what the schema offers, so the score remains at baseline 3.

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 as 'Deep blockchain forensics' and specifies concrete data points (DEX pool health, TVL, token price, whale flows). It also positions the tool as a pre-transaction check, distinguishing it from sibling tools like x711_tx_simulate or x711_price_feed.

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 advises 'Use before any DeFi transaction to assess real-time protocol health', providing a clear when-to-use. It also lists expected returns and mentions the API key requirement. However, it does not explicitly state when not to use the tool or mention alternative tools for other contexts.

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, so the description bears full burden. It discloses the return format (JSON with prices, symbols, source, timestamp), supported assets, rate limits, and no API key requirement. It does not mention any destructive actions, which aligns with a read-only feed.

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 tightly written with no redundant sentences. It front-loads the core purpose, gives examples, and concludes with return type and limits. Every sentence contributes essential 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?

Without an output schema, the description fully specifies the return structure and includes all necessary context: supported assets, usage hint, rate limits, and no API key. This is complete for a price feed tool with three simple parameters.

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?

Input schema has 100% parameter description coverage, so baseline is 3. The description adds value by explaining preferred usage ('Prefer query') and case insensitivity, which supplements 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 identifies the tool as a live crypto price feed via CoinGecko, returning USD price and 24h change. It lists specific supported assets and distinguishes from sibling tools (e.g., data retrieval, transactions) by focusing solely on price data.

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 advises using this tool before tx_simulate to get current gas cost in USD, providing a concrete use case. It also notes free tier limits (10 calls/day) but does not include explicit when-not-to-use or alternative tools for price data, though none exist among siblings.

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. Description notes API key requirement but does not disclose rate limits, effect on state (assumed read-only), or other behavioral traits beyond return format. With no annotations, the description carries the full burden but provides only minimal disclosure.

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 return format line. No filler; essential information 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?

Adequate for a single-parameter tool with no output schema, but could elaborate on interpretation of sentiment_score or trending for completeness.

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 examples; the description does not add beyond the schema, so 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?

Description clearly states the purpose: crypto social sentiment analysis via CoinGecko and DexScreener, listing specific return fields like sentiment_score, trending, community_size. It distinguishes from sibling tools like price_feed or onchain_insight by focusing on social data.

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 before trading decisions' and mentions API key requirement. Does not specify when not to use or directly reference alternatives, but the context of sibling tools implies its niche.

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 discloses behaviors: private keys never leave the agent, public RPC used, anonymized pattern written to The Hive, zero extra latency for viral mode. It covers security, network effects, and failure handling ('win or loss'). No contradictions.

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 front-loaded with core purpose and security. It is structured logically: action, security, network, Hive, viral mode, return values. However, it is a bit lengthy with multiple sentences; some repetition of tagline could be trimmed. Still efficient for the complexity.

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 compensates by specifying return fields: success, tx_hash, explorer_url, hive, conquest. It covers demo mode, viral mode, and the Hive integration. It explains the post-broadcast pattern writing and social templates. Comprehensive 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%, so baseline is 3. The description adds marginal value beyond schema: it explains the overall flow but does not significantly enhance parameter understanding. For example, chain and signed_tx details are already clear in schema. The viral_conquest and safe_demo parameters are described similarly in both.

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 action: 'Relay a pre-signed EVM transaction' to five named chains. It distinguishes from sibling tools like x711_tx_simulate by focusing on broadcast. The mention of viral_conquest mode adds specific functionality, further clarifying the purpose.

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 guidance on how to use: sign locally, submit via eth_sendRawTransaction. It explains the safe_demo parameter for testing and the viral_conquest parameter for marketing. However, it does not explicitly contrast with alternatives like x711_tx_simulate, leaving some ambiguity about when to broadcast vs simulate.

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 discloses the tool's behavior: uses public RPC eth_call + eth_estimateGas, no wallet/API key needed, estimates cost in USD, enriches with Hive wisdom, and returns specified fields. No contradictions.

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 informative but slightly verbose; however, every sentence adds value and it is well-structured with front-loaded purpose. Could be more concise but still highly effective.

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 5 parameters and no output schema, the description covers the return structure, integrates with sibling tools, and provides additional context like free tier limits. It is fully sufficient for an AI agent to understand and use the 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 description coverage is 100%, so baseline is 3. The description adds minimal extra parameter detail beyond schema (e.g., default chain is base), but does not significantly enhance parameter understanding.

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 simulates on-chain transactions on multiple chains before broadcasting, and explicitly distinguishes it from the sibling x711_tx_broadcast by instructing to always simulate first.

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 when-to-use context: 'Always simulate before calling x711_tx_broadcast'. Also mentions free tier limit (3 sims/day) which helps manage usage.

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 bears full burden and discloses important behaviors: always returns results, fallback chain, free tier limits (10/day). Could mention rate limits or latency, but current detail is 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?

Front-loaded with key info (multi-source, fallback). Sentences are purposeful, though slightly verbose. Could trim redundancy in examples but overall 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?

Given no output schema, the description thoroughly explains return format, sources, and fallback behavior. Covers edge cases (unavailable sources) and usage limitations. Complete for a search 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 the single 'query' parameter with examples. Description adds no new semantic info beyond schema (same examples). Baseline 3 since schema coverage is 100%.

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 identifies the tool as a multi-source web search with a specific fallback chain (HackerNews → Wikipedia → DuckDuckGo → Hive). It distinguishes itself from sibling tools by focusing on web search and community knowledge, which is unique among the listed x711 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?

Explicitly states best use cases (tech/AI/crypto, current events, documentation discovery) and mentions automatic fallback. Lacks explicit 'when not to use', but the context and sibling tool names imply this is the go-to for general web search.

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