GuardBot
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GUARDBOT_HOST | No | Expose on your LAN; default loopback | |
| GUARDBOT_PORT | No | Port (default 8403) | |
| GUARDBOT_PAY_TO | No | Address to receive payments | |
| GUARDBOT_NETWORK | No | Network for x402 payments (e.g., base-sepolia) | |
| GUARDBOT_DEV_SEED | No | Serves /dev/seed, a testnet-only page to create test grants | |
| GUARDBOT_NO_CACHE | No | Disable the local index | |
| GUARDBOT_PRICE_USDC | No | Price in USDC for paid calls via x402 | |
| GUARDBOT_SOLANA_RPC | No | Point at testnets (devnet / nile) | |
| GUARDBOT_FACILITATOR | No | Facilitator URL for x402 payments | |
| GUARDBOT_TRON_NETWORK | No | Point at testnets (devnet / nile) | |
| GUARDBOT_ETHERSCAN_KEY | No | Free; speeds up log history on eth/arbitrum/polygon | |
| GUARDBOT_WC_PROJECT_ID | No | Enables WalletConnect (free id from cloud.reown.com) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_tokenA | Pre-trade safety check. Simulates actually BUYING the token and SELLING it back against live liquidity, so a honeypot, a punitive tax or an empty pool is demonstrated rather than guessed. Also checks whether the contract is impersonating a bigger token's ticker. Returns safe/warn/block with the evidence. Call BEFORE buying. |
| check_approvalsA | What has this wallet already handed out? Lists standing approvals across EVM chains, TRON and Solana — ERC-20 allowances, NFT operator approvals (ApprovalForAll) and grants held inside Permit2 — each with a graded risk level. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
check_token evaluates a token's tradability and impersonation risk, while check_approvals audits a wallet's existing allowances across chains. They target different objects and perform different kinds of safety analysis, so an agent cannot confuse them.
Both tools follow the same verb_noun pattern: check_token and check_approvals. This is a clear, consistent convention with no mixed naming styles or vague verbs.
Only two tools feels thin for a general-purpose security bot, but the tools are tightly scoped to token safety and wallet approval checks. The count is defensible but still sits on the borderline where a small set may feel sparse.
The core domain is covered well: token buy/sell simulation, honeypot and tax detection, ticker impersonation, and multi-chain approval discovery are all present. Missing features like revocation or deeper transaction simulation are not clearly promised, so the gap is minor rather than severe.