bobai

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

The description explains the data source (public audit log) and verifiability (on-chain), and lists the returned fields. Since no annotations exist, this provides sufficient behavioral clarity for a read-only, non-destructive 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 a single sentence that packs essential information, front-loading the core purpose. It is efficient but slightly dense; could be improved by splitting for readability.

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 zero parameters, no output schema, and multiple siblings, the description adequately explains the tool's output and purpose. It covers the key context for a data-retrieval tool, though it could mention that it is read-only.

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?

There are no parameters, so the baseline is 4. The description does not need to add parameter info, but it compensates by clarifying what the output contains.

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 provides proof of the buyback-and-burn flywheel, listing specific data points (last burn with BscScan tx, burns over 7/30 days, total bot runs). This distinguishes it from siblings like bobai_burned or bobai_token_info, which likely cover different aspects.

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?

Usage is implied through the description, but there is no explicit guidance on when to use this tool versus alternatives like bobai_burned, nor any mention of prerequisites 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?

No annotations are provided, so the description carries the burden. It explains that the burn is performed by an autonomous bot and the amount is permanently burned. However, it does not disclose if any side effects occur (likely none) or any additional behavioral traits like rate limits or data freshness.

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 single sentence that conveys all necessary information. 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 no parameters and no output schema, the description is complete for a simple data-retrieval tool. It clearly states the metric (total burned) and the mechanism (autonomous buyback-and-burn bot). There is no additional complexity that would require more detail.

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 zero parameters, so there is no burden on description for parameters. The description adds value by explaining what the tool returns (total burned). With no params, baseline is 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?

The description clearly states the tool returns the total $BOBAI permanently burned, specifying it is sent to dead/zero address by an autonomous buyback-and-burn bot. This is specific and distinguishes it from other bobai tools that might show activity or supply.

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 when one wants to know the total burned amount, but does not explicitly state when to use this vs alternatives like bobai_activity or bobai_circulating_supply. No exclusions or context 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?

The description defines the result as 'current circulating supply' and explains it as total supply minus burned. This adds clarity beyond the tool name, but it does not disclose behavior such as whether the value is real-time, cached, or requires authentication. With no annotations, this is acceptable but not thorough.

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 conveys the essential information without any wasted words. It is front-loaded with the core purpose.

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 zero parameters, no output schema, and a straightforward purpose, the description provides all necessary context. It defines the metric clearly and is fully 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?

The tool has no parameters, and the description sufficiently explains the single output concept. Baseline for 0 parameters is 4; no additional parameter detail is needed.

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 returns the current circulating supply of $BOBAI, defined as total supply minus burned tokens. This verb+resource combination is specific and distinct from sibling tools like bobai_burned or bobai_total_supply.

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 guidance is provided on when to use this tool versus alternatives like bobai_burned or bobai_token_info. The description lacks explicit context for selection, leaving the agent to infer usage from the name alone.

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 carries full burden. It describes the tool as an interactive guide, implying read-only behavior, but does not explicitly state that it is non-destructive or what the output format (e.g., text) will be.

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, front-loaded sentence with no wasted words. It efficiently communicates purpose and key content.

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 and no parameters, the description is fairly complete, explaining the guide's content. It could specify output format, but it is adequate for a simple informational 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?

The input schema has no parameters, so description adds value by detailing what the guide covers (questions, actions, tool selection, fee rule). Baseline 4 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 an interactive guide for the agent, covering what it can ask, do, and which tool to call for each task. This distinguishes it from sibling tools like bobai_price or bobai_token_info.

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 begins with 'START HERE,' implying it should be used first for orientation. It explains that it guides tool selection, but does not explicitly state when not to use it or list alternatives beyond the context.

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 disclose behavior. It states that the tool returns 'ready-to-run viem code' and specifies method details. However, it does not explicitly clarify that the tool does not execute the swap itself, only provides code. It also omits any prerequisites (e.g., wallet, BNB balance) or side effects. The description is adequate but could be more transparent.

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, front-loaded sentence with all key information: what the tool does, the assets involved, the DEX, and the swap method. No unnecessary words—every word adds value.

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 no parameters or output schema, the description explains the return value (code) and the swap details. It is fairly complete for a simple code-providing tool, though it could mention that the code is meant to be executed separately and does not run automatically.

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 tool has zero parameters, so the baseline is 4 as per guidelines. The description adds context about the code output but does not parameterize anything. Since there are no parameters, the description effectively serves its purpose.

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 that the tool provides ready-to-run viem code to buy $BOBAI with BNB on PancakeSwap V2, specifying the method (on-chain quote, 15% slippage, fee-on-transfer). It distinguishes itself from sibling tools which are informational (e.g., bobai_price, bobai_token_info) by offering actionable swap code.

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 executing a swap, but does not explicitly state when to use this vs alternatives. However, given that all sibling tools are informational (e.g., bobai_activity, bobai_liquidity), it's clear that this tool is the only one for buying. No exclusions or prerequisites are mentioned, but the context makes usage clear enough.

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. The description states it provides links but doesn't disclose return format (e.g., plain text, markdown) or any side effects. No hidden behaviors, but lacks detail.

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?

One sentence, very concise, front-loaded with 'Official $BOBAI links'. Every word serves a purpose.

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 zero parameters and no output schema, the description should clarify the return format. It lists links but not how they are presented. Adequate but not complete for an agent.

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?

No parameters are present. The description adds no extra meaning beyond the schema, but baseline 4 is appropriate for zero 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?

The description clearly states the tool provides official $BOBAI links, listing specific platforms. It's distinct from sibling tools like bobai_token_info.

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 tool vs. siblings. Usage is implied for getting official links, but no exclusion or alternatives 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?

No annotations provided, so the description carries full burden. It discloses behavioral traits: live data, specific metrics included, and price-impact for buy sizes. This adds meaningful context beyond a basic name. 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?

A single sentence that efficiently packs all key points: live depth, reserves, USD liquidity, burned percentage, and price-impact estimates. No unnecessary words, front-loaded with the main topic.

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 and no annotations, the description adequately covers what the tool returns (reserves, liquidity, burned %, price-impact for 0.1-5 BNB). It could mention data freshness or limitations, but it's sufficiently complete for a simple query 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?

No parameters (0), so baseline is 4 per guidelines. The description adds meaning by explaining what the tool returns without needing parameters. Schema coverage is trivially 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 states the tool provides live $BOBAI liquidity depth, pool reserves, liquidity in USD, LP-burned percentage, and price-impact estimates for common buy sizes (0.1–5 BNB). This specific verb+resource scope distinguishes it from sibling tools like bobai_price or bobai_token_info.

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 when needing liquidity depth or price impact for specific buy sizes. While it doesn't explicitly state when not to use or list alternatives, the sibling tool names provide context for differentiation. Clear context but lacks exclusions.

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 carries full burden. It explains the computation method (PancakeSwap V2 reserves × Chainlink feed) and assures no off-chain API trust. However, it omits potential latency, gas costs, or failure modes.

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?

Single sentence, front-loaded with key info, zero waste. Highly concise and 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 could clarify return format (e.g., object with fields). However, for a simple price tool, it is largely complete and actionable.

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?

No parameters exist; schema coverage is 100%. The description adds no parameter info but none is needed, earning a baseline of 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?

The description clearly states it provides live price in USD and BNB plus market cap, computed on-chain. It distinguishes from siblings by emphasizing the on-chain computation and lack of trust in off-chain APIs.

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 implicitly guides usage for trustless on-chain price lookup. However, it does not explicitly state when to use this vs alternatives like bobai_trade_info.

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 the full burden. It discloses the returned information and adds context (BEP-20 on BNB Chain, verified, renounced) beyond the tool name. However, it does not explicitly state that the tool is read-only or non-destructive, though that is implied. Score 3 is appropriate given the lack of annotation contradiction and adequate but not exhaustive behavioral 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?

