Which integrations are available for this server?

Fetches GitHub user profiles, repositories, follower counts, and account details to enrich token claim cards with developer reputation and credibility scoring. Monitors Solana blockchain for PumpFun claim events and token graduations, providing real-time on-chain data for enrichment and alerting. Publishes real-time PumpFun claim and graduation cards to a Telegram channel, including rich media and formatted messages.

How do I use pumpfun-claims-bot?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pumpfun-claims-bot show recent GitHub social fee claims with credibility scores" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en ja ko ru zh

pumpfun-claims-bot

by nirholas

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

PumpFun Claims Bot

Looking for interactive monitoring? The telegram-bot supports watch management, group chats, REST API, SSE streaming, and webhooks. Use this channel-bot for simple broadcast-only channels.

Features

Feed Types

Feed	Description	Toggle
GitHub Social Fee Claims	GitHub devs claiming PumpFun social fee PDA rewards	`FEED_CLAIMS`
Token Graduations	Tokens graduating from bonding curve to PumpAMM	`FEED_GRADUATIONS`

Claim Intelligence

Every GitHub social fee claim card includes:

Feature	Description
🟢 Credibility Score	Deterministic 0-100 verdict (Strong/Moderate/Caution/High Risk) synthesised from every trust signal, with a transparent ±factor breakdown
📊 Dev Track Record	Persistent per-developer reputation — a repeat dev's prior tokens and their average credibility, so a serial fee-farmer whose newest coin looks clean is exposed on sight
🚨 First-Time Alert	`🚨🚨🚨 FIRST TIME CLAIM` banner when a GitHub user claims for the first time ever
⚠️ Fake Claim Detection	Detects when `claim_social_fee_pda` instruction is called but no fees are actually paid out
📊 Claim Counter	Sequential claim number tracked persistently across restarts
💹 Lifetime SOL	Total SOL claimed from the PDA over all time
👤 GitHub Profile	Username, bio, repos, followers, account age, location, blog
𝕏 Social Links	Twitter/X profile with follower counts (from GitHub profile)
🏅 Influencer Badge	Tier-based badge for high-follower GitHub/X accounts
📈 Token Intel	Graduated/bonding curve status, curve progress %, created age, reply count
🔗 Token Socials	Twitter, Telegram, website links from token metadata
🏷️ Token Flags	NSFW, banned, cashback status indicators
⚠️ Trust Signals	Warnings for new GitHub accounts (< 30 days), zero repos, fake claims
🔗 Trading Links	Axiom, GMGN, Padre links with affiliate codes
️ Token Image	Token image or GitHub avatar as photo card

Graduation Cards

Rich graduation cards include creator profile, top holders analysis, 24h trading volume, dev wallet activity, pool liquidity, and bundle detection.

Influencer Tier System

Combines GitHub and X/Twitter follower data to classify claimers:

Tier	Badge	X Followers	GitHub Followers
Mega	🔥🔥 MEGA INFLUENCER	≥ 100K	≥ 10K
Influencer	🔥 Influencer	≥ 10K	≥ 1K
Notable	⭐ Notable	≥ 1K	≥ 100

Either threshold triggers the tier — a user with 50K X followers and 50 GitHub followers still qualifies as Influencer.

Credibility Score & Dev Track Record

Every claim card leads with a deterministic 0-100 credibility verdict synthesised from the trust signals the bot already gathers, plus the claiming dev's persistent track record across prior tokens.

The score is deterministic and transparent — same inputs always produce the same number, no model call, and every point is attributed to a named factor shown under the headline:

Tier	Badge	Score
Strong	🟢	75-100
Moderate	🟡	55-74
Caution	🟠	35-54
High Risk	🔴	0-34

Scoring starts at a neutral 50 and adjusts by weighted factors: claim verification (+22, or -20 on a GitHub-owner mismatch), account age (+14 for 5y+ down to -18 for < 30 days), public repos, followers, starred non-fork repo, copycats (-10/-16), bundling, holder concentration, prior rugs, and bans.

Dev track record turns that one-shot score into memory. Every score is recorded against the claiming GitHub user id and persisted, so the next time that dev launches a token the card shows their history — exposing a serial fee-farmer whose newest coin looks clean, and crediting a builder with a real record:

🟢 Credibility: 100/100 · Strong
   ↑ claim verified · GitHub 6y · 42 repos · repo 150★
📊 Dev track record: 3 prior tokens · avg 🔴 19/100 (High Risk)

Logic lives in src/credibility.ts (pure scoreCredibility) and src/dev-reputation.ts (persistent store), both fully covered by tests.

AI-Powered Claim Summaries

First-time claims get a one-line AI take generated by Groq (llama-3.3-70b-versatile):

Analyzes 30+ signals: token metadata, GitHub profile, creator history, trading activity
Max 120 characters — direct, opinionated, trader-focused
5-second timeout with graceful fallback (empty string on failure)
HTML-sanitized output safe for Telegram

Examples:

"Real GitHub project, dev claimed fast" · "Fork of popular repo, proceed with caution"

Related MCP server: NoesisAPI

Architecture

Solana RPC (WebSocket + HTTP polling)
        │
        ▼
┌───────────────────┐
│  SocialFeeIndex   │──▶ Bootstraps ~148K SharingConfig → mint mappings
└────────┬──────────┘
         │
┌────────▼──────────┐
│   ClaimMonitor    │──▶ Decodes PumpFees program claim transactions
│   EventMonitor    │──▶ Decodes Pump program logs (graduations)
└────────┬──────────┘
         │ FeeClaimEvent / GraduationEvent
