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. |
| simulate_revokeA | Prove a revoke BEFORE it is signed. Builds the one transaction that removes a single approval — ERC-20 approve(spender, 0), NFT setApprovalForAll(operator, false), or a grant held inside Permit2 — then runs it against live state on the node and re-reads the grant in the same simulated block, so 'works' is measured, not assumed. Nothing is signed, sent or broadcast: the calldata comes back for a wallet or an offline signer, and the amount is hard-coded to zero. Read-only. Use check_approvals first to find which grant to remove; use this to prove that removing it will actually work. |
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 3 tools
Each tool has a distinct responsibility: check_approvals lists existing approvals, simulate_revoke tests a specific revocation, and check_token evaluates a token's safety. The workflow relationship between check_approvals and simulate_revoke is clearly separated by read vs. simulate.
Names follow a clean verb_noun pattern, with check_approvals and check_token sharing the 'check' prefix. simulate_revoke is the only deviation, but the verb accurately reflects its action and is still in the same structural style.
Three tools is well-scoped for a guard-focused server: inspect approvals, simulate a revoke, and vet a token before trading. Each tool covers a distinct user need with no redundancy or bloat.
The tool surface covers the core workflows: discovering risky approvals, proving a revoke works before signing, and detecting malicious tokens. A minor gap is the lack of any execution/broadcast capability, but the tools intentionally stop at simulation and calldata generation.