The description is a single sentence, efficiently conveying the purpose and key outputs. It is front-loaded with the token symbol and name. Could be slightly improved with clearer separation of fields, but overall concise and 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?

The description lists all expected output fields (contract, name, symbol, decimals, total & circulating supply, amount burned) and adds chain/verification context. No output schema exists, so the description fully covers the return information. Any additional details like data source or latency are non-critical for this simple 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?

The tool has no parameters (schema coverage 100% vacuously), so no parameter documentation is needed. The description does not need to add parameter meaning. Baseline 4 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?

The description clearly states the purpose: retrieving on-chain token info for $BOBAI, listing specific fields (contract, name, symbol, decimals, supply, burned). It distinguishes from siblings like bobai_price and bobai_burned, which are more granular, making this the summary tool.

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 guidance on when to use this tool versus siblings. While the scope is implicitly broader, the description does not explicitly state that it serves as a general overview or when a user should prefer specific tools for detailed data.

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 should disclose behavioral traits. It only says 'describes', which is vague; it does not mention whether it is read-only, requires authentication, or the nature of the output (e.g., static text).

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 efficiently conveys the core purpose without extraneous text. It is concise and front-loaded, but could benefit from clearer structure (e.g., labeling sections).

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 parameters, no output schema, and a simple 'reader' function, the description adequately explains the tool's role. However, it could explicitly state that the tool returns a text description of tokenomics.

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 tool has no parameters and schema description coverage is 100%, so no additional parameter information is needed. The description appropriately focuses on the tool's purpose.

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 describes the neutral, verifiable value-accrual mechanics of $BOBAI, specifically the deflationary tax->buyback->burn design and trust properties. It is distinct from sibling tools like bobai_price or bobai_burned.

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 indicates it is for understanding how the token works and explicitly says it is NOT a buy recommendation. However, it does not clarify when to use this tool over siblings like bobai_token_info or bobai_guide, nor does it state prerequisites or exclusions.

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 carries full burden. It discloses the token's fee-on-transfer, required slippage, and necessary methods, and warns about reverts. Good transparency for an informational 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 sentences, no waste. First sentence gives core info, second adds critical warning. Efficient and 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 an informational tool with no parameters or output schema, the description covers necessary context: what it teaches and why it's needed. Could mention output format but not essential.

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 parameters, schema coverage is 100% trivially. Baseline 4 per rules; no parameter info needed.

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 instructions for swapping $BOBAI, distinguishing it from sibling tools like bobai_how_to_buy. However, it is not a verb+resource action but a guide.

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 context (when you need to swap correctly) but does not explicitly state when to use or alternatives. It warns against naive swaps, providing some 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?

No annotations are provided, so the description carries full burden. It mentions what the tool does but does not disclose any behavioral traits such as read-only nature, rate limits, error handling, or what happens with invalid addresses. Minimal 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 a single sentence that effectively communicates the tool's purpose with no unnecessary words. It is front-loaded and concise.

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 simplicity of the tool (one parameter, no output schema), the description is adequate but incomplete. It does not specify the return format (e.g., units, precision) or handle edge cases, which could be beneficial for an agent.

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% (the only parameter 'address' is described as 'BSC wallet address (0x + 40 hex chars)'). The description adds no additional meaning beyond the schema, so baseline of 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?

The description clearly states that the tool returns BNB and $BOBAI balances for any BSC wallet address. It uses a specific verb (balance) and resource (wallet address), and is distinct from sibling tools like bobai_price or bobai_token_info.

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 does not explicitly state when to use this tool versus alternatives. However, the sibling tool names provide context, implying this is for wallet balance queries. No explicit when-not-to-use or alternative recommendations are given.

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