┌────────▼──────────┐
│ Enrichment Layer  │
│  ├─ GitHub API    │──▶ User profile, repos, followers
│  ├─ X/Twitter API │──▶ Follower counts, influencer tier
│  ├─ PumpFun API   │──▶ Token info, creator profile, holders, trades
│  ├─ ClaimTracker  │──▶ First-claim detection, persistent counts
│  └─ Fake Detect   │──▶ Instruction called but no payout (amountLamports=0)
└────────┬──────────┘
         │ ClaimFeedContext
┌────────▼──────────┐
│    Formatters     │──▶ Rich HTML cards with sections & emoji layout
└────────┬──────────┘
         │
┌────────▼──────────┐
│   grammY Bot      │──▶ Posts photo + caption to Telegram channel
│   (retry + rate   │    Falls back to text-only if photo fails
│    limiting)      │
└───────────────────┘

Multi-RPC Failover

The RpcFallback class manages multiple Solana RPC endpoints with automatic rotation:

Round-robin rotation after 3 consecutive failures on any endpoint
60-second cooldown per failed endpoint before retrying
Earliest-expiry fallback — if all endpoints are in cooldown, picks the one expiring soonest
Success resets — a single successful call resets the failure counter
Configure via SOLANA_RPC_URLS (comma-separated)

Programs Monitored

Program	ID	Purpose
PumpFees	`pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ`	Fee sharing, social fee PDA claims
Pump	`6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P`	Bonding curve (graduations)
PumpAMM	`pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`	AMM (graduated pool events)

Install

npm (MCP server — recommended for AI assistants)

Run the MCP server instantly with npx — no clone needed:

npx pumpfun-claims-bot

Or install globally:

npm install -g pumpfun-claims-bot
pumpfun-claims-bot

Add to your MCP client config (Claude Desktop, Cursor, VS Code Copilot):

{
  "mcpServers": {
    "pumpfun": {
      "command": "npx",
      "args": ["pumpfun-claims-bot"]
    }
  }
}

npm package: pumpfun-claims-bot on npm

From source (full bot + Telegram feed)

git clone https://github.com/nirholas/pumpfun-claims-bot.git
cd pumpfun-claims-bot && npm install

Quick Start

1. Create a Telegram Bot

Message @BotFather on Telegram
/newbot → follow prompts → copy the bot token
Create a public channel (e.g., @pumpfunclaims)
Add the bot as an admin to the channel (must have "Post Messages" permission)

2. Configure Environment

cp .env.example .env

# ── Required ──────────────────────────────────────────────
TELEGRAM_BOT_TOKEN=your-bot-token-from-botfather
CHANNEL_ID=@your_channel_name    # or numeric chat ID like -100xxx

# ── Solana RPC ────────────────────────────────────────────
SOLANA_RPC_URL=https://mainnet.helius-rpc.com/?api-key=your-key
SOLANA_WS_URL=wss://mainnet.helius-rpc.com/?api-key=your-key

# Comma-separated fallback RPCs (rotates on 429/5xx/timeout)
SOLANA_RPC_URLS=https://mainnet.helius-rpc.com/?api-key=key1,https://your-other-rpc.com

# ── Feed Toggles (all default false except FEED_CLAIMS) ───
FEED_CLAIMS=true                 # GitHub social fee claims (default: true)
FEED_GRADUATIONS=false           # Token graduations to PumpAMM (default: false)
FEED_LAUNCHES=false              # New token launches (default: false)
FEED_WHALES=false                # Large buy/sell whale alerts (default: false)
FEED_FEE_DISTRIBUTIONS=false     # Creator fee distribution events (default: false)

# ── Claim Filter ──────────────────────────────────────────
REQUIRE_GITHUB=true              # Only post claims with GitHub social fee PDA (default: true)

# ── Enrichment APIs ───────────────────────────────────────
GITHUB_TOKEN=ghp_your_token      # Raises GitHub rate limit: 60 → 5000 req/hr
GROQ_API_KEY=gsk_your_key        # Groq API for AI one-liner summaries

# X/Twitter follower counts & influencer detection
# Get cookies from x.com DevTools → Application → Cookies
# X_AUTH_TOKEN=your_auth_token_cookie
# X_CT0_TOKEN=your_ct0_cookie

# ── Affiliate Ref Codes ───────────────────────────────────
# Appended to Axiom / GMGN / Padre trading links in cards
# AXIOM_REF=your_ref
# GMGN_REF=your_ref
# PADRE_REF=your_ref

# ── Tuning ────────────────────────────────────────────────
POLL_INTERVAL_SECONDS=30         # HTTP polling fallback interval (default: 30)
WHALE_THRESHOLD_SOL=10           # Minimum SOL for whale alerts (default: 10)
LOG_LEVEL=info                   # debug | info | warn | error (default: info)

# ── Health Check ──────────────────────────────────────────
# PORT=3000                      # Set automatically by Railway

Environment Variables Reference

