DEV Community: Weston G

Paste a wallet, get a personal airdrop verdict — and call the same logic from any LLM

Weston G — Mon, 11 May 2026 20:06:05 +0000

Paste a wallet, get a personal airdrop verdict — and call the same logic from any LLM

Two surfaces, one rule registry: a browser tool and an MCP tool that share the exact same 14 hand-verified on-chain rules and return the exact same verdict shape.

The problem

Airdrop directories are full of "you might be eligible for 312 airdrops!" claims. They match on chain ("you've used Ethereum → you qualify for every Ethereum airdrop"), which is useless. The real eligibility lives on each project's contract or off-chain criteria.

So I built a tool that does the opposite: a tiny number of hand-verified rules, each tied to a specific entry, evaluated against the wallet you paste. No signature, no signup, no server-side address logging — just RPC calls fanned out from the browser. And because the same rule registry feeds an MCP tool, any LLM client (Claude Desktop, Cursor, etc.) can call it directly without scraping the site.

The browser tool

Live at web3-discover.vercel.app/tools/eligibility.

Paste an EVM and/or Solana address. The page evaluates 14 rules against 42 curated entries and buckets the results into:

✅ Likely eligible — rule passes (e.g. eth_getTransactionCount on Linea ≥ 1, or you hold ≥ 1 PENDLE)
🟡 Keep farming — partial: you've started but not crossed the threshold (e.g. 2 Arbitrum tx when 5 are needed for Reya / Ostium)
⏭ Not relevant — rule fails outright
🔍 Manual check — entry lives on a chain we can't reach from the browser (Monad, MegaETH, Hyperliquid, Sui-based) or has off-chain criteria (KYC, Discord, Galxe quests)

Try vitalik.eth + a public Solana wallet — resolves in 2-5 seconds, 9 eligible at the time of writing.

How the browser side stays cheap

Every entry-page CTA deep-links to /tools/eligibility?focus=<slug>. A banner at the top of the results page names the entry the visitor came from, then after evaluation the matching card is scrolled into view and pulse-highlighted with a CSS keyframe. This costs zero extra requests — the focus logic is pure DOM-after-render.

Total RPC requests = one batched JSON-RPC POST per EVM chain (so 6 max for an EVM address) plus per-mint Solana calls. Each batch bundles eth_getTransactionCount + every eth_call(balanceOf) we need for that chain, so adding more rules on Ethereum costs zero additional requests.

The MCP tool

Same logic, exposed at https://web3-discover.vercel.app/api/mcp as the fourth tool of the web3-discover MCP server.

curl -s -X POST https://web3-discover.vercel.app/api/mcp \
  -H 'content-type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 7,
    "method": "tools/call",
    "params": {
      "name": "check_eligibility",
      "arguments": { "evm": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" }
    }
  }'

Returns the same verdict shape — eligible[], partial[], manual[], unavailable[], skip[] — but as machine-readable JSON each LLM client can render however it likes:

{
  "inputs": { "evm": "0xd8dA…6045", "sol": null },
  "rulesEvaluated": 14,
  "totalTracked": 42,
  "counts": {
    "eligible": 9,
    "partial": 0,
    "skip": 5,
    "manual": 28,
    "unavailable": 0
  },
  "eligible": [
    {
      "slug": "base-coinbase-l2",
      "project": "Base",
      "chain": "Base (Coinbase L2)",
      "verdictDetail": "70 tx on Base (≥ 1 required)",
      "officialUrl": "https://base.org"
    }
  ]
}

Drop-in for Claude Desktop / Cursor

{
  "mcpServers": {
    "web3-discover": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://web3-discover.vercel.app/api/mcp"]
    }
  }
}

Then ask: "What airdrops am I eligible for? My wallet is 0x…" and the model calls check_eligibility directly. No scraping, no flaky HTML parsing.

The one-file pattern that keeps both surfaces honest

Two surfaces means two ways for the rules to drift. The fix is one source of truth:

src/data/
  eligibility-rules.json   # source of truth
  eligibility-rules.ts     # typed wrapper for the Astro page

And during prebuild:

// scripts/build-airdrops-snapshot.mjs
fs.copyFileSync(
  path.join(ROOT, 'src/data/eligibility-rules.json'),
  path.join(ROOT, 'api/_eligibility-rules.json'),
);

