This server provides read-only access to live on-chain data about the $BOBAI token on BNB Chain, enabling AI agents to research, analyze, and interact with the token ecosystem.
Get token fundamentals: Contract address, symbol, decimals, total & circulating supply, and burned amount.
Check live price: Current $BOBAI price in USD and BNB plus market cap, computed on-chain via PancakeSwap V2 reserves × Chainlink BNB/USD feed — no external price API.
Inspect liquidity: Pool reserves, USD liquidity, LP-burned percentage, and price-impact estimates for buy sizes from 0.1–5 BNB.
Track burn activity: Total $BOBAI permanently burned, last burn transaction, and 7/30-day burn stats — all verifiable on BscScan.
Verify bot activity: Confirm the buyback-and-burn flywheel is running, with BscScan links for every entry.
Query wallet balances: BNB and $BOBAI balances for any BSC wallet address.
Get trading parameters: PancakeSwap V2 router/pair details and critical fee-on-transfer settings (3% tax, ≥15% slippage, SupportingFeeOnTransferTokens).
Get ready-to-run buy code: viem code to execute a $BOBAI swap with 0-shot setup, including on-chain quote and correct slippage.
Understand tokenomics: Deflationary tax→buyback→burn mechanics and trust properties (renounced ownership, burned LP, fair launch).
Explore NFT rewards: Live remaining supply per tier for the auto-minted NFT drop (earned on buys ≥ $100) and qualification steps.
Access official links: Website, BscScan, X, Telegram, DexScreener, GeckoTerminal, CoinGecko, GitHub, and more.
Get agent orientation: An interactive guide explaining what to ask and which tool to call for each task.
Provides tools for querying live on-chain data about the $BOBAI token on BNB Chain, including price, supply, liquidity, burns, and trade information.
$BOBAI is a fair-launched memecoin on BNB Chain with a simple thesis: don't ask for trust — make everything verifiable on-chain, then build things people (and AI agents) actually use.
Token: 0x245c386dcfed896f5c346107596141e5edcbffff (BEP-20, verified, ownership renounced)
3% on-chain tax powers a fully autonomous 24/7 buyback-and-burn flywheel — every burn lands in a public audit log with a BscScan tx link
LP tokens burned to 0x…dEaD · fair launch on four.meme · no team allocation
This repo is the public source for all of it — read-only and keyless: no private keys, no API keys, no custody
Price, burns, liquidity, buyback reserve — computed on-chain, every number verifiable | |
🤖 AI-agent rails | Remote MCP server in the official MCP registry (as far as we can tell, the first memecoin there), 14 read-only on-chain tools, plain-REST mirror, ERC-8004 on-chain identity |
🖼️ NFT buy-drop | Buy ≥ $100 of $BOBAI → a collectible NFT auto-mints to your wallet. 1925 supply, tiered rarity, renounced contract |
Live buy/burn alerts, price & security commands, and a whale tracker with 1d/7d/30d holdings trends | |
13 free self-tests (IQ, ADHD screening & more) — runs in your browser, no signup | |
BOBAI arcade game with global highscores | |
Community World Cup 2026 prediction game with $BOBAI prize pools, paid out on-chain | |
The whole design in one document |
Nothing above is a roadmap — it's all live.
Related MCP server: mcp-omnifun
Live remote MCP endpoint (streamable HTTP, JSON-RPC 2.0, protocol 2025-06-18, no auth, CORS open):
POST https://brainonbnb.com/mcpQuick check:
curl -s https://brainonbnb.com/mcp -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Remote (Claude Code, or any client that speaks streamable HTTP):
claude mcp add --transport http bobai https://brainonbnb.com/mcpLocal stdio (Claude Desktop and other stdio-only clients) — mcp/server.mjs is a zero-dependency stdio server (Node ≥ 18, no npm install):
{
"mcpServers": {
"bobai": {
"command": "node",
"args": ["/path/to/bobai-buyburn/mcp/server.mjs"]
}
}
}Or with Docker (uses the Dockerfile in this repo):
docker build -t bobai-mcp . && docker run -i bobai-mcpNo clone at hand? mcp-remote bridges stdio clients to the hosted endpoint: npx -y mcp-remote https://brainonbnb.com/mcp
Tool | What it returns |
| START HERE — what an agent can ask/do and which tool to call |
| Contract, symbol, decimals, total/circulating supply, burned |
| Live price in USD/BNB + market cap, computed fully on-chain (pair reserves × Chainlink BNB/USD) — no off-chain price API to trust |
| Pool reserves, liquidity USD, LP-burned %, price-impact estimates per buy size |
| Total $BOBAI permanently burned by the 24/7 buyback bot |
| Total supply minus burned |
| Proof the flywheel runs: last burn tx, 7/30-day burns, total bot runs — every entry verifiable on BscScan |
| Smart-money signals: tax reserve charging the next buyback, whale flows & holdings trends (1d/7d/30d), immutable ledger of recent $100+ buys, burn momentum |
| PancakeSwap V2 router/pair/paths + the critical fee-on-transfer params (3% tax, ≥15% slippage, |
| Ready-to-run viem code to buy $BOBAI 0-shot |
| Neutral, verifiable value-accrual mechanics (tax → buyback → burn) |
| BNB + $BOBAI balance of any BSC address |
| Earnable NFT buy-drop: live remaining supply per tier + how to earn one |
| Official links (site, BscScan, X, Telegram, DexScreener, …) |
Plus 2 guided prompts and MCP resources (llms.txt, agent card). Every read tool is also mirrored as a plain REST GET endpoint for agents that don't speak MCP — see brainonbnb.com/skill.md.
Path | What it is |
| brainonbnb.com (Cloudflare Pages) incl. the MCP server ( |
| Autonomous BOB buyback-and-burn bot (runs 24/7 via GitHub Actions) |
| Creator-fee buyback bot |
| Manual liquidity add + LP burn to the dead address |
| Cloudflare Workers (Telegram bot, NFT mint/metadata, World Cup game, …) |
| Public audit logs — every burn/buyback verifiable on-chain |
Ownership renounced, LP tokens burned to 0x…dEaD, fair launch on four.meme
Price and liquidity data computed on-chain only (no third-party price API in the money path)
All bot activity lands in public audit logs with BscScan tx links
Nothing here is financial advice — verify everything yourself, that's the point
Proof 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?
No annotations provided, so description carries full burden. It discloses data source (public audit log) and verifiability (on-chain). However, it does not mention whether data is live or cached, or any potential rate limits. 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?
Single sentence packs multiple data points clearly, though somewhat run-on with colons. Could be split into two sentences for readability, but 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 output schema, the description adequately lists all return elements (last burn tx, burns over periods, total bot runs). It is complete for a simple parameterless tool, though format details (e.g., BscScan link) are implied.
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, so schema coverage is trivially 100%. Baseline is 4 for zero parameters. Description adds no parameter info as none exist.
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). It effectively distinguishes from siblings like bobai_burned which likely focuses only on burn events, by aggregating multiple metrics.
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 alternatives. Sibling tools exist for similar purposes (e.g., bobai_burned, bobai_token_info), but the description does not provide selection criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total $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?
No annotations, so description carries full burden. It discloses that the burn is permanent, sent to dead/zero address, and executed by an autonomous bot. This provides behavioral context beyond a simple total.
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 concise sentence with no waste. Front-loads the key information immediately.
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 zero-parameter tool. Describes what is returned and the mechanism. Could specify that the value is a number, but not critical.
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, so baseline is 4. The description adds no parameter info, but none 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 the tool's purpose: returns total $BOBAI permanently burned. It uses specific verb 'burned' and resource '$BOBAI', and distinguishes from siblings focused on other aspects like price, supply, or activity.
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 versus alternatives. Usage is implied by the tool's specific metric, but missing explicit differentiation from sibling tools like 'bobai_tokenomics' or 'bobai_circulating_supply'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current 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?
No annotations provided, so description carries full burden. It honestly states the data source and formula, implying a read-only, non-destructive operation. No hidden behaviors or 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?
Single sentence, front-loaded with key information. Every word serves a purpose. 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?
No output schema, but the return value (circulating supply) is clearly defined. Could be enhanced with format details (e.g., integer, decimal, unit), but sufficient for a simple numeric query.
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 – baseline 4 per guidelines. Schema coverage is 100% (empty schema), so description adds no parameter info because none 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?
Description clearly states it returns the current circulating supply of $BOBAI. Used as 'current...supply' with explicit formula 'total supply minus burned tokens'. Distinguishes from siblings like bobai_burned and 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 when-to-use or alternatives, but zero-parameter simplicity makes usage self-evident. The description implies it is for retrieving the circulating supply, and siblings cover related but distinct metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START 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 provided, so description carries burden. It discloses it's an interactive guide covering orientation topics, but doesn't detail side effects or state changes. Adequate for a read-only guide.
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, front-loaded sentence with no wasted words. 'START HERE' immediately signals 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?
Tool has no parameters and no output schema. Description covers purpose, contents (guide, tool mapping, fee rule), and is sufficient for an agent to know 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?
Input schema has 0 parameters, so schema coverage is 100%. Baseline 4 applies; no additional 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's an interactive guide for a new agent, listing what it covers (askable queries, actions, tool mapping, fee rule). It distinguishes from siblings by being the starting point.
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 says 'START HERE', implying it should be used first. Also mentions 'which tool to call for each', guiding to other tools. Could be more explicit about 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.
Ready-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?
No annotations are provided, so the description bears full responsibility. It discloses the method (viem code, PancakeSwap V2, slippage, fee-on-transfer) but does not mention prerequisites (e.g., needing BNB, wallet setup), execution environment, or return value format.
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 is front-loaded with key information. Every word is informative 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 no parameters and no output schema, the description provides a clear purpose and output (code for swap). It is slightly vague on the exact form of the return (code snippet? instructions?), but overall complete for a no-param 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?
There are no parameters (0 params, 100% schema coverage). The description adds full context about what the tool does without needing parameters, 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 the tool provides 'Ready-to-run viem code to BUY $BOBAI with BNB on PancakeSwap V2', specifying action, asset, pair, platform, and method. It distinguishes from siblings (e.g., bobai_price, bobai_activity) which are informational.
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 says 'so an agent can execute a swap 0-shot', indicating intended use for direct buying. It does not explicitly state when not to use or name alternatives, but the context of sibling tools implies this is the execution tool, while others are for queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official $BOBAI links: website, BscScan contract, X, Telegram, DexScreener, GeckoTerminal, CoinGecko, GitHub source, llms.txt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, static content, no side effects). For a tool with zero annotations, this 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?
One sentence, front-loaded with the subject, no wasted words. Perfectly 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 no parameters, no output schema, and low complexity, the description fully explains what the tool returns: a list of official links.
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, so baseline is 4. The description adds no parameter info (none needed), but 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 states it provides official $BOBAI links, listing specific platforms like website, BscScan, X, etc. This distinguishes it from siblings that cover activity, price, 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?
No explicit when-to-use or alternatives are given, but the purpose is self-evident given the sibling context. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live $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?
With no annotations, the description carries full burden. It mentions 'Live' hinting at real-time data but does not discuss authentication needs, rate limits, or read-only nature. The tool has no parameters, so complexity is low, but behavioral gaps remain.
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, well-structured sentence that front-loads the core purpose and lists specifics without waste. Every part 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?
No output schema exists, so the description compensates by enumerating return fields (pool reserves, liquidity in USD, etc.). It covers the likely needs for liquidity depth info, though could mention additional details like data freshness.
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 (schema coverage 100%). The description adds value by detailing what the tool returns, beyond the empty schema. This exceeds the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Live $BOBAI liquidity depth' and lists specific data points (pool reserves, liquidity in USD, LP-burned percentage, price-impact estimates for common buy sizes). This clearly distinguishes it from siblings like bobai_price and bobai_trade_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 lists what data the tool provides but does not explicitly state when to use it over alternatives. No exclusions or comparisons to sibling tools are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
On-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 must cover behavioral traits. It mentions the reward is auto-minted and requires no claim, but does not explicitly state that this tool is read-only or discuss auth or rate limits. The description mixes the reward process with tool functionality, which may cause minor confusion.
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, concise and front-loaded with key information. It could be slightly more structured, but it efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the essential information: remaining supply, rarity, and steps. It is complete enough for an agent to understand what the tool returns and how it relates to the reward.
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 (0 params, 100% schema coverage), so no parameter documentation is needed. Baseline for 0 params is 4; the description does not need to add anything beyond 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 states the tool provides info on an on-chain reward for $BOBAI purchases, with specific verb 'earn' and resource 'NFT drop'. It distinguishes from sibling tools like bobai_price or bobai_circulating_supply by describing a unique reward mechanism.
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 the tool is used to get live remaining supply per buy-tier, rarity, and steps to earn the NFT. While it doesn't explicitly mention when not to use it or alternatives, the context from sibling names suggests it's the appropriate tool for this specific NFT drop info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live $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?
No annotations provided, so the description carries full burden. It discloses the on-chain computation method and trust model (no off-chain API), but does not mention side effects, authorization needs, or performance characteristics. 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, well-crafted sentence with no wasted words. It efficiently conveys purpose, outputs, and methodology.
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 fully explains what the tool returns (price in USD/BNB, market cap) and how it is computed (on-chain via PancakeSwap and Chainlink). 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?
The tool has zero parameters, and schema description coverage is 100% (trivially). Baseline is 4 as per instructions. The description adds value by explaining the output (price, market cap) and computation method, which is not covered by 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 states the tool provides live $BOBAI price in USD and BNB plus market cap, with a specific verb (Live price) and resource (BOBAI). It distinguishes itself from sibling tools like bobai_activity or bobai_supply by focusing solely on price and market cap.
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 obtaining price and market cap data, but does not explicitly state when to use this tool versus alternatives or provide exclusions. However, given sibling tools cover other metrics, it is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live smart-money signals for $BOBAI: the tax reserve charging the next buyback (wallet + contract queue = pending buy pressure), whale flows (auto-tracked 1%-of-supply wallets: 24h/7d in/outflows, top movers with tx), 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?
No annotations are provided, so the description carries full burden. It discloses that the data is verifiable and requires no API key, but does not discuss rate limits, idempotency, or whether data is cached. For a read-only signal tool, this is adequate 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 long sentence that packs many details. While all content is relevant, the lack of sentence breaks makes it harder to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return values. It covers multiple data categories (tax reserve, whale flows, buys, burn momentum) adequately. However, it does not mention time range flexibility or whether data is live vs. aggregated.
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 (schema coverage 100% via empty schema). Baseline is 4, and the description adds context about the data returned, which is sufficient.
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 specifically states 'Live smart-money signals for $BOBAI' and enumerates distinct data components (tax reserve, whale flows, recent buys ledger, burn momentum), clearly differentiating 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?
No explicit guidance on when to use this tool versus the 13 sibling tools. The description implies it is for 'smart-money' insights, but does not state when to prefer it over alternatives like bobai_activity or bobai_trade_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$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?
No annotations exist, but the description discloses key behavioral traits such as being BEP-20 on BNB Chain, verified, and renounced, adding value beyond the schema.
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 immediately conveys the core functionality without extraneous 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 zero-parameter tool with no output schema, the description fully covers the expected information (contract, name, symbol, decimals, supplies, burned amount) and network context.
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 description naturally cannot add parameter meaning; baseline 4 is appropriate as no compensation 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 on-chain token info including contract, name, symbol, decimals, total & circulating supply, and amount burned, distinguishing it from sibling tools like bobai_price or bobai_circulating_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 does not explicitly state when to use this tool over siblings, but the purpose is self-contained as a general overview, leaving implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Neutral, 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?
No annotations provided, so description must carry full burden. Only notes neutrality and non-promotional nature, but lacks disclosure of behavioral traits such as idempotency, stability, or cost implications.
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 conveys essential purpose and disclaimer, with front-loaded key terms ('Neutral, verifiable value-accrual mechanics'). No unnecessary words, though slightly long.
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 would benefit from indicating whether output is textual or structured. It adequately states what the tool describes but lacks specifics on the format or details of the return.
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 zero parameters, so schema coverage is 100% automatically. The description adds meaning by summarizing the content (value-accrual mechanics), which justifies the baseline of 4 for no-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 provides neutral, verifiable value-accrual mechanics of the token, including deflationary design and trust properties. It distinguishes itself from siblings like price or activity tools, though a specific verb like 'retrieve' is missing.
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 understanding tokenomics, but does not explicitly state when to use this tool versus alternatives like bobai_token_info or bobai_price. The 'NOT a buy recommendation' clarifies non-promotional intent but lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How 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 fully carries the burden and reveals critical behavior: fee-on-transfer, 3% tax, min 15% slippage, and that naive swaps revert. This is comprehensive.
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 well-structured sentences that front-load key information and earn their place 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?
While the description explains the swap process, it does not specify what the tool returns (e.g., swap info, quote). Given no output schema and sibling tools like bobai_how_to_buy, completeness is lacking.
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, so the description does not need to explain them. The baseline for 0 parameters is 4, and the description adds context about the swap process.
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 is about swapping $BOBAI on-chain using PancakeSwap V2, specifying router, pair, swap paths, and fee-on-transfer parameters. It distinguishes from sibling tools by focusing on trade execution.
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 says when to use the tool for swapping and warns against naive swaps, but does not mention when to avoid it or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BNB 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?
No annotations provided, so description carries full burden. It discloses the tool returns balance for BNB and BOBAI, but doesn't mention authorization, rate limits, or other behaviors. Adequate but not comprehensive.
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, concise sentence that front-loads key information with no extraneous 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 low complexity (one parameter, no output schema), the description adequately summarizes the tool's function. Could specify return format (e.g., units), but sufficient for a simple balance check.
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 covers the single parameter 'address' with complete description. The tool description adds no additional meaning beyond what schema provides, meeting the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves BNB and BOBAI balances for any BSC wallet address, distinguishing it from sibling tools like bobai_price and 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 versus alternatives like bobai_price or bobai_token_info. The context of siblings implies it's for wallet-specific balances, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1bobai_smart_moneyv0.1.0bobai_activitybobai_burnedbobai_circulating_supplybobai_guidebobai_how_to_buybobai_linksbobai_liquiditybobai_nft_dropbobai_pricebobai_token_infobobai_tokenomicsbobai_trade_infobobai_wallet_balanceScored across 14 tools
Each tool targets a distinct aspect of the $BOBAI token ecosystem (e.g., price, supply, burns, liquidity, smart-money signals, NFT rewards, buying guide) with no overlap in purpose, allowing an agent to select the correct tool unambiguously.
All tools follow a consistent 'bobai_<descriptive_noun>' pattern in snake_case, making the naming highly predictable and easy to navigate.
With 14 tools, the set is well-scoped for a token-focused server. Each tool adds specific value covering token info, mechanics, acquisition, analytics, and user guidance, without being overly large or sparse.
The tools cover all essential token operations: supply info (circulating, burned), price, liquidity, buy execution (with code and parameters), wallet balance, activity logs, smart-money signals, NFT rewards, and a guide. No obvious gaps for an agent to interact with the token.
BNBOracle - 8 BNB Chain tools: BEP-20, PancakeSwap, validators, gas, txs, holders.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Live data + LLM inference for agents: prices, uptime, x402 audits, conformance doctor. USDC on Base.
AI price forecasts, whale flows, market sentiment and prediction signals. 18 tools free, no account.