Variable	Required	Default	Description
`TELEGRAM_BOT_TOKEN`	✅	—	Bot token — message @BotFather → `/newbot`
`CHANNEL_ID`	✅	—	Channel to post to (`@channelname` or `-100xxx`) — get the numeric ID via @userinfobot
`SOLANA_RPC_URL`	✅	`https://api.mainnet-beta.solana.com`	Primary Solana HTTP RPC — free tier at Helius, QuickNode, or Alchemy
`SOLANA_WS_URL`	—	Derived from `SOLANA_RPC_URL`	Solana WebSocket URL — same provider as `SOLANA_RPC_URL`, replace `https://` with `wss://`
`SOLANA_RPC_URLS`	—	—	Comma-separated fallback RPC URLs — auto-rotates on 429 / 5xx / timeout
`FEED_CLAIMS`	—	`true`	Post GitHub social fee claim cards
`FEED_GRADUATIONS`	—	`false`	Post token graduation cards
`FEED_LAUNCHES`	—	`false`	Post new token launch cards
`FEED_WHALES`	—	`false`	Post whale buy/sell alerts
`FEED_FEE_DISTRIBUTIONS`	—	`false`	Post creator fee distribution events
`REQUIRE_GITHUB`	—	`true`	Skip claims that have no GitHub social fee PDA
`GITHUB_TOKEN`	—	—	GitHub PAT — create one here (no scopes needed) — raises rate limit from 60 → 5000 req/hr
`GROQ_API_KEY`	—	—	Groq API key for AI one-liner summaries — get a free key at console.groq.com
`X_AUTH_TOKEN`	—	—	X/Twitter `auth_token` cookie — open x.com, DevTools → Application → Cookies → copy `auth_token`
`X_CT0_TOKEN`	—	—	X/Twitter `ct0` cookie (CSRF token) — same place as above, copy `ct0`
`AXIOM_REF`	—	—	Affiliate ref code for Axiom trading links
`GMGN_REF`	—	—	Affiliate ref code for GMGN trading links
`PADRE_REF`	—	—	Affiliate ref code for Padre trading links
`POLL_INTERVAL_SECONDS`	—	`30`	HTTP polling interval when WebSocket is unavailable
`WHALE_THRESHOLD_SOL`	—	`10`	Minimum SOL trade size to trigger a whale alert
`LOG_LEVEL`	—	`info`	Log verbosity: `debug` \| `info` \| `warn` \| `error`
`PORT`	—	`3000`	Health check HTTP server port — set automatically by Railway
`MCP_ENABLED`	—	`false`	Enable the MCP (Model Context Protocol) server for AI assistant integrations
`MCP_PORT`	—	`3001`	MCP server HTTP port (Streamable HTTP transport)

3. Run

# Install dependencies
npm install

# Development (hot reload via tsx)
npm run dev

# Production
npm run build
npm start

4. Deploy with Docker

docker build -t pumpfun-channel-bot .
docker run -d --env-file .env pumpfun-channel-bot

5. Deploy to Railway

Deploy on Railway

Railway auto-deploys from GitHub and provides persistent volumes for claim tracking data.

# Install Railway CLI
npm install -g @railway/cli
railway login

# Create & link project
railway init
railway link

# Set environment variables
railway variables set TELEGRAM_BOT_TOKEN=your-token
railway variables set CHANNEL_ID=@your_channel_name
railway variables set SOLANA_RPC_URL=https://mainnet.helius-rpc.com/?api-key=your-key
railway variables set SOLANA_WS_URL=wss://mainnet.helius-rpc.com/?api-key=your-key
railway variables set FEED_CLAIMS=true
railway variables set REQUIRE_GITHUB=true

# Create persistent volume for claim tracker data
railway volume create --mount /app/data

# Deploy
railway up

See railway.json for the deployment config:

{
  "$schema": "https://railway.app/railway.schema.json",
  "build": {
    "builder": "DOCKERFILE",
    "dockerfilePath": "Dockerfile"
  },
  "deploy": {
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 10
  }
}

Project Structure

pumpfun-claims-bot/
├── src/
│   ├── index.ts              # Entry point — wires monitors, enrichment, & Telegram posting
│   ├── config.ts             # Environment variable loading & validation
│   ├── mcp-server.ts         # MCP server — exposes tools via Streamable HTTP or stdio
│   ├── mcp-stdio.ts          # Standalone MCP entry point (stdio transport)
│   ├── claim-monitor.ts      # PumpFees program monitor (WebSocket + HTTP polling)
│   ├── claim-routing.ts      # Decides which claims are posted, skipped, or re-routed
│   ├── claim-tracker.ts      # First-claim detection + claim counter (persisted to disk)
│   ├── credibility.ts        # Deterministic 0-100 credibility scoring
│   ├── dev-reputation.ts     # Persistent per-developer track record store
│   ├── event-monitor.ts      # Pump program log decoder (graduations, launches)
│   ├── social-fee-index.ts   # SocialFeeIndex — maps SharingConfig PDAs → mints (~148K)
│   ├── formatters.ts         # Rich HTML card builders for Telegram
│   ├── pump-client.ts        # PumpFun HTTP API client (token info, creator profiles)
│   ├── github-client.ts      # GitHub API client (user profiles, rate-limited cache)
│   ├── x-client.ts           # X/Twitter profile fetcher + influencer tier logic
│   ├── groq-client.ts        # Groq AI one-liner summaries
│   ├── rpc-fallback.ts       # Multi-RPC failover with round-robin
│   ├── health.ts             # HTTP health check server
│   ├── types.ts              # Program IDs, discriminators, event types
│   └── logger.ts             # Leveled console logger
├── src/__tests__/            # Vitest suites (203 tests) + shared fixtures
├── packages/web/             # React dashboard, mock-data build (see Web Dashboard)
├── web/web/                  # React dashboard, live-SSE build (see Web Dashboard)
├── leaderboard-bot/          # Separate Telegram bot: GitHub dev earnings leaderboard
├── data/                     # Persisted state (gitignored, Railway volume mount)
│   └── github-first-claims.json
├── Dockerfile                # Multi-stage Docker build
├── railway.json              # Railway deployment config
├── package.json
└── tsconfig.json

How It Works

Claim Detection Pipeline

Transaction detected on PumpFees program
  │
  ▼
