mcpField
S
Scout Packs

Scout Packs

Remote
github.com/tigerops-winBusiness & Marketing0Updated 2w ago
Repository

About Scout Packs

Scout Packs provides verified B2B lead packs and per-lead enrichment to AI agents through x402 payments in USDC on Base. Its MCP server lets agents browse packs and retrieve payment terms without handling wallet keys or funds.

Key features

  1. 01Browse pack sizes, prices, and sales status
  2. 02Purchase lead packs using x402 payment terms
  3. 03Look up verified business email and provenance
  4. 04Retrieve composite domain intelligence dossiers
  5. 05Free redacted pack previews

Use cases

  1. 01Find verified business contact emails for a company
  2. 02Buy and download a lead pack through an agent
  3. 03Gather domain, technology, email-pattern, and SSL signals

MCP support

The MCP server exposes `list_packs` for pack details and previews, and `buy_pack` for x402 payment terms and purchase steps. The buying agent's wallet pays the endpoint; the server does not handle funds or keys.

Configuration

Remote servers need no local install. Pick your client, then copy the config or install in one click.

Endpointhttps://scout-packs-production.up.railway.app/mcp
Copy install command
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

Run commands in a terminal; paste JSON into the client’s MCP config and restart. Servers that need sign-in will prompt on first connect.

Tools

16

This tool takes no parameters.

Details

From the project README

Scout Packs — Tiger Operations

Verified B2B lead packs and per-lead enrichment lookups sold to AI agents over x402 (USDC on Base, eip155:8453). Demand-probe pricing (2026-10-04): $0.01 per lookup or pack. Margin inversion vs. Scout COGS is acknowledged — this is a demand probe, not a business model. Kill gate: ≥3 paid lookups from ≥2 distinct wallets in 7 days post-reprice.

PackLeadsPriceFulfillment
scout-pack-2525$0.01instant JSON download after payment
scout-pack-5050$0.01assembled on demand, delivered within 24h
scout-pack-100100$0.01assembled on demand, delivered within 24h

Per-lead enrichment: GET /lookup?query=<company or domain> — 402 paywall, $0.01 USDC, POST /fulfill-lookup returns one verified business email + source URL + provenance.

Composite dossier: GET /dossier?domain=<domain> — 402 paywall, $0.05 USDC, POST /fulfill-dossier returns a composite domain dossier: RDAP registration + DNS infrastructure signals, tech-stack detection, likely corporate email patterns + MX verification, and SSL/TLS certificate health for one domain, fused into a single response with an aggregated signals list — the /domain-intel, /tech-stack, /email-pattern, and /ssl-check results in one call instead of four separate calls.

Each lead: company_name, city_state, category, contact_email (verified business email), source_url.

Endpoints

  • GET / — human landing page
  • GET /catalog — packs & prices (JSON)
  • GET /.well-known/x402 — machine-readable payment terms
  • GET /llms.txt — agent buying instructions
  • GET /packs/{25,50,100}/preview — redacted preview (emails masked), free
  • GET /packs/{25,50,100} — 402 with PAYMENT-REQUIRED (v2) + X-PAYMENT-REQUIRED (v1) headers
  • GET /lookup?query=<company or domain> — 402 with payment terms ($0.01 USDC); no match → 404
  • POST /fulfill — {"tx_hash":"0x...","pack":"25","deliver_to":"..."}
  • POST /fulfill-lookup — {"tx_hash":"0x...","query":"<company>"}
  • GET /dossier?domain=<domain> — 402 with payment terms ($0.05 USDC); composite domain dossier: domain intel + tech stack + email patterns + SSL check fused into one call
  • POST /fulfill-dossier — {"tx_hash":"0x...","domain":"<domain>"}
  • GET /skill.md — agent skill file for the lead lookup (markdown)
  • /mcp — MCP streamable-HTTP endpoint (proxied to the sibling MCP server when MCP_PROXY_PORT is set)

Interface reference (for agent/MCP clients)

GET /packs/{25,50,100} → 402 Payment Required

  • Headers: PAYMENT-REQUIRED = base64(JSON x402 v2 terms), X-PAYMENT-REQUIRED = base64(JSON x402 v1 terms)
  • Body: {error:"payment_required", pack, leads, price_usd, currency:"USDC", network:"eip155:8453", fulfillment, sales_enabled, x402:{x402Version:2, accepts:[{scheme:"exact", network, amount (atomic USDC, 6 decimals), description, mimeType, payTo, maxTimeoutSeconds, asset, extra}], resource:{url, description, mimeType}}, how_to_pay:[...]}
  • sales_enabled:false while the seller address is unconfigured (current state); flips automatically once set.

POST /fulfill — body {tx_hash:"0x…", pack:"25"|"50"|"100", deliver_to:"…" (optional)}

  • Success, pack 25 → 200 {receipt:"ok", pack:"scout-pack-25", tx_hash, verified_at, leads:{…25-lead pack JSON…}}
  • Success, pack 50/100 → 200 {receipt:"ok", pack, tx_hash, verified_at, order_id, status:"queued_for_assembly", eta:"within 24 hours of payment confirmation", deliver_to, note}
  • Failure → 402 {error:"payment_not_verified", detail:"sales_paused: receiving address not configured" | "bad_tx_hash" | "already_redeemed" | "tx_not_found" | "tx_not_successful" | "tx_too_old" | "no_matching_usdc_transfer" | "chain_lookup_failed", pay:[…steps…]} or 400 {error:"unknown_pack"|"bad_json"}

Verification rules: tx must be a successful Base USDC transfer of ≥ the pack amount to the configured receiving address, mined <30 days ago, and each tx hash is single-use.

Buying flow

  1. GET /packs/25 → read the 402 terms (payTo, exact USDC amount).
  2. Standard x402: sign an EIP-3009 authorization for exactly $0.01 USDC on Base to payTo and retry the same request with the signature in the X-PAYMENT (v1) or PAYMENT-SIGNATURE (v2) header. The payment is verified + settled via facilitator and pack 25 is returned immediately (50/100 return a 24h order receipt).
  3. Fallback: send exactly $0.01 USDC on Base to payTo yourself, then POST /fulfill with the tx hash.

Payment is verified on-chain (Blockscout free API): the tx must be a successful USDC transfer of ≥ the pack amount to the receiving address. Tx hashes are single-use (replay-protected); txs older than 30 days are rejected.

Config

  • SCOUTPACKS_RECEIVING_ADDRESS — the Base address that receives USDC. While unset (or the zero address) the endpoint runs in preview-only mode: sales_enabled=false in 402 bodies and /.well-known/x402, and /fulfill refuses all requests.
  • SCOUTPACKS_PUBLIC_BASE — public URL used in 402 resource fields.
  • PORT — default 8000.
  • MCP_PROXY_PORT — optional (e.g. 8001); when set, /mcp reverse-proxies to the sibling MCP streamable-HTTP server (mcp/http_server.py) on that port — one deploy exposes both the x402 API and a durable-HTTPS MCP endpoint.

Deploy

./run.sh &                                   # localhost:8000

Production (since 2026-10-02) runs on Railway — https://scout-packs-production.up.railway.app is the sole production endpoint. The old localtunnel path (lt-proxy.js, loca.lt subdomains) is dead legacy, retired 2026-10-02 after chronic 503s. On normal infra for a fresh deploy, cloudflared tunnel --url http://127.0.0.1:8000 works as usual.

Then register on the open indexes, e.g. 402 Index: POST https://402index.io/api/v1/register with {url, name, protocol:"x402", description, price_usd, payment_asset:"USDC", payment_network:"eip155:8453", category:"data", tags:[...]}.

MCP server (for agent clients)

AI agents can also discover and buy packs from inside MCP clients (Claude Desktop, Cursor, MCP Inspector, agent frameworks) via the MCP server in mcp/:

  • list_packs — free. Pack sizes, prices, live sales status, redacted sample.
  • buy_pack — returns the exact x402 payment terms and the step-by-step flow; the buying agent's own wallet pays the endpoint. Never moves funds, never holds keys.

Quick start (Python 3.10+, installs the mcp SDK only):

cd mcp && python3 -m venv .venv && .venv/bin/pip install mcp
BASE_URL=https://<endpoint-url> .venv/bin/python scout_packs_mcp.py

Or once published to PyPI: uvx scout-packs-mcp with BASE_URL set. Full docs: mcp/README.md. Registry listings: mcp/REGISTRIES.md.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.