Architecture
This page explains how the project is structured at the code level.
High-Level Architecture
Rug Radar has two major parts:
- the MCP/HTTP server
- the Docusaurus docs app
The server is in the repository root. The docs app lives in apps/docs/.
Server Composition
Entry point
src/index.ts
Responsibilities:
- load environment variables
- create the MCP server
- register tools
- expose Express routes
- manage MCP transport sessions
Tool handlers
Located in src/tools/.
Each tool owns:
- input handling
- orchestration of upstream adapters
- result shaping
- graceful fallback behavior where relevant
External API adapters
Located in src/api/.
Responsibilities:
- call DEX Screener, RugCheck, Helius, and Bags
- normalize upstream response shapes
- return clean internal snapshots
Utilities
Located in src/utils/.
Responsibilities:
- scoring
- formatting
- validation
- HTTP fetch/cache/error normalization
Persistence layer
Located in src/db/.
Responsibilities:
- Postgres connectivity and queries
- watchlist, snapshot, alert, and event persistence
- Redis alert deduplication
Request Flow Examples
analyze_token
- validate input
- resolve by address or token name
- fetch DEX data
- fetch RugCheck, Helius, and Bags data
- compute risk score
- return structured result plus source metadata
watch_token
- validate token address
- normalize thresholds
- upsert watchlist in Postgres
- run token analysis
- store baseline snapshot and tool event
get_token_changes
- load latest snapshot
- run fresh token analysis
- store new snapshot
- compute change set
- evaluate watchlist thresholds
- insert deduplicated alerts
Public HTTP Endpoints
/: info-style metadata response/health: health status/info: name, version, tools, and endpoint map/mcp: MCP transport
Caching And State
- upstream HTTP responses are cached in memory
- Postgres stores durable watchlists and snapshots
- Redis is optional and stores dedupe keys for alerts
Docs App
The documentation and landing site are built with Docusaurus and live under apps/docs/.