Skip to main content
Glama
Sign In

bobai

by com.brainonbnb
OverviewDiscussionsAdmin

bsc_rug_watch

Idempotent

Rug-pull and honeypot ALARM for a BSC token you hold. Give just the token: every 15 minutes the token is read again with bsc_token_preflight and compared with the read before, and an alert is raised 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. HOW YOU GET THE ALERTS: with a callback (your public https URL) each alert is POSTed there; without one, call this tool again with {"watch":"","since":""} and new_events lists what fired since. A POSTed 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bsc_rug_watch"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceNoWith watch: an ISO 8601 time; new_events lists only the alerts after it
tokenNoThe BSC token to watch (0x + 40 hex). It must trade in a pool. Leave out when reading a watch with "watch".
watchNoRead a watch instead of registering one: the id you got at registration
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
callbackNoOptional: your public https endpoint; alerts are POSTed there as JSON. Without it, read them with "watch".
signatureNoOptional, holder tier: the personal_sign signature of the message by that wallet

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / callback / description
      Previous value: -"Your https endpoint; alerts are POSTed there as JSON"New value: +"Optional: your public https endpoint; alerts are POSTed there as JSON. Without it, read them with \"watch\"."
    • addedInput schema / properties / since
      Added value: +{
+  "description": "With watch: an ISO 8601 time; new_events lists only the alerts after it",
+  "type": "string"
+}
    • changedInput schema / properties / token / description
      Previous value: -"The BSC token to watch (0x + 40 hex). It must trade in a pool."New value: +"The BSC token to watch (0x + 40 hex). It must trade in a pool. Leave out when reading a watch with \"watch\"."
    • addedInput schema / properties / watch
      Added value: +{
+  "description": "Read a watch instead of registering one: the id you got at registration",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "token",
-  "callback"
-]New value: +[]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations it discloses the polling cadence (15 minutes), the concrete alert thresholds (50% liquidity drop, 25% warning, 2-point tax rise, 40% pump / 30% dump), the delivery mechanism with HMAC-SHA256 signature header, the free/paid watch limits, the 30-day lifetime and the renewal rule. These are exactly the operational facts the annotations (readOnlyHint=false, idempotentHint=true) cannot convey, and they are consistent with them.

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?

The purpose is front-loaded and the 'HOW YOU GET THE ALERTS' label helps orientation, but the middle is a long run-on enumeration of detection heuristics that an agent does not strictly need in order to invoke the tool. The factual content is useful, yet the density makes it harder to scan than it should be.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so: it explains that `new_events` lists what fired since the given time, that POSTed alerts are signed JSON bodies, and it points to status and terms URLs. Everything needed to register, poll, and verify alerts is present.

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 100%, so the baseline is 3, but the description adds real meaning: `token` must trade in a pool, `watch`/`since` form a read cursor, and `wallet`/`issued`/`signature` are a holder tier requiring a specific EIP-191 personal_sign message ('BOBAI rug watch\nwallet: <lowercase address>\nissued: <issued>') that no schema text supplies.

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?

The opening sentence names a specific verb and resource — a rug-pull/honeypot alarm registered against a BSC token — and the body clarifies the two modes (register with `token`, read with `watch` + `since`). It also positions itself relative to the sibling it depends on, `bsc_token_preflight`, so an agent can tell this apart from a one-off preflight check.

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?

The description is explicit about the two calling patterns: 'Give just the token' to register, or call again with watch/since to fetch new events, plus the callback-vs-polling decision and the holder-tier requirements. It never explicitly says when NOT to use it (e.g., a single one-off safety check belongs in bsc_token_preflight), which keeps it out of 5 territory.

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