Smart money & whale flows, price, liquidity, burn proofs for $BOBAI on BNB Chain (BSC). No key
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.5/5.
Most tools have clearly distinct purposes, but a few overlap in data (e.g., bobai_burned, bobai_activity, and bobai_token_info all report burn amounts; bobai_circulating_supply overlaps with bobai_token_info). The detailed descriptions prevent confusion, but some redundancy remains.
All tools follow a consistent pattern with the 'bobai_' prefix and snake_case, making it easy to predict tool names for a given topic.
14 tools is within the ideal range for a token information server, covering price, liquidity, supply, trading, wallet, and NFT features without becoming unwieldy.
The server covers the full informational surface for the token: price, supply, burns, liquidity, trading parameters, wallet balances, tokenomics, and even a guide and links. No obvious missing operations.
bobai_activityAInspectProof the buyback-and-burn flywheel is actually running: last burn (with BscScan tx), burns over the last 7/30 days, total bot runs — from the public audit log, every entry verifiable on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('public audit log') and that entries are on-chain verifiable, which gives useful provenance context. However, it does not explicitly state that the tool is read-only or has no side effects, though zero parameters and the audit-log framing imply 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 a single, tightly packed sentence that conveys purpose and key output details without filler. It is front-loaded with the core value proposition and every clause adds 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?
Given zero parameters and no output schema, the description does a good job of explaining what the tool returns: last burn with tx, burns over 7/30 days, and total bot runs. It could be more explicit about return format, but it is complete enough for a simple status/report 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 zero parameters, so there is no parameter detail needed. The description adds meaningful context about what the output covers, which is the only relevant semantic information here.
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's purpose: it proves the buyback-and-burn flywheel is running by showing last burn with BscScan tx, 7/30-day burn counts, and total bot runs. It is specific about the resource and output, though it uses 'Proof' rather than a conventional action verb like 'show' or 'return'.
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 implied usage is to verify buyback-and-burn activity, but there is no explicit when-to-use guidance or mention of alternatives. It does not tell the agent when to choose this over sibling tools like bobai_burned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_burnedAInspectTotal $BOBAI permanently burned (sent to the dead/zero address by the autonomous 24/7 buyback-and-burn bot).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility for behavioral disclosure. It provides useful context—burned tokens sent to the dead address by an autonomous bot—but does not explicitly state that this is a read-only query, how often it updates, or what the return format is. It is 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?
The description is a single sentence that front-loads the core metric ('Total $BOBAI permanently burned') and then adds relevant detail about the burn mechanism. It is 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?
For a simple, zero-parameter, no-output-schema tool, the description is fairly complete. It defines the value clearly and explains the burn source. However, it does not specify whether the value is current or historical, nor what type of data is returned (e.g., integer, string), leaving minor ambiguity.
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 zero parameters, so the schema is fully covered by default. The description adds meaning about the output (the burned total) but does not need to explain parameters. The baseline of 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 metric: total $BOBAI burned. It uses a specific resource ($BOBAI) and a distinct concept (permanently burned) that differentiates it from sibling tools like bobai_circulating_supply or bobai_liquidity. However, it lacks an explicit verb like 'returns' or 'shows', slightly reducing 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?
No usage guidance is provided. The description does not indicate when to use this tool versus the many sibling tools, nor does it mention any exclusions or alternatives. Users are left to infer the context from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_circulating_supplyAInspectCurrent circulating $BOBAI supply (total supply minus burned tokens).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the calculation logic (total supply minus burned tokens), which adds some transparency. However, it omits potential caveats like data freshness, side effects, or whether the result is a live query vs cached, leaving gaps.
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, concise sentence that directly states the tool's purpose. Every word carries meaning, with no filler, redundant phrasing, or structural clutter.
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 zero-parameter, read-only tool with no output schema, the description is largely sufficient. It defines the return value (circulating supply) and its calculation, which an agent can use. It could be slightly more explicit about the return format (number, string) but is otherwise complete for this simplicity level.
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 is empty (no parameters), and schema coverage is 100%. The description doesn't need to explain parameters since none exist. It effectively provides the only semantic meaning, which aligns with the baseline of 4 for zero-parameter tools.
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 current circulating supply of $BOBAI, specifying 'total supply minus burned tokens.' This is a specific verb-resource combination that distinguishes it from sibling tools like bobai_burned (which likely returns just the burned amount) and bobai_token_info (broader 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 provides no guidance on when to use this tool versus alternatives like bobai_tokenomics or bobai_burned. It simply defines the tool's purpose without any context or exclusions, leaving the agent to infer usage from the name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_guideAInspectSTART HERE. Interactive guide for an agent that just discovered $BOBAI: what you can ask, what you can do, and which tool to call for each — plus the must-know fee-on-transfer rule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool is interactive, guiding the agent through what to ask and which tool to call, and includes the critical fee-on-transfer rule. This gives a good sense of the behavior, though it doesn't detail the response format or whether it returns a menu or 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, well-structured sentence that front-loads 'START HERE' and packs high-value information: target audience, scope, and a key rule. Every phrase earns its place, with no redundancy or filler.
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 and no output schema, the description fully serves its purpose as an entry-point guide. It tells the agent what the guide covers, mentions the critical fee-on-transfer rule, and orients the agent to sibling tools via 'which tool to call for each.' This is complete for its role.
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 score is 4 per the rubric. The description appropriately adds no parameter detail since there are none. Schema coverage is 100% with an empty schema, so no information is missing.
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 begins with 'START HERE' and clearly states it is an 'Interactive guide for an agent that just discovered $BOBAI.' It explicitly enumerates what the tool covers: 'what you can ask, what you can do, and which tool to call for each' plus the fee-on-transfer rule. This distinguishes it from sibling tools that are specific info lookups.
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 phrase 'START HERE' and 'for an agent that just discovered $BOBAI' provides explicit guidance on when to use it. It also tells the agent that the guide will indicate 'which tool to call for each' action, directing to specific sibling tools. This is explicit usage guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_how_to_buyAInspectReady-to-run viem code to BUY $BOBAI with BNB on PancakeSwap V2 (on-chain quote + 15% slippage + fee-on-transfer method), so an agent can execute a swap 0-shot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behavioral aspects: on-chain quote, 15% slippage, fee-on-transfer method, and 0-shot execution. It does not mention return formats, error cases, or wallet prerequisites, but the core behavior is well communicated.
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 dense sentence that is front-loaded with the essential action and contains no filler. Every element (asset, chain, DEX, slippage, method, 0-shot) earns its place.
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 absence of an output schema and annotations, the description adequately conveys that the tool returns runnable viem code and summarizes its key execution details. It could mention prerequisites like needing a wallet or BNB balance, but overall it is sufficiently complete for the agent to understand the tool's purpose and output.
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 zero parameters, so the baseline is 4. The description adds meaning by explaining what the code accomplishes (buy with BNB, slippage, method), even though no parameter-specific details are 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 the tool provides ready-to-run viem code for buying $BOBAI with BNB on PancakeSwap V2. This specific verb+resource+platform distinguishes it from sibling tools that cover activity, pricing, supply, and other informational 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?
It explicitly states the purpose is to enable an agent to execute a swap 0-shot, implying use when an actual buy needs to be performed. It does not list alternatives or exclusions, but the context is clear enough for an agent to identify when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_linksAInspectOfficial $BOBAI links: website, BscScan contract + verified source, X, Telegram, DexScreener, GeckoTerminal, CoinGecko, live burn audit log, llms.txt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It lists the types of links included but does not disclose the return format (e.g., whether it returns a list of URLs, an object, or markdown) or that the tool is read-only. It provides some context (live burn audit log) but is minimal, earning a mid-range score.
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, well-structured sentence that front-loads the key purpose ('Official $BOBAI links') and then lists the content. Every word adds value, with no repetition or filler.
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 (no parameters, no output schema), the description is nearly complete. It lists all major categories of links. However, it could be improved by explicitly stating what the tool returns (e.g., an array of URLs) or that it is a static resource. Overall, it is sufficient for a minimal 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 zero parameters, so the baseline is 4. The description does not need to explain parameters. It adds no parameter-specific information, but that is unnecessary here.
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' and then enumerates the specific resources (website, BscScan, X, Telegram, etc.), making its purpose unambiguous. This distinguishes it from sibling tools like bobai_price or bobai_token_info, which serve different functions.
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 context is clear: this tool is for accessing official links. However, it does not explicitly state when to use this over alternatives, such as bobai_price for price or bobai_token_info for token details. The name and description suffice for basic guidance, but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_liquidityAInspectLive $BOBAI liquidity depth: pool reserves, liquidity in USD, LP-burned percentage (perma-locked), and price-impact estimates for common buy sizes (0.1–5 BNB).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the data scope (live, reserves, USD, perma-lock, price impact), which is behavioral context beyond typical param info. It does not explicitly state 'read-only' but 'live liquidity depth' implies a non-mutating query.
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, front-loaded sentence that packs all key information without waste. It lists the exact data points and the buy-size range (0.1–5 BNB), making it highly 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 no parameters and no output schema, this description is complete enough for an agent to know exactly what the tool returns and when to use it. It covers the main aspects of liquidity depth, including perma-lock and price impact.
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 zero parameters, so the schema already covers 100% of the parameter surface. The description adds no param meaning but enriches the output expectations, which is sufficient for a parameterless tool.
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 $BOBAI liquidity depth with specific data points (pool reserves, liquidity USD, LP-burned %, price impact). The verb is implied by 'provides' and it fully distinguishes from siblings like price or 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 clearly implies when to use this tool: when liquidity or price-impact details are needed. It does not explicitly mention alternatives, but the context is unambiguous given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_nft_dropAInspectOn-chain reward an agent can EARN: every $BOBAI buy >= $100 (single swap) auto-mints a capped-supply collectible NFT to the buyer wallet — no claim, no signup. Live remaining supply per buy-tier and rarity, plus the exact steps to earn one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 describes the reward program's behavior (auto-mint, no claim) but does not explicitly state that calling this tool is a read-only data retrieval with no side effects. There is no contradiction, but the lack of explicit side-effect disclosure is a gap.
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, front-loaded with purpose, no filler. Efficiently conveys the tool's value and data 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?
For a zero-parameter informational tool, the description covers what the tool does, what data it returns, and the program's key mechanics. It is sufficiently complete for an agent to decide when to call it.
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?
Tool has zero parameters and schema coverage is 100%, so no parameter explanations are needed. The description adds context about the data returned (supply, rarity, steps) beyond the empty 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 explains this tool provides live NFT drop supply and rarity data, plus earning instructions. It distinguishes from sibling tools (price, supply, etc.) by focusing exclusively on the NFT drop reward program.
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 an agent needs NFT drop details (supply, rarity, steps). It doesn't explicitly name alternatives or exclusions, but the specific topic and steps make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_priceAInspectLive $BOBAI price in USD and BNB + market cap, computed fully on-chain (PancakeSwap V2 pair reserves × Chainlink BNB/USD feed) — no off-chain price API to trust.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses the exact data sources (PancakeSwap V2 pair reserves and Chainlink BNB/USD feed) and asserts no off-chain API dependency, which is valuable behavioral context. It does not disclose potential latency or edge cases, but for a read-only price tool this is above average.
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, dense sentence that leads with the core output ('Live $BOBAI price') and then provides the computation rationale. Every word earns its place, with no repetition or filler.
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 no parameters and no output schema, the description sufficiently explains what it returns (price in USD and BNB, market cap), how it is computed (on-chain reserves and Chainlink feed), and why it is trustworthy (no off-chain API). It is complete for the tool's simple scope.
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 zero parameters and schema description coverage is 100%. Per the rubric, 0 params corresponds to a baseline of 4. The description adds no parameter details because there are none, which 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 uses a specific resource ('Live $BOBAI price') and clearly defines the scope: 'USD and BNB + market cap'. It distinguishes itself from sibling tools by explicitly stating the on-chain computation method, making the tool's function unambiguous.
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 clear context for when to use the tool: when a trusted, on-chain price is needed. It implies a preference over off-chain APIs ('no off-chain price API to trust') but does not explicitly name alternative tools or state when not to use it, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_smart_moneyAInspectLive smart-money signals for $BOBAI: the tax reserve charging the next buyback (wallet + contract queue = pending buy pressure), whale flows & holdings (auto-tracked 1%-of-supply wallets: 24h/7d in/outflows, top movers with tx, daily balance snapshots with 1d/7d/30d holdings trends), an immutable on-chain ledger of recent $100+ buys (size, buyer wallet, tx), and burn momentum. All verifiable, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds context such as 'All verifiable, no API key' and describes auto-tracking and immutable ledger, which are useful behavioral traits. However, it does not explicitly state that this is a read-only operation or disclose any limitations, which is a gap given no annotation support.
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 long run-on sentence with multiple clauses, making it dense and harder to parse. It is front-loaded with 'Live smart-money signals' but would benefit from being split into clearer sentences. Every element contributes value, but the structure is suboptimal.
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 thoroughly enumerates the return contents: tax reserve details, whale flows with 24h/7d in/outflows, top movers with transactions, balance snapshots with 1d/7d/30d trends, buy ledger fields, and burn momentum. This gives an agent a complete picture of what the tool provides.
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 0 parameters and an empty schema, so the baseline is 4. The description adds no parameter-specific semantics, but there is nothing to explain. The schema already fully covers the parameter space, so a score of 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 specifies that the tool provides live smart-money signals for $BOBAI, and enumerates distinct data components (tax reserve, whale flows, holdings, buy ledger, burn momentum). This distinguishes it from sibling tools like bobai_price or bobai_liquidity, making the purpose unambiguous.
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 smart-money-related queries by detailing what data is included, but it does not explicitly state when to use this tool versus alternatives like bobai_price or bobai_wallet_balance. There is no mention of exclusions or comparison to siblings, so guidance is implied but not direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_token_infoAInspect$BOBAI (Brain On BNB AI) on-chain token info: contract, name, symbol, decimals, total & circulating supply, amount burned. BEP-20 on BNB Chain, verified & renounced.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It specifies that the tool returns on-chain information (implying a read operation) and describes the token's attributes. However, it does not explicitly state that it is read-only, nor does it mention potential caveats like data latency or verification status beyond 'verified & renounced'.
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, information-dense sentence that front-loads the token name and purpose. It includes all relevant details without unnecessary words, making it 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 the tool's simplicity (0 parameters, no output schema), the description covers the expected fields adequately. However, it could be slightly more complete by noting that more specific tools exist (e.g., bobai_burned for burn amounts), but this is not essential for a basic info 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 zero parameters and an empty input schema, so the baseline score is 4. The description adds no parameter-specific semantics because there are none to explain, which 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 tool's purpose: providing on-chain token info for $BOBAI. It lists specific fields (contract, name, symbol, decimals, supplies, amount burned) and characterizes the token (BEP-20, verified, renounced), distinguishing it from sibling tools that focus on price, liquidity, or other specific 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?
The description implies usage as a general token info tool but does not explicitly state when to use it versus the many sibling tools (e.g., bobai_price, bobai_liquidity). It offers no exclusions or alternatives, relying on the context that this is the comprehensive metadata source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_tokenomicsAInspectNeutral, verifiable value-accrual mechanics of $BOBAI: the deflationary tax->buyback->burn design + trust properties (renounced, LP burned, fair launch). Describes how the token works, NOT a buy recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's nature as 'Neutral, verifiable' and includes a disclaimer that it is not investment advice. For a read-only informational tool, this is adequate behavioral transparency, though it doesn't describe the exact output format or result style.
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, well-structured sentence that front-loads the core purpose ('Neutral, verifiable value-accrual mechanics') and then lists key aspects. Every clause adds value: the tax-buyback-burn design, trust properties, and the important 'not a buy recommendation' caveat. No waste.
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 empty schema and no output schema, the description effectively conveys the tool's scope: tokenomics mechanics and trust properties. It includes enough specifics (deflationary tax, buyback, burn, renounced, LP burned, fair launch) to set expectations. It could mention what kind of response the user gets, but for a descriptive informational tool, this is sufficiently complete.
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. The description adds meaning by framing the content (mechanics, trust properties) but no parameter details are needed. Schema coverage is trivially 100% with no properties, so there is no gap for the description to fill.
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 what the tool provides: 'Neutral, verifiable value-accrual mechanics of $BOBAI' with specific components like 'deflationary tax->buyback->burn design' and 'trust properties'. It explicitly distinguishes itself from siblings by noting it 'Describes how the token works, NOT a buy recommendation', which separates it from price or purchase guidance 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?
The description gives clear context for when to use this tool—when seeking factual tokenomics and trust properties—and explicitly excludes a use case ('NOT a buy recommendation'). It does not name alternative tools, but the 'not a buy recommendation' disclaimer implies differentiation from purchasing-related tools like bobai_how_to_buy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_trade_infoAInspectHow to swap $BOBAI on-chain: PancakeSwap V2 router, pair, swap paths, and the critical fee-on-transfer parameters (3% tax, min 15% slippage, SupportingFeeOnTransferTokens methods). $BOBAI reverts on a naive swap — use these.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses critical behavioral facts: the 3% tax, minimum 15% slippage, need for SupportingFeeOnTransferTokens methods, and the revert risk on a naive swap. This is exactly the kind of context an agent needs before invoking the 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 two sentences with no filler. Every phrase earns its place: protocol, router, pair, swap paths, tax, slippage, methods, and the revert warning. It is dense but well-structured and 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?
For a zero-parameter tool with no output schema and no annotations, the description is exceptionally complete. It covers the full operational picture needed to execute a safe swap, including the critical caveat about naive swaps reverting.
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. The description adds semantic value by explaining the swap parameters that matter (slippage, fee-on-transfer methods), even though these are not input schema fields.
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 its purpose: 'How to swap $BOBAI on-chain' with specific technical details (PancakeSwap V2 router, pair, swap paths, fee-on-transfer parameters). It distinguishes itself from sibling info tools by focusing on the actionable swap mechanics rather than general activity, price, or tokenomics 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 phrase 'How to swap' gives clear context for when the tool should be used. It does not explicitly mention when not to use it or name alternative sibling tools like bobai_how_to_buy, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bobai_wallet_balanceAInspectBNB and $BOBAI balance of any BSC wallet address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | BSC wallet address (0x + 40 hex chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation and that there are no address restrictions ('any'), but does not detail potential error cases, rate limits, or return format. This is acceptable for a simple balance query but lacks depth.
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, clear sentence that immediately communicates the core function. Every word is informative, 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?
For a simple one-parameter read tool, the description sufficiently conveys what is returned (BNB and $BOBAI balances). There is no output schema, but the description names the expected return values, which is 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?
The input schema already describes the address parameter with format details (0x + 40 hex chars), and the description adds minimal extra meaning ('any'). Since schema coverage is 100%, this is an adequate baseline.
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 resource (BNB and $BOBAI balance) and the scope (any BSC wallet address), but lacks an explicit verb like 'get' or 'fetch'. This makes it distinct from sibling tools that cover activity, supply, prices, 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?
The phrase 'any BSC wallet address' provides clear context for when the tool is applicable, and the sibling tool names indicate that this is the go-to for wallet balances. However, it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
