rugradar
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ADMIN_TOKEN | No | Optional admin token for feedback export. | |
| RUGRADAR_AB | No | Optional A/B testing configuration. | |
| FALLBACK_MODEL | No | Optional model for the second provider. | |
| GEMINI_API_KEY | No | Optional API key for model explanations. | |
| FALLBACK_API_KEY | No | Optional API key for the second provider. | |
| FALLBACK_BASE_URL | No | Optional base URL for the second provider. | |
| UPSTASH_REDIS_REST_URL | No | Optional Upstash Redis REST URL for durable memory. | |
| UPSTASH_REDIS_REST_TOKEN | No | Optional Upstash Redis REST token for durable memory. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_tokenA | Check if a crypto token is a scam before buying. |
| scan_messageA | Scan a crypto pitch message for scam tactics (seed phrase requests, wallet-drainer links, guaranteed returns, urgency, send-to-receive) without touching the network. Private data is stripped. |
| token_historyC | What RugRadar saw the last time this token was checked (verdict, score, pool size, how long ago). |
| explain_findingB | Plain-language meaning of a RugRadar finding code such as HONEYPOT or LP_UNLOCKED. |
| get_reportA | Fetch a saved RugRadar check by its id (the code at the end of a rugradar-dun.vercel.app/r/... link). Saved checks last 30 days. Re-run check_token before relying on an old one: tokens change fast. |
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 5 tools
Tools have distinct purposes: check_token and scan_message both assess scams but differ in scope (network vs. text-only), and get_report vs. token_history retrieve different historical data. However, check_token's inclusion of message red flags creates minor overlap with scan_message, and both historical tools could be confused.
Four tools follow a verb_noun pattern (get_report, check_token, scan_message, explain_finding), but token_history uses a noun_noun pattern, a minor deviation. Overall consistent and readable.
Five tools are well-suited for a focused token scam checker; each covers a distinct need (checking, scanning, retrieving, explaining). No tools feel redundant or missing.
The surface covers token checking, message scanning, report retrieval, history, and finding explanations, which is comprehensive for the domain. Minor gap: no tool to list or search saved reports, but agents can work around it.