Skip to main content
Glama
tigerops-win

scout-packs-mcp

by tigerops-win
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

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.

Pack

Leads

Price

Fulfillment

scout-pack-25

25

$0.01

instant JSON download after payment

scout-pack-50

50

$0.01

assembled on demand, delivered within 24h

scout-pack-100

100

$0.01

assembled 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.

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 /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)

Related MCP server: Agent Commerce Gateway

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.

Available Tools

3 tools
buy_packAInspect

Get the exact x402 payment requirements and step-by-step buying flow for a Scout Pack. pack: "25", "50", or "100". Returns what the buying agent must do; the agent's own wallet executes the USDC payment against the endpoint.

ParametersJSON Schema
NameRequiredDescriptionDefault
packYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/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 clearly discloses the key behavioral trait: it returns payment requirements and flow, and the agent's own wallet executes the USDC payment against the endpoint. It does not mention auth, rate limits, or whether the call itself is read-only, but the non-execution behavior is well covered.

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?

Three tightly written sentences. Purpose is front-loaded, followed by parameter values and return behavior. No filler or repetition.

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 one required parameter, an existing output schema, and no annotations, the description covers purpose, parameter values, and the critical non-execution behavior. It omits routing to alternatives such as list_packs and any prerequisites, but the core information is sufficient for an agent to call it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, and the only parameter 'pack' is undocumented in the schema. The description compensates by stating 'pack: "25", "50", or "100"', providing the exact allowed values. This is strong added value beyond the schema.

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?

States a specific verb 'Get' and resource 'x402 payment requirements and step-by-step buying flow for a Scout Pack.' It distinguishes itself from list_packs by focusing on the buying flow rather than listing available packs.

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 when-to-use or when-not-to-use guidance. It does not mention list_packs or lookup_lead as alternatives, nor does it state prerequisites. Usage is only implied by the tool name and stated purpose.

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

list_packsAInspect

List Scout Packs for sale: sizes, prices, and a redacted sample. Free.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It usefully discloses that the sample is redacted and the call is free, which is real behavioral context for a no-param read tool, but it says nothing about pagination, auth, or result volume.

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?

A single tight sentence with the verb and resource front-loaded, followed by a short 'Free.' fragment that does earn its place as a cost signal, though the fragment style is slightly clipped.

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 zero-parameter read-only listing with an output schema that carries return values, the description covers what the agent needs to select and call it; only sibling routing and pagination behavior are absent.

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 takes zero parameters, so the baseline is 4 and there is no schema-level parameter meaning the description could be expected to supplement.

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?

States a specific verb ('List') and resource ('Scout Packs for sale') plus the fields returned (sizes, prices, redacted sample). It is clearly distinguishable from buy_pack as a browse rather than purchase operation, though it does not name that sibling explicitly.

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?

Usage is implied: the 'Free' note signals zero-cost browsing that logically precedes buy_pack, but the description never states when to use this versus buy_pack or lookup_lead, nor any prerequisites.

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

lookup_leadAInspect

Look up one verified B2B contact by company name or domain. $0.10 USDC per lookup. Returns the x402 payment requirements; your agent's wallet executes the payment. Example: lookup_lead(query="Acme Corp") or lookup_lead(query="acme.com")

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the $0.10 USDC per-lookup cost and explains that the call returns x402 payment requirements which the agent's wallet must satisfy. That payment-gating behavior is essential and non-obvious. It omits error/rate-limit behavior, which keeps it from a 5.

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?

Three short sentences, front-loaded with purpose, then cost/payment mechanics, then examples. Every sentence adds information, though the two example forms slightly overlap with the preceding sentence's description of accepted input.

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?

An output schema exists, so return-value detail is not required. Combined with the stated cost and payment flow, the definition gives an agent everything needed to invoke it correctly; only edge-case behavior (no match found, payment failure) is unaddressed.

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?

Schema coverage is 0% and the single 'query' parameter has no description, so the description must compensate. It explicitly states the accepted values (company name or domain) and gives two worked examples ('Acme Corp', 'acme.com'), which is enough to construct a valid call.

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?

States a specific verb and resource ('Look up one verified B2B contact') plus the accepted key types ('by company name or domain'), so the agent knows exactly what it retrieves. It doesn't explicitly position itself against its siblings (list_packs, buy_pack), but their pack-oriented framing makes the distinction reasonably inferable.

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?

Two concrete example invocations show expected input shape, which implies intended usage, and the pricing line signals this is a paid, single-record lookup rather than a bulk operation. However, it never states when to use this versus the sibling pack tools or any preconditions/exclusions.

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.

  1. 3 tool updatesv1.0.0
    • First observedbuy_pack
    • First observedlist_packs
    • First observedlookup_lead
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list_packs browses inventory, buy_pack initiates a pack purchase, and lookup_lead performs a separate B2B contact lookup. There is no overlap in action or resource that would cause misselection.

Naming Consistency5/5

All three tools follow a consistent snake_case verb_noun pattern: list_packs, buy_pack, lookup_lead. The convention is predictable and readable throughout.

Tool Count4/5

Three tools is on the lower end but plausible for a narrow commerce-and-lookup server. It covers the advertised flows without bloat, though slightly more (e.g., a status or retrieval tool) could be expected.

Completeness3/5

The surface covers browsing, buying, and a single lead lookup, but lacks post-purchase retrieval or payment confirmation, and lead lookup only supports one query at a time. These gaps may force agents to rely on external endpoints or repeated calls.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers