Skip to main content
Glama

bobai

by com.brainonbnb
OverviewDiscussionsAdmin

bsc_rug_watch

Idempotent

Rug-pull and honeypot ALARM for a BSC token you hold — webhook only (no Telegram, no browser, no mail). Registers the token and your own https callback; every 15 minutes the token is read again with bsc_token_preflight and compared with the read before, and your callback is POSTed as soon as something dangerous changes: the sell stops going through (honeypot), the liquidity is pulled (pool hard side down 50%; a warning at 25%), LP is withdrawn, the buy or sell tax rises by 2 points or more, the owner changes (renounced to an owner again is the worst case), the proxy is upgraded, the deployer or a top holder starts selling, or the owner can now change the tax — and the way tokens are rugged today, read from the watch's own 24 h history of reads: fake volume (many swaps from a handful of wallets, or an hour's volume far over the pool from few of them — it looks like wash trading, it is not proven), a pump (price up 40% within 6 h) and the dump after it (down 30% from that high), a slow rug (price down 25% over the day with no single big step while sells dominate and insiders sell), liquidity draining slowly, and insider sells adding up. Each alert is signed: x-bobai-signature: sha256=HMAC-SHA256 of the raw body with the secret returned once at registration. One active watch is free per caller; wallets holding 1,000,000 $BOBAI or more get unlimited — 25 active watches per wallet — by adding wallet, issued (ISO time) and an EIP-191 personal_sign signature of "BOBAI rug watch\nwallet: \nissued: " (a signature, no transaction). A watch runs 30 days; register the same token and callback again to renew. Status: GET https://agent.brainonbnb.com/rug-watch/; terms: GET https://agent.brainonbnb.com/rug-watch. Measurement, not advice: an alert says what changed between two reads.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesThe BSC token to watch (0x + 40 hex). It must trade in a pool.
issuedNoOptional, holder tier: the ISO 8601 UTC time in the signed message, within the last 10 minutes
walletNoOptional, holder tier: the wallet holding 1,000,000 $BOBAI or more
callbackYesYour https endpoint; alerts are POSTed there as JSON
signatureNoOptional, holder tier: the personal_sign signature of the message by that wallet

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond annotations: webhook-only delivery, 15-minute re-read cadence, per-alert trigger conditions, HMAC-SHA256 signing with the x-bobai-signature header and registration-time secret, free/paid quota tiers, and the required signature message format. The write-and-open-world nature of the tool is fully disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded correctly, but the description is a dense run-on that crams the entire alert taxonomy into stacked parentheses. Highly useful detail, but the structure makes it hard to scan and the alert-condition list is longer than an agent needs for tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex stateful webhook tool with no output schema, it covers delivery mechanism, signing, lifespan, and where to read status/terms. It stops short of describing the alert JSON payload shape, which an integrating agent would benefit from, leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the schema documents all five fields. The description nonetheless adds real value by giving the exact EIP-191 signing message template ('BOBAI rug watch\nwallet: <lowercase address>\nissued: <issued>') and the holder threshold, which the schema only gestures at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Rug-pull and honeypot ALARM for a BSC token you hold — webhook only'. It names the delivery mechanism, the polling cadence, and distinguishes itself from siblings by noting it internally re-reads with bsc_token_preflight. An agent can tell exactly what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly frames the use case ('a BSC token you hold') and rules out alternatives ('no Telegram, no browser, no mail'), plus states quota tiers, the 30-day lifespan, and how to renew. It stops short of an explicit when-to-choose-this-over-X comparison, but the context is strong enough for correct selection.

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

All bobai toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources