Product Hunt MCP Server

Product Hunt

Product Hunt is the public registry of new product and tech launches: daily/weekly/monthly rankings, vote totals, review scores, comment threads, collections, and topic taxonomy.

Data model and hierarchy

• Post — one launch. Carries name, tagline, description, votesCount, commentsCount, reviewsCount, reviewsRating, dailyRank, weeklyRank, website, productLinks (Website/Twitter/LinkedIn/GitHub/Instagram), topics, and the redirect URL fields.
• Topic — taxonomy node a post is tagged with (artificial-intelligence, developer-tools, productivity, open-source, ...). A post has many topics; a topic has many posts.
• Collection — editorial / community-curated bundle of posts grouped by theme. Independent of topics.
• Comment — discussion thread on a post; maker replies live in the same thread.
• User / viewer — viewer returns the authenticated account. Maker, hunter, and voter profile fields on posts and topics are redacted by the upstream API.

Operational order

1. Resolve identity first when you have one. A domain → reverse lookup on the post listing by url=https://<domain>. A Twitter/X handle → reverse lookup by twitterUrl=https://x.com/<handle>. These short-circuit the whole pagination problem and are the canonical first step for company/founder research.
2. Narrow before listing. Newest-first over the whole firehose is almost never the right shape. Pick one filter axis (topic slug, postedAfter/postedBefore ISO 8601 window, featured=true) before walking pages.
3. Page linearly, single-threaded. Walk edges until pageInfo.hasNextPage is false, carrying the endCursor in after. Parallel fan-out drains the complexity budget (see below) for no extra coverage.
4. Filter on the edges you already have. Each list edge already carries name, tagline, and description. Match against those for the keyword shape the upstream cannot filter on — per-post fetches add cost without adding text.
5. Resolve redirect URLs only when you need the destination. Tracking redirects (producthunt.com/r/...) are fine to keep as-is for ranking/scanning. Resolve them before enrichment, outreach, or domain matching.

Search constraints (the load-bearing gotcha)

The upstream has no full-text search on posts. The only post filters are topic, featured, url, twitterUrl, postedBefore, postedAfter, and order. Anything else (keyword, sponsor name, country, price tier) is a client-side grep over name / tagline / description on returned edges.

• order accepts NEWEST, RANKING, FEATURED_AT, VOTES. It does not accept POPULARITY — that string fails server-side validation even though it appears in informal Product Hunt copy.
• Posts come in two cohorts: those scheduled for a launch day (featuredAt populated) and unfeatured submissions. featured=true filters to launched.
• Dates are ISO 8601 UTC (2026-04-01T00:00:00Z). Half-open windows: postedAfter is inclusive, postedBefore is exclusive.

Rate limits are complexity-budgeted, not request-counted

Product Hunt meters every GraphQL request against a 6,250-unit complexity budget per ~15-minute window, shared across the whole workspace's traffic to this provider. Every response carries the current limit, remaining, reset_at, and reset_in_seconds — pace against remaining, not against request count.

• One page of posts with topics and edges costs roughly 100 units. Long scans should plan for 50–60 pages per window, not hundreds.
• Burning the budget returns an immediate rate-limit error; the only remedy is waiting until reset_at.
• Single-threaded, narrowed scans (topic + date window) stay well inside the budget. Broad multi-window fan-out is the failure mode.

URLs and enrichment

• Post website and entries inside productLinks are tracking redirects through producthunt.com/r/.... Single-post fetches auto-resolve; bulk list scans return the raw redirects. Resolve before persisting domains for enrichment, outreach, or backlink work.
• productLinks is the right enrichment surface — Website, Twitter/X, LinkedIn, Instagram, GitHub, sometimes Bluesky. Use the resolved Website domain as the company identifier.
• Maker, author, and hunter profile data is redacted. userId on a post is not a usable lookup key — treat it as opaque. Founder/company enrichment goes through productLinks plus the resolved website domain.

Discovery surfaces

• Topics are fetched best by known slug (artificial-intelligence, developer-tools, productivity, open-source, marketing, design-tools). Listing topics returns them in reverse-chronological creation order, so the top of the feed is dominated by event topics ("Pitch Dubai", "Pitch NYC", ...), not the high-volume evergreen ones.
• Collections are useful for thematic launch sweeps and editorial sets. They overlap with topics but are curated, not taxonomic.
• Comments are the launch-day sentiment surface — maker replies, early-user reactions, criticisms. Pull them when traction signals matter beyond vote count.