The MCP serverless function reads the JSON at cold start; the Astro page imports the typed .ts wrapper. Same data, two consumers, zero drift.

Why this matters as a wedge

Most directory sites optimise for "discover something new". This optimises for the moment after you've already heard of a project: "do I, this wallet I'm holding, actually need to act on this?" That question doesn't compete with newsletters or Twitter — it complements them.

And exposing the same logic over MCP means the directory gets pulled into LLM chats as the user is making decisions, not after the fact. The two surfaces feed each other: the browser tool drives organic / shared discovery; the MCP tool drives in-chat utility when a user has Claude open anyway.

Try it

Browser: web3-discover.vercel.app/tools/eligibility
MCP: https://web3-discover.vercel.app/api/mcp — JSON-RPC 2.0, tools/list returns four tools
Source: the curated entries themselves live in a separate CC0 repo at SolvoHQ/web3-discover-data, auto-refreshed daily

Open to pull requests adding new rules — each one is ~5 lines in the JSON registry.

I shipped an MCP server for crypto airdrops — install in 1 config line

Weston G — Mon, 11 May 2026 14:13:59 +0000

I shipped a tiny MCP server last week that turns a curated crypto airdrop directory into 3 tools any LLM client (Claude Desktop, Cursor, Continue, Windsurf) can call directly.

This post is the install snippet + a screenshot of it returning real data — so you can decide in 30 seconds whether it's worth one config line.

What you get

Three tools, no signup, no API key, no rate limit:

list_active_airdrops(chain?, risk?, sort_by?, limit?) — browse 32 vetted active airdrops, filter by chain (Solana, Base, Ethereum…) or risk level (verified / unverified)
get_airdrop(slug) — full details for one campaign: action steps, weekly effort, cost floor, risk notes, official URL
check_wallet(addr) — paste an EVM or Solana address, fan out to 7 public RPCs (Ethereum, Base, Linea, Arbitrum, Polygon, BSC, Solana), and surface every tracked airdrop whose chain you've already touched

Hosted, JSON-RPC 2.0 over HTTP, CORS-open. Endpoint: https://web3-discover.vercel.app/api/mcp.

Install in Claude Desktop or Cursor

Add this one block to your MCP config:

{
  "mcpServers": {
    "web3-discover": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://web3-discover.vercel.app/api/mcp"]
    }
  }
}

That's it. Restart your client. Ask: "What active airdrops can I farm on Solana this week with under $100 capital?"

What it returns (live)

Here's the actual JSON-RPC 2.0 response from a real tools/call against the live endpoint — pulled the moment I wrote this article:

Verify it yourself:

curl -s -X POST https://web3-discover.vercel.app/api/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_active_airdrops","arguments":{"limit":3,"sort_by":"added"}}}'

You get back structured entries: slug, project, chain, blurb, deadline, effort estimate, cost floor, risk flag (verified means the team has publicly confirmed TGE plans; unverified means speculative), and the official URL.

Why this is interesting (beyond "another MCP server")

I run a curated airdrop directory at web3-discover.vercel.app. Every entry is hand-vetted, scam-filtered, and re-checked weekly. The web surface works well for humans who already know about it — but most retail farmers ask LLMs first now.

So I exposed the directory as MCP tools. Three things this unlocks that the web UI alone can't:

Natural-language filtering. "What's verified-only, ongoing, costs gas only?" — the LLM picks list_active_airdrops, filters by risk=verified, sorts by deadline, narrates the result.
Wallet-aware advice. check_wallet returns which chains your wallet has touched plus the entries on those chains. The LLM combines that with your stated risk tolerance and tells you what to prioritize, not just what exists.
Composition with other MCP servers. If you've got a wallet MCP server + this one, the LLM can chain "what airdrops am I close to qualifying for, given my actual on-chain history?"

No tracking. The directory has no signup. The check_wallet tool just reads from public RPCs — no address is logged.

Why hosted, not stdio?

Most MCP servers ship as npx some-package that runs on your machine. I went hosted (HTTP transport via mcp-remote bridge) for one reason: the data changes weekly. A stdio package would have to re-download the directory or hit an API anyway. Hosting it means the data refreshes when I do a freshness sweep, not when you remember to npm update.

Tradeoff: you trust me to keep the endpoint up. I run a freshness sweep weekly (the directory page shows a "last verified" date per entry). If you'd rather self-host, the source is MIT and the MCP handler is a single ~250-line file (api/mcp.mjs).

What works, what doesn't, what's next

Works today:

All 3 tools verified end-to-end on Claude Desktop and Cursor with mcp-remote
32 active entries, 7-chain wallet check
No auth, no rate limit at current load

Doesn't yet:

No eligibility scoring — check_wallet is a presence check, not an "are you actually eligible?" check. Most airdrops have additional criteria (volume, tx count, NFT holdings) that I'd need to wire per-entry.
No notifications — if a deadline shifts or an entry gets removed, you'll only see it next time you query.

Next:

subscribe_deadlines(addr) returning an iCalendar feed so deadlines land in your calendar
Per-entry eligibility checks where the airdrop has a public scoring API
Adding the directory as an MCP resource (not just tools) so LLMs can browse without explicit calls

Try it

Drop the config block above into Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS) or Cursor (Settings → MCP). Ask "What airdrops are worth farming this week?"

If it's useful, the directory itself lives at web3-discover.vercel.app — same data, human-shaped.

If something breaks or you want a tool added, open an issue.

Built with Astro + Vercel serverless. Three days, ~250 LOC for the MCP handler. The hardest part wasn't the code — it was making sure the underlying directory data was actually honest. (No paid placements pretending to be listings.)

Building a daily-refreshed, scam-flagged airdrop directory with Astro + IndexNow + GoatCounter

Weston G — Mon, 11 May 2026 12:57:42 +0000

I've been building web3-discover — a hand-vetted, scam-flagged directory of currently-claimable web3 airdrops — and I wanted to share the static-site + agent-driven pipeline behind it, because the architecture is unusual: there's no backend, no database, no editor login. Everything is git-tracked Markdown, every deploy is a static build, and content is refreshed daily by an autonomous workflow rather than human curators.

Live URL: https://web3-discover.vercel.app

The wedge (why "fewer entries" is the feature)

The crypto-airdrop site space is dominated by SEO-juiced aggregators listing 300+ "airdrops" — most of which are expired, scams, or paid placements pretending to be listings. The wedge is the opposite: ~30 hand-vetted entries, each with a concrete action, cost floor, deadline, risk flag, and a lastChecked date. If we can't verify an entry, we drop it.

The stack (and why each piece)

Astro 5 — chosen specifically because content collections give you a typed schema for markdown frontmatter, and the output is dead-static HTML. No client JS in the critical path. Every entry page is a 9KB document.

// src/content/config.ts
const airdrops = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    chain: z.enum(['Ethereum', 'Solana', 'Base', 'Arbitrum', /* ... */]),
    action: z.string(),
    costFloor: z.string(),     // "$0", "$50", "gas-only"
    deadline: z.string(),      // ISO date or "ongoing"
    riskFlag: z.enum(['verified', 'unverified', 'suspected-scam']),
    lastChecked: z.string(),
    officialUrl: z.string().url(),
    addedOn: z.string(),
  })
});

When an entry breaks schema, the build fails loudly. That's the whole content-CI layer — no DB migrations to run.

Vercel for hosting — vercel --prod from CLI. Free tier handles plenty of traffic. Sitemap pinned to @astrojs/sitemap@3.2.1 because newer versions broke our Astro 5 build chain.

JSON-LD for structured data — Organization + WebSite on every page (in Base.astro layout), ItemList on the airdrops index page, Article schema on each entry page (with datePublished from frontmatter addedOn, publisher logo, mainEntityOfPage, dateModified sourced from lastChecked). Verified live via curl — the JSON parses cleanly with python3 -m json.tool.

RSS at /rss.xml using @astrojs/rss. Each item carries the full action/effort/cost/deadline/risk block — readable in a feed reader without clicking through. GUIDs are entry URLs (canonical).

IndexNow for crawler push notifications — three endpoints pinged on every content update:

https://api.indexnow.org/indexnow → 202
https://www.bing.com/indexnow → 200
https://yandex.com/indexnow → 202 ({"success":true})

The verification key is a file at https://web3-discover.vercel.app/<hex>.txt. Don't delete that file — Bing re-validates on subsequent pings. I learned that the hard way trying to "clean up" the public dir.

GoatCounter for analytics. Privacy-friendly, no cookies, no consent banner needed. Embed is a 5-line <script>. The dashboard lives at <workspace>.goatcounter.com. Counts pageviews + referrers, exactly what I need to see whether a distribution channel actually works.

The agent-refresh loop (the unusual part)

The site is maintained by an autonomous workflow (Claude Code agent ticks running on a 30-second heartbeat). Every wake the agent reads the current Markdown entries, checks lastChecked against Date.now() - 7d, and queues stale entries for re-verification:

Fetch the project's official Twitter or docs page.
Re-confirm the deadline string.
Re-confirm the action steps still match what the project requires.
If anything has changed: update the frontmatter, bump lastChecked.
If the project has TGE'd (token generation event passed) or the airdrop is over: remove the entry from src/content/airdrops/ entirely.
Re-build, redeploy, ping IndexNow.

In the first sweep (22 → 32 entries) the agent caught three of my own false assumptions: Monad / MegaETH / Plasma are post-TGE, not pre-TGE. Sonic Labs Season 2 ended November 2025 — dropped. The point isn't that the agent is smarter than me; it's that running the verification loop on a 7-day cycle instead of "when I feel like it" surfaces drift fast.

Per-entry conversion pivot (a real lesson)

Initial v1 had a /tools/swap page with Jupiter Plugin (Solana) and Jumper deeplink (EVM) as a monetization path — integrator-fees on swaps. Every airdrop entry page had a "Sell when claimed" CTA pointing at /tools/swap?token=X&chain=Y.

The bug: the URL params were read by NO code. Every sell-CTA from 32 entry pages dumped users on a USDC-default swap. The single biggest pre-traffic conversion gap, sitting in production for ~24 hours before I caught it.

Fix: a slug→target registry mapping each entry's chain + symbol to a concrete token address. For Solana, that's the SPL mint passed into Jupiter.formProps.initialInputMint. For EVM, ?fromChain=…&fromToken=… on the Jumper deeplink. 12 verified Solana mints + 20 EVM token addresses are now hardcoded into a TypeScript const. Building this took ~25 minutes. The fact that an agent let it ship undetected for 24h is the cautionary tale — verification-before-completion is non-negotiable when your reviewer-of-last-resort is the same process that shipped the change.

Guides pillar (SEO + risk-awareness)

Three evergreen guides live at /guides/scams, /guides/taxes, /guides/wallet-hygiene. Every airdrop entry internally links to two risk-matched guides (a suspected-scam entry links to /guides/scams; a high-deadline entry links to /guides/wallet-hygiene). Indexable surface went from 35 to 39 URLs, every entry page gains internal-link equity.

The choice was deliberate: I'd rather have 3 deep guides than 30 shallow ones. Crawlers reward dwell time, and a 1500-word scams guide with concrete patterns ("if the claim URL doesn't match the project's official Twitter pinned tweet, walk away") does that better than 30x 200-word listicles.

What I'd tell anyone building in this category

Anti-features are the differentiation. "No wallet connect, no claim links, no paid listings" is not a copy gimmick — it's the reason I trust my own site, and it's the reason a user might. The competitive moat in any junk-flooded category is being the one that says "no" to the easy money.
Static + agent-refresh > headless CMS. A headless CMS gives editors a UI. I don't have editors. The git tree is the database; the deploy is the publish step; the agent is the editor. If your contributor list is 1, this collapses to dramatically less infra than "Strapi + Postgres + worker queue".
JSON-LD is free SEO money. Article schema with dateModified sourced from lastChecked tells Google "this is a fresh page". Cost: 12 lines per layout file. Benefit: every entry shows the freshness signal in SERPs.
IndexNow ≠ Google Search Console. GSC verification is an interactive OAuth flow with no zero-account path I could find. IndexNow accepts a static key file and gets you Bing + Yandex (the latter is non-trivial for crypto SEO, where Russian and Eastern European traffic is real). Don't burn hours on GSC; ship IndexNow and move on.

Try it

Site: https://web3-discover.vercel.app — currently 32 active entries, deadline-sorted, refreshed today.

If you spot an entry that's wrong, broken, or scammy I should flag harder — open an issue at the repo (linked in the footer). The whole content tree is public Markdown — feedback round-trips fast.

Tags: #astro, #web3, #staticsite, #seo, #crypto