Identify instruction: claim_social_fee_pda?
  │
  ├─ YES ──▶ Parse platform (2 = GitHub) + user_id from Anchor args
  │           │
  │           ▼
  │        Check amountLamports from SocialFeePdaClaimed event
  │           │
  │           ├─ amountLamports > 0 ──▶ Real claim
  │           │   ├─ Check ClaimTracker: first time for this GitHub user?
  │           │   │   ├─ YES ──▶ 🚨 FIRST TIME CLAIM banner
  │           │   │   └─ NO  ──▶ Standard claim card
  │           │   └─ Enrich: GitHub API + PumpFun API + X profile
  │           │
  │           └─ amountLamports = 0 ──▶ ⚠️ FAKE CLAIM (instruction called, no payout)
  │
  └─ NO ───▶ Other claim type (creator fee, cashback, etc.)

On startup, the bot fetches all SharingConfig accounts from the PumpFees program to build a reverse mapping from social fee PDA addresses to token mints. This enables resolving which token a social fee claim belongs to without additional RPC calls.

~148K mappings loaded at startup
Incremental updates via WebSocket subscription on CreateFeeSharingConfig and UpdateFeeShares events
Lookup: socialFeeIndex.getMintForPda(pdaAddress) → token mint
One PDA → many mints — handles scammers who reuse PDAs across multiple tokens

Fake Claim Detection

Some users call the claim_social_fee_pda instruction targeting random token PDAs where they have no fees to collect. The bot detects these by checking:

The instruction discriminator matches claim_social_fee_pda
The transaction logs contain no SocialFeePdaClaimed event — OR the event shows amountLamports = 0
The GitHub user ID and platform are still parsed from the instruction args (Anchor Borsh format)

Fake claims are posted with a ⚠️ FAKE CLAIM warning and a 🚩 Fake claim — no fees paid out trust signal.

First-Claim Tracking

The ClaimTracker maintains a persistent set of GitHub user IDs that have successfully claimed:

In-memory set for fast lookup during processing
Debounced disk persistence (5-second delay) to data/github-first-claims.json
Split check/mark pattern: hasGithubUserClaimed() checks without side effects, markGithubUserClaimed() only called after successful Telegram post
Claim counter: incrementGithubClaimCount() returns sequential claim number per user
First-claim status is NOT set for fake claims

Three-Layer First-Claim Verification

Local dedup — Skip if already posted (survives restarts via persisted JSON)
On-chain verification — lifetimeClaimedLamports == amountLamports confirms it's truly the first claim on-chain
Graceful fallback — Skips first-claim banner if verification fails (prevents false positives after redeployment)

Example Claim Card

🚨🚨🚨 FIRST TIME CLAIM 🚨🚨🚨

🐙 $PUMP — PumpCoin  💹 $45K
  ↳ GitHub dev claimed PumpFun social fees

📊 Claim #1 · 0.1043 SOL lifetime ($15.65)

🏦 0.1043 SOL ($15.65)
  ↳ 8mNp...4rWz

👤 nirholas (Nicholas)
  ↳ 📦 45 · 👁 200 · 📅 5y ago
  TypeScript SDK builder
𝕏 nichxbt · 1.2K

📈 Bonding curve (72%) · Created 3h ago · 💬 12
𝕏 @pump_coin · 💬 TG · 🌐 pumpcoin.io

⚠️ GitHub account created 15d ago

CA: 7xKXt...p3Bz
Axiom · GMGN · Padre

🔍 TX

Requirements

Node.js >= 20.0.0
Telegram bot token (via @BotFather)
Telegram channel with the bot added as admin
Solana RPC endpoint — dedicated RPC recommended (Helius, QuickNode, Triton). Public mainnet works but may rate-limit.
GitHub token (optional) — raises API rate limit from 60 to 5,000 req/hr

Troubleshooting

Bot Not Posting Messages

Check bot permissions — The bot must be an admin in the channel with "Post Messages" permission
Verify CHANNEL_ID — Use @channel_name for public channels or the numeric ID (e.g., -100xxx) for private channels. To find the numeric ID, forward a channel message to @userinfobot
Telegram 403 error — Means the bot is NOT a member/admin of the channel. Add it via channel settings → Administrators → Add Administrator
Check logs — Set LOG_LEVEL=debug to see all events the bot processes

Rate Limiting

Telegram limits bots to ~30 messages per second to a channel. The grammY framework handles rate limiting automatically:

Messages may be delayed but won't be dropped
The bot includes a retry helper that respects retry_after headers
For very high activity, increase POLL_INTERVAL_SECONDS to reduce event volume

RPC Connection Issues

Public RPC endpoints have rate limits — for production use a dedicated RPC
Set SOLANA_RPC_URLS with multiple endpoints for automatic failover
If WebSocket disconnects, the bot falls back to HTTP polling at POLL_INTERVAL_SECONDS
The RpcFallback class provides round-robin across configured endpoints
Set LOG_LEVEL=debug to see connection status

Missing Claims

GitHub claims only? — Set REQUIRE_GITHUB=true to only post GitHub social fee claims
Feed disabled? — Verify FEED_CLAIMS=true is set
SocialFeeIndex slow? — Initial bootstrap fetches ~148K accounts. This takes 30-60 seconds on startup. Check logs for SocialFeeIndex: loaded N mappings
Rate limited? — GitHub API allows 60 req/hr unauthenticated. Set GITHUB_TOKEN for 5,000 req/hr

Pipeline Stats

The bot logs pipeline counters every 60 seconds:

Pipeline: 15 total → 8 social → 3 first / 5 repeat → 8 posted (skip: 7 cashback)

total: All claim events received
social: GitHub social fee PDA claims
first/repeat: First-time vs. returning claimers
posted: Successfully posted to Telegram
skip cashback: Cashback claims (user refunds, not creator activity)

Web Dashboard

Two React frontends are checked in, and they are not the same app:

Directory	What it is	Build
`web/web/`	The full dashboard: SSE event stream, watch lists, SEO assets (`robots.txt`, `sitemap.xml`, `llms.txt`). Has its own lockfile, so `npm ci` works.	`cd web/web && npm ci && npm run build`
`packages/web/`	An earlier, smaller copy of the same UI. Its Dashboard renders generated sample events, with no SSE client.	`cd packages/web && npm ci && npm run build`

The features listed below describe web/web/. Both directories build clean today; consolidating them onto one is still open work.

Deep links (/dashboard, /docs, ...) are client-side routes, so any static host must rewrite unknown paths to index.html. Each app now ships a vercel.json with that rewrite; on a non-Vercel host, configure the equivalent SPA fallback.

Pages

Page	Route	Description
Home	`/`	Landing page with project overview
Dashboard	`/dashboard`	Live event feed with SSE streaming
Create Coin	`/create`	Token creation interface
Docs	`/docs`	API documentation & Telegram commands
Packages	`/packages`	Package browser

Dashboard Features

Server-Sent Events (SSE) — Real-time streaming via /api/v1/claims/stream with auto-reconnect (3s delay)
Event Filters — All, Launches, Whales, Graduations, Claims, Distributions
Live Stats Bar — Counters for each event type
Watch Lists — Add/remove wallet addresses to monitor (GET/POST/DELETE /api/v1/watches)
Rich Event Cards — Token launches, whale trades, graduations, fee claims with full context
Connection Status — Visual indicator with error messages
Mock Data Fallback — Simulated feed when SSE is unavailable

Tech Stack

Layer	Technology
Framework	React 18
Router	React Router
Build	Vite 5
Styling	Tailwind CSS
Language	TypeScript

MCP Server

The bot includes a built-in Model Context Protocol (MCP) server that lets AI assistants (Claude, Copilot, Cursor, etc.) query PumpFun on-chain data conversationally.

MCP Tools

Tool	Description
`get_token_info`	Token metadata, market cap, bonding curve progress, flags
`get_token_holders`	Top holders with concentration metrics
`get_token_trades`	Recent trade activity — volume, buy/sell counts
`get_pool_liquidity`	PumpSwap AMM pool liquidity for graduated tokens
`get_bundle_info`	Bundle detection (scam indicator)
`get_creator_profile`	Creator launch history, scam estimate, recent coins
`get_github_user`	GitHub profile by username or numeric ID
`get_claim_history`	Claim status for a GitHub user — count, mints claimed
`get_sol_price`	Current SOL/USD price

Usage: Stdio Transport (Claude Desktop / Cursor / VS Code)

Add to your MCP client config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "pumpfun": {
      "command": "npx",
      "args": ["pumpfun-claims-bot"]
    }
  }
}

Or run from source:

# Development (tsx)
npm run mcp:dev

# Production (compiled)
npm run build && npm run mcp

Usage: Streamable HTTP Transport (Embedded)

Run alongside the main bot by setting MCP_ENABLED=true:

MCP_ENABLED=true MCP_PORT=3001 npm run dev

The MCP endpoint is available at POST /mcp on the configured port. Clients connect using the Streamable HTTP transport.

Example Queries

Once connected, ask your AI assistant:

"Look up token info for mint address 7xKXt...p3Bz"
"Has GitHub user 12345 ever claimed PumpFun fees?"
"Who are the top holders of this token?"
"Check if this token launch was bundled"
"What's the current SOL price?"

Health Check API

The bot exposes an HTTP health check server for Railway / Docker probes.

Endpoint	Method	Description
`/health`	GET	Health status with uptime and stats
`/`	GET	Alias for `/health`

Response:

{
  "status": "ok",
  "uptime": "12345s",
  "uptimeMs": 12345000
}

Returns 200 for ok, 503 for degraded
Dynamic stats injected via callback (pipeline counters, connection status)
Port configurable via PORT or HEALTH_PORT env vars (default: 3000)

Testing

The project uses Vitest: 203 tests across 11 suites, all green on npm test.

# Run all tests
npm test

# Watch mode (re-runs on file changes)
npm run test:watch

Test Suites

Every suite lives in src/__tests__/ (plus fixtures.ts, shared sample data).

Suite	File	Coverage
Claim Tracker	`claim-tracker.test.ts`	First-claim detection, persistence, counters, lifetime totals
Claim Routing	`claim-routing.test.ts`	Which claims are posted, skipped, or routed to which feed
Credibility	`credibility.test.ts`	Deterministic 0-100 scoring, per-factor attribution, tier bounds
Dev Reputation	`dev-reputation.test.ts`	Persistent per-developer track record and averages
Formatters	`formatters.test.ts`	HTML card generation, escaping, null handling, edge cases
GitHub Client	`github-client.test.ts`	URL parsing, API response handling, cache behavior
Groq Client	`groq-client.test.ts`	AI summary generation, API key handling, HTML safety
Pump Client	`pump-client.test.ts`	Token, holder, trade, and creator API response handling
RPC Fallback	`rpc-fallback.test.ts`	Round-robin rotation, cooldowns, retryable error handling
X Client	`x-client.test.ts`	Influencer tier classification, follower formatting
E2E Pipeline	`e2e.test.ts`	End-to-end claim tracking, formatting, GitHub feed

Local Development

# Install dependencies
npm install

# Run with hot reload (tsx)
npm run dev

# Type-check without emitting
npm run typecheck

Set LOG_LEVEL=debug — all events are logged to stdout regardless of whether they're posted to Telegram.

Tech Stack

Component	Technology
Runtime	Node.js >= 20 (ESM)
Language	TypeScript 5.7 (strict mode)
Blockchain	Solana via `@solana/web3.js`
Telegram	grammY framework
AI	Groq API (llama-3.3-70b-versatile)
Frontend	React 18 + Vite 5 + Tailwind CSS
Testing	Vitest
Container	Docker (multi-stage Alpine, non-root)
MCP	`@modelcontextprotocol/sdk` (Streamable HTTP + stdio)
Hosting	Railway (auto-deploy from GitHub)
Dependencies	6 production, 4 dev — intentionally minimal

Contributing

Contributions are welcome! See CONTRIBUTING.md for guidelines.

Fork the repo
Create a feature branch (git checkout -b feat/my-feature)
Run tests (npm test) and typecheck (npm run typecheck)
Open a Pull Request

Security

Found a vulnerability? Please report it responsibly — see SECURITY.md.

License

Documentation

Full documentation site: https://nirholas.github.io/pumpfun-claims-bot/

Getting started covers install and first run.
Examples has copy-paste snippets.

Available Tools

9 tools

get_bundle_infoB

Detect if a token launch was bundled (scam indicator)

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Token mint address

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the tool's purpose but does not disclose what the tool returns (e.g., a boolean, a score, details), whether it makes external calls, or any side effects. For a detection tool, the output format and interpretation are critical, and this is not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose. It is efficient and contains no fluff. However, it could be slightly more structured by including a note about the output or usage, but for its length, it is well-written.

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

Completeness2/5

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

Given the tool's complexity (a detection tool with a single parameter and no output schema), the description is incomplete. It does not explain what the tool returns, how to interpret the result, or any limitations. The agent would need to guess the output format, which is a significant gap for a tool that provides a scam indicator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100% for the single parameter 'mint', which is described as 'Token mint address'. The description adds no additional meaning beyond the schema, but since the schema fully covers the parameter, a baseline of 3 is appropriate. The description does not clarify the format or any constraints beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: detecting if a token launch was bundled, which is a scam indicator. It uses a specific verb ('Detect') and resource ('token launch'), and it distinguishes itself from sibling tools like get_token_info or get_token_holders by focusing on the bundling scam aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for scam detection but does not explicitly state when to use this tool versus alternatives. It doesn't mention when not to use it or provide context on how it fits with other token analysis tools. The purpose is clear enough that an agent could infer usage, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_claim_historyA

Check claim history for a GitHub user — whether they have claimed, claim count, and which token mints they claimed from

ParametersJSON Schema

Name	Required	Description	Default
`githubUserId`	Yes	GitHub numeric user ID

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It clearly indicates this is a read-only operation ('Check claim history') and explains what information is returned (claim status, count, and token mints). However, it doesn't disclose any other behavioral traits like whether it requires authentication, rate limits, or any side effects, but for a simple read tool, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that is front-loaded with the purpose, then details what is checked. It is concise without unnecessary words, but it could be slightly more structured (e.g., separating purpose from details), yet it is efficient and to the point.

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

Completeness3/5

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

Given the tool has only one parameter and no output schema, the description is fairly complete for a simple query tool. It tells the agent what to expect (claim status, count, and token mints). However, it lacks information on edge cases, such as what happens if the user hasn't claimed anything or if the user ID is invalid, which would be helpful but not critical given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (only one parameter, githubUserId, which is described as 'GitHub numeric user ID'). The description adds context by explaining what the tool does with that user ID (checks their claim history), which is helpful. However, since the schema already fully documents the parameter, the baseline is 3, and the description doesn't add much beyond that.

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 description uses a clear verb ('Check') and specific resource ('claim history'), and distinguishes the tool from siblings by stating it checks 'whether they have claimed, claim count, and which token mints they claimed from'. This is specific and unambiguous, differentiating it from other get_* tools that focus on tokens or pools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you need to check a GitHub user's claim history), but it does not provide explicit guidance on when not to use it or alternatives. Unlike the high-scoring example, it doesn't name alternative tools or exclude scenarios, so it's adequate but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_creator_profileA

Fetch PumpFun creator profile — username, launch count, scam estimate, recent coins

ParametersJSON Schema

Name	Required	Description	Default
`wallet`	Yes	Creator wallet address

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. The use of 'Fetch' implies a read-only operation, but it does not explicitly state that the tool does not modify data or mention any potential side effects, rate limits, or authentication requirements. It does, however, add context by listing the returned fields, which is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that starts with the verb and resource, then lists the return fields. No unnecessary words or redundancy, making it highly concise and well-structured.

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?

The tool is simple with one parameter and no output schema. The description adequately explains what the tool returns (username, launch count, scam estimate, recent coins), which is sufficient for an agent to understand the expected result. Complexity is low, and the description covers the key aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% since the wallet parameter has a clear description ('Creator wallet address'). The tool description does not add any additional meaning beyond the schema; it only lists the fields returned, not further elaboration on the parameter. Baseline 3 is appropriate.

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 description clearly states the tool fetches a PumpFun creator profile and lists specific return fields (username, launch count, scam estimate, recent coins). This is a specific verb+resource that distinguishes it from sibling tools like get_token_info or get_github_user.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving creator profiles but does not explicitly state when to use it versus alternatives or any exclusions. It lacks guidance such as 'use when you need creator details' or when not to use it. The intent is clear from the resource type but not explicitly articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_github_userB

Fetch GitHub user profile by username or numeric ID — repos, followers, bio, account age

ParametersJSON Schema

Name	Required	Description	Default
`userId`	No	GitHub numeric user ID
`username`	No	GitHub username (login)

TDQS

B3.3/5.0

Behavior1/5

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

There are no annotations provided, and the description does not disclose any behavioral traits such as read-only nature, side effects, rate limits, or required permissions. The tool appears to be a simple fetch, but without explicit disclosure, the agent cannot assess side effects or constraints. This fails to carry the behavioral transparency burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that packs in the essential information: what it does, the input method, and the output scope. No unnecessary words or redundancy. It is well-structured and easy to parse.

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

Completeness3/5

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

The description provides a partial view of the output (repos, followers, bio, account age) but does not mention error handling, return format, or any limitations. Since there is no output schema, the description should compensate more fully. However, given the simplicity of the tool, a score of 3 is appropriate.

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?

The input schema already provides clear descriptions for each parameter ('GitHub numeric user ID' and 'GitHub username (login)'). The tool description adds meaningful clarification that either parameter can be used, reinforcing the intended usage. This goes beyond the schema's individual field descriptions, earning a high score.

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 description clearly states the tool's function: 'Fetch GitHub user profile' and specifies the input method ('by username or numeric ID') and the key data returned ('repos, followers, bio, account age'). This is a specific verb+resource statement that distinguishes it from other tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given on when to use this tool versus alternatives. While the sibling tools are clearly different (e.g., token info, pool liquidity), the description does not state conditions, exclusions, or preferences. It only describes the basic function, leaving the agent to infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pool_liquidityA

Fetch PumpSwap AMM pool liquidity for a graduated token

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Token mint address
`usdMarketCap`	No	Current USD market cap (for context)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must carry the burden of behavioral disclosure. It states it fetches data, implying a read operation, but does not elaborate on whether the pool exists, what happens if the token is not graduated, or any specific data returned. It adds 'for a graduated token' which is useful, but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the main purpose. No wasted words. It is appropriately sized and conveys the essential information.

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

Completeness3/5

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

Given the tool has a simple purpose and full schema coverage, the description is adequate but could mention what data is returned (e.g., liquidity amounts, reserve values) even without an output schema. It lacks details on error cases or prerequisites, but is sufficient for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions. The description does not add additional meaning beyond the schema, but the schema already provides adequate guidance. Baseline of 3 is appropriate since no extra context is provided.

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 description clearly states the action ('Fetch') and the specific resource ('PumpSwap AMM pool liquidity') qualified by 'for a graduated token'. It distinguishes the tool from siblings that fetch token info, holders, trades, etc., by focusing on liquidity of an AMM pool.

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 implies usage in the context of graduated tokens, which helps the agent understand when to use it (post-graduation). However, it does not explicitly mention when not to use it or alternatives, though siblings are available and the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sol_priceA

Fetch current SOL/USD price

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Fetch') but does not mention any behavioral details such as return format, potential delays, rate limits, or whether it requires authentication. For a simple read tool this is acceptable but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, highly concise with zero filler. It is front-loaded with the key verb and resource. Every word earns its place.

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

Completeness4/5

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

Given the simplicity of the tool (no parameters, no nested objects, no output schema), the description is largely sufficient. However, it does not specify the exact return value (e.g., numeric price, string representation, or whether it includes historical data), which could leave slight ambiguity. Still, for a straightforward price getter, it is adequate.

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?

The tool has zero parameters, and the schema coverage is trivially 100%. Per rubric, 0 parameters yields a baseline score of 4. The description adds no parameter details, but none are needed.

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 description clearly states 'Fetch current SOL/USD price' with a specific verb ('Fetch') and resource ('SOL/USD price'), distinguishing it from sibling tools like get_token_info or get_pool_liquidity. The purpose is unambiguous and directly maps to the tool's name.

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 context for when to use this tool is obvious: whenever the user needs the current SOL/USD price. Since the tool has no parameters and a unique niche among siblings, no exclusions or alternatives are necessary. It is implicitly clear, though not explicitly expressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_token_holdersA

Fetch top holders for a PumpFun token including concentration metrics

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Token mint address

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. The verb 'Fetch' implies a read-only operation, and it adds that concentration metrics are included, but it does not disclose any other behaviors such as rate limits, data volume, or potential errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action, and contains no unnecessary words. It is perfectly concise for the tool's simplicity.

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

Completeness4/5

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

The tool has one parameter and no output schema. The description provides a sufficient overview of the output (top holders with concentration metrics), though it could specify more details like the number of holders or format of metrics, but this is adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the 'mint' parameter with a sufficient description ('Token mint address'), and the tool description does not add any extra meaning beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.

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 description clearly states the tool fetches top holders for a PumpFun token and includes concentration metrics, which distinguishes it from sibling tools like get_token_info or get_token_trades.

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 provides context that this is for top holder concentration analysis, but it does not explicitly mention alternatives or when not to use it. However, the purpose is clear enough that an agent would know when to choose this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_token_infoA

Fetch PumpFun token metadata, market cap, bonding curve progress, and flags

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Token mint address

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates a fetch/read operation and lists the returned data categories, but does not disclose potential behaviors such as whether the token must exist, how invalid addresses are handled, or whether data is cached. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence that lists the resource and returned data categories. There is no filler, repetition, or unnecessary detail, making it easy for an agent to parse quickly.

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

Completeness4/5

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

For a simple one-parameter metadata-fetch tool with no output schema, the description sufficiently covers what the tool returns. It could mention that the input must be a PumpFun token and could clarify what 'flags' means, but the overall context is adequate for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% because the only parameter 'mint' is described as 'Token mint address'. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.

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 description uses a specific verb ('Fetch') and identifies the exact resource (PumpFun token metadata) plus the specific data categories returned (market cap, bonding curve progress, flags). This clearly differentiates from sibling tools like get_token_holders, get_token_trades, and get_pool_liquidity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when you need token metadata, market cap, bonding curve progress, or flags. However, it does not explicitly state when not to use it or point to alternative sibling tools for different data needs, so the guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_token_tradesA

Fetch recent trade activity for a PumpFun token (volume, buy/sell counts)

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Token mint address

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'recent' trade activity, but does not define the time window (e.g., last 24h, last hour, etc.) or any behavior like pagination, rate limits, or whether this is a read-only operation. It does not disclose how the counts are aggregated (e.g., on-chain vs. API-source) or whether it includes wash trading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the main purpose, and every word adds value. No unnecessary details. Perfectly concise.

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

Completeness3/5

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

The tool is simple (one parameter, no nested objects, no output schema), so the bare description may be sufficient for an agent to know what it returns (volume, buy/sell counts). However, without annotations, more context on the 'recent' window or return format would increase completeness. Still, given its simplicity, it doesn't require extensive documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – the only parameter 'mint' is described as 'Token mint address', which is sufficient. The description adds context that the param is for a PumpFun token, but since the schema already covers the parameter adequately, the baseline 3 is appropriate.

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 description states a specific verb ('Fetch') and a specific resource ('recent trade activity for a PumpFun token') and mentions the key outputs (volume, buy/sell counts). It clearly distinguishes from siblings like get_token_info or get_token_holders by focusing strictly on trade activity (volume, buy/sell counts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for trade monitoring, but it doesn't explicitly state when to use it vs alternatives (e.g., when tracking volume changes vs. holding distribution). No exclusions or alternatives are named, but in the context of sibling tools like get_token_holders or get_pool_liquidity, the purpose is clear enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv1.0.4Aug 21, 2026
- First observedget_bundle_info
- First observedget_claim_history
- First observedget_creator_profile
- First observedget_github_user
- First observedget_pool_liquidity
- First observedget_sol_price
- First observedget_token_holders
- First observedget_token_info
- First observedget_token_trades

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct data resource: token info, holders, trades, liquidity, bundle status, creator profile, GitHub user, claim history, and SOL price. There is no meaningful overlap or ambiguity between tool purposes.

Naming Consistency5/5

All tools follow a consistent get_<noun> pattern with snake_case, making the read-only nature and target resource immediately clear. No mixed conventions or vague verb variations exist.

Tool Count5/5

Nine tools is a well-scoped size for a claims-verification bot. Each tool covers a distinct piece of the investigation workflow without unnecessary redundancy or bloat.

Completeness4/5

The toolkit covers token intelligence, holder analysis, liquidity, scam signals, creator background, GitHub identity, claim history, and SOL pricing—strong coverage for pre-claim due diligence. However, there is no active claim or eligibility-check action, which leaves a minor gap if the bot is expected to execute claims directly.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CYRE Guardian
io.github.milesdev888
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Blockchain Cryptocurrency Security
1
solenrich A
io.github.0xSardius
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
Blockchain Cryptocurrency Finance
3622
DeFade — Multi-Chain Memecoin Analyzer A
org.defade
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Blockchain Cryptocurrency Web3 & Decentralized Tech
151
Noesis — Solana On-Chain Intelligence A
io.github.Rengon0x
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Blockchain Web3 & Decentralized Tech Cryptocurrency
21

Related MCP Servers

memecoin-radar-mcp
Cryptocurrency Web3 & Decentralized Tech Blockchain
kukapay
A
license
A
quality
D
maintenance
Real-time radar for Solana memecoins, Pump.fun launches, and KOL trades.
Updated a year ago (2025-06-15 02:39 UTC)
8
2
MIT
NoesisAPI
Blockchain Web3 & Decentralized Tech Finance
Rengon0x
A
license
Not graded
quality
D
maintenance
Solana on-chain intelligence API — token scans, wallet PnL, bundle detection, fresh wallets, dev profiling. MCP server for Claude, Cursor & AI agents. Live PumpFun/Raydium streams
Updated 4 months ago (2026-05-18 14:26 UTC)
1
MIT
Pique Signalofficial
Cryptocurrency Finance
piquesignal
A
license
A
quality
C
maintenance
Live scored Solana memecoin signals with safety profiles, conviction scoring, and paper trading for AI agents.
Updated 4 months ago (2026-05-14 20:03 UTC)
6
MIT
solana-agent-mcp
Blockchain Cryptocurrency
KorroAi
F
license
B
quality
C
maintenance
Real-time Solana pump.fun token scanner with MCP stdio transport and HTTP API. Enables AI agents to monitor and trade pump.fun tokens via natural language.
Updated 2 months ago (2026-07-06 16:27 UTC)
8
3
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nirholas/pumpfun-claims-bot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

PumpFun Claims Bot

Features

Feed Types

Claim Intelligence

Graduation Cards

Influencer Tier System

Credibility Score & Dev Track Record

AI-Powered Claim Summaries

Architecture

Multi-RPC Failover

Programs Monitored

Install

npm (MCP server — recommended for AI assistants)

From source (full bot + Telegram feed)

Quick Start

1. Create a Telegram Bot

2. Configure Environment

Environment Variables Reference

3. Run

4. Deploy with Docker

5. Deploy to Railway

Project Structure

How It Works

Claim Detection Pipeline

SocialFeeIndex Bootstrap

Fake Claim Detection

First-Claim Tracking

Three-Layer First-Claim Verification

Example Claim Card

Requirements

Troubleshooting

Bot Not Posting Messages

Rate Limiting

RPC Connection Issues

Missing Claims

Pipeline Stats

Web Dashboard

Pages

Dashboard Features

Tech Stack

MCP Server

MCP Tools

Usage: Stdio Transport (Claude Desktop / Cursor / VS Code)

Usage: Streamable HTTP Transport (Embedded)

Example Queries

Health Check API

Testing

Test Suites

Local Development

Tech Stack

Contributing

Security

License

Documentation

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Pique Signalofficial

Latest Blog Posts

MCP directory API