Reported issues for AgentDeals
Pod holds 22 of 226 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to AgentDeals.
Most discussed
Security issues flagged by MCP Marketplace
We have this report from https://mcp-marketplace.io/server/io-github-robhunter-agentdeals?welcome=true. My guess is it means that we need to run an npm audit fix or something similar.
This is a well-structured MCP server that aggregates developer tool deals and pricing data. The code follows good security practices with proper authentication handling, appropriate permissions for its purpose, and clean architecture. Supply chain analysis found 2 known vulnerabilities in dependencies (0 critical
Read the thread · 2026-03-20 · open · 18 comments
Agent identity, referral attribution and credit balances cannot survive a deploy — and three tool descriptions promise they do
Every agent-facing tool that depends on identity writes its state to a JSON file inside the container. The container is built with COPY data/ data/, the committed versions of those files are empty, and there is no volume. So agent identity, referral attribution and credit balances cannot survive a deploy — and three published tool descriptions tell agents otherwise.
The mechanism
src/agents.ts:8 resolves the registry to a path inside the app directory and saveAgents writes it with `fs
Read the thread · 2026-08-30 · open · 10 comments
Traffic dashboard: a vendor-page leaderboard and a traffic view Rob can open — and the history it needs does not exist yet
Superseded in part, 2026-08-26. Rob has ruled that this dashboard must not be published on agentdeals.dev. Acceptance criteria 1 and 3 below are withdrawn, and the issue is split into Part A (record the per-vendor series — do this now) and Part B (the exploration surface — parked on a design doc). See the restructuring comment, which is the current spec.
The ask
Rob wants somewhere to see how AgentDeals
Read the thread · 2026-08-26 · closed · 10 comments
Our privacy policy makes four claims that production contradicts, and forbids the vendor sharing Rob asked for today
Rob's direction this morning, verbatim: "Our privacy policy needs to make clear that we can share information with vendors — if it doesn't, we need to update that today."
It doesn't. It says the opposite, in a sentence built so that no amount of editing around it will help:
We do not share data with third parties because we do not collect data to share.
So this issue is not "add a sharing clause." The policy was last updated March 20, 2026 and the product has changed underneath it
Read the thread · 2026-08-25 · closed · 10 comments
Breadcrumb navigation and BreadcrumbList structured data
Overview
Add visual breadcrumb navigation and BreadcrumbList JSON-LD structured data to all content pages. Breadcrumbs help users navigate and improve Google search appearance (Google shows breadcrumbs in search results instead of raw URLs).
Why
We have 3,841 pages across 5 content types (vendors, comparisons, best-of, alternatives, stacks). Users landing deep in the site have no visual path back up. Google uses BreadcrumbList schema to display navigation trails in search results — this
Read the thread · 2026-04-15 · closed · 8 comments
Persist telemetry stats across deploys
Problem
Telemetry stats (total sessions, tool calls, API hits, landing page views) are stored in memory and reset to zero on every deploy. The most recent deploy (PR #106, March 4) wiped 95 organic sessions worth of data.
This causes two problems:
- Health dashboard shows 0 sessions — makes the product look dead when Rob checks it
- Growth metrics lost — we can't track session growth over time (3 → 75 → 77 → 95 → 0)
Current behavior
/healthendpoint returns in-memory
Read the thread · 2026-03-04 · closed · 7 comments
/signal: remove the untrue referral claim, stop publishing our traffic, cut the page to 175 words
Summary
/signal publishes a statement about this site that is not true, and gives away our own traffic
numbers on an unauthenticated endpoint. Rewrite the page short, delete the published data, and
remove the claim from both surfaces that carry it.
CEO direction 2026-08-27: "There's too much copy and exposition here, there are commitments to no tracking / referrals, and we publish data. Definitely don't publish data there, and clean up the copy. Short, to the point."
1. The site does
Read the thread · 2026-08-27 · closed · 6 comments
Serve AGENTS.md via HTTP (404 on live site)
Problem
AGENTS.md was added to the repo root in PR #321 but is not served via the HTTP server. https://agentdeals.dev/AGENTS.md returns 404.
llms.txt is properly served (has a route in serve.ts at line ~5100), but AGENTS.md was not given an equivalent route.
Context
AGENTS.md is an emerging standard (now under the Linux Foundation / Agentic AI Foundation) that guides AI coding agents on how to interact with a project. For AgentDeals specifically, serving AGENTS.md at our web root
Read the thread · 2026-03-19 · closed · 6 comments
Most recent
1,570 of 1,572 vendor pages publish their free tier as already expired — priceValidUntil holds the date the price last changed, not the date it stops
Every /vendor/:slug page emits a schema.org Offer for the free tier we publish. That Offer carries priceValidUntil, and on 1,570 of our 1,572 vendor pages the date in it has already passed.
schema.org defines the property in one sentence:
The date after which the price is no longer available.
We are filling an end-of-validity date with a start-of-validity date. Those are opposite ends of the same interval.
The line
src/serve.ts:4007, inside the SoftwareApplication JSON-LD:
Read the thread · 2026-08-30 · closed · 4 comments
Our own crawler is counted as unknown traffic — the published note bounding maintainer distortion names the wrong class
Summary
/api/traffic publishes a note telling the reader how far a maintainer's own requests can distort
the numbers. The bound it gives is wrong for the only maintainer tooling that actually runs against
this site. Four user agents my cycles send are classified unknown — the second-largest class we
publish — and one census run put 3,534 requests there in a single hour.
The correct rule already exists in this repo, on the MCP side, and the web side does not use it.
The published cla
Read the thread · 2026-08-30 · open · 0 comments
get_referral_code is the highest-intent call we serve and the only vendor-surfacing tool that never asks the agent to report its recommendation
Summary
We ask agents to tell us which vendor they recommended, on every surface except the one where an
agent has already decided. get_referral_code is the third most-called tool we publish, it is the
moment of highest intent in the product, and it is the only vendor-surfacing tool whose response
carries no signal ask. Its response also reports "attributed": false without naming anything that
would make it true.
What the beacon has collected
/api/signal has been recording since 2
Read the thread · 2026-08-30 · open · 0 comments
POST /api/conversions and /api/conversions/confirm are unauthenticated — anyone can write ledger entries that credit an agent balance
POST /api/conversions and POST /api/conversions/confirm are publicly reachable with no authentication. The first one writes ledger entries that credit an agent balance; the second runs the clawback-window confirmation sweep that moves balances from pending to confirmed. Confirmed balance is what request_payout pays out.
Verification
I probed both on production with a body that could not write anything, so nothing was added to the ledger.
POST /api/conversions {} -> 400 {
[Read the thread](https://github.com/robhunter/agentdeals/issues/1164) · 2026-08-30 · closed · 2 comments
### track_changes returns ~37,500 tokens by default, 95% of it unconfirmed detector output — and passing `since` silently returns a different schema
`track_changes` is our second most-called tool — 124 of 562 all-time tool calls, behind `search_deals` at 289. Its default response is about 37,500 tokens, 95% of which is unconfirmed detector output that the website itself declines to count as a pricing change.
All figures below are from live calls against `https://agentdeals.dev/mcp` on 2026-08-29. Token counts are characters ÷ 4.
## The default response
| Key | Bytes | Records |
|---|---|---|
| `discovered_changes` | **129,923** | 153 |
|
[Read the thread](https://github.com/robhunter/agentdeals/issues/1160) · 2026-08-29 · open · 0 comments
### We cannot tell whether anyone ever leaves for a vendor — no outbound click is recorded anywhere
The site exists to send a reader to a vendor. That is the one event we do not record.
## What we measure and what we don't
`/api/metrics` and `/api/traffic` carry page views by route and class, MCP tool calls, search queries, zero-result queries, referral marketplace lookups, and change-log freshness. There is no outbound key in either.
I checked for a mechanism rather than assuming: `grep -E '(res\.redirect|Response\.redirect|status:\s*30[123])' src/*.ts` returns nothing, and there is no `cl
[Read the thread](https://github.com/robhunter/agentdeals/issues/1155) · 2026-08-29 · open · 0 comments
### The agent marketplace promises revenue share we cannot pay — 1,511 vendor pages solicit codes, the x402 transfer is a stub, and every deploy deletes every registered agent
## What we publish
`/marketplace` is titled "Agent Marketplace — Earn Revenue with Referral Codes" and gives agents four steps ending in "Get paid when your codes convert via x402". It prints a trust-tier table, a revenue-split table (70/30, 80/20, 40/40/20) and a `curl` for setting a payout address.
**1,511 of our 1,572 vendor pages carry the solicitation.** Every vendor with no referral surface renders it — confirmed live on `/vendor/supabase`:
> Know a referral or partner program for Supab
[Read the thread](https://github.com/robhunter/agentdeals/issues/1150) · 2026-08-29 · open · 3 comments
### A refused change record renders as "stable — zero pricing changes recorded" on 86 vendor pages — /vendor/lokalise publishes a free tier the vendor deleted
A refused change record is not a signal that nothing changed. It is a signal that we could not decide. On 86 vendor pages we render it as the former.
## The one that is false on production now
`/vendor/lokalise`, live:
> **stable** — Lokalise's free tier offers Localization platform — 1 project, 2 target languages, 500K hosted words, 500 translation keys, 10K processed words/year. **It's stable — zero pricing changes recorded.** Verified July 2026.
lokalise.com/pricing today lists four plans
[Read the thread](https://github.com/robhunter/agentdeals/issues/1139) · 2026-08-29 · open · 4 comments
### The vendor-name check can pass on our own stored URL — 7 records cite a page that now belongs to another company
## The check can be satisfied by our own stored URL
`source_check` records how it confirmed a page names the vendor. Across the 793 records with `outcome: ok`:
| `detail` | records |
|---|---|
| `text` | 749 |
| **`url`** | **43** |
| `host` | 1 |
For those 43, the vendor's name was found in the URL we store, not in the page we fetched. That makes the check circular: we typed the vendor name into the `url` field, so the page passes for containing what we wrote.
It matters when the URL stops
[Read the thread](https://github.com/robhunter/agentdeals/issues/1129) · 2026-08-28 · open · 0 comments
### 43 records cite a page our fetcher structurally cannot read — including RapidAPI and Kaggle, our two most-requested vendor pages
43 records carry `source_check.outcome: unreadable` with the detail `page content too short (likely JS-rendered SPA)`. The diagnosis is right — those vendors render their pricing in JavaScript and we fetch raw HTML. The consequence is that these records can never be confirmed by any future run, because nothing in the pipeline will ever see the text.
Two of them are our most-requested vendor pages: **RapidAPI is #1 by traffic and Kaggle is #6.**
Found during this cycle's traffic-led page review
[Read the thread](https://github.com/robhunter/agentdeals/issues/1124) · 2026-08-28 · open · 1 comment
### Our two documented install paths share zero tool names — npm ships a March build that answers none of the tools we document
We document two ways to install AgentDeals. They expose tool sets with **no name in common**, and
neither answers the other's names.
I went looking for this because ~94% of `/mcp` volume is a monitoring and directory ecosystem
(#1098, #1099), several of whose directories carry a listing for us. I wanted to know what those
listings tell an agent to install. PulseMCP's entry says stdio is "recommended for reliability and
speed", so I installed it the way an agent would.
## Measured
`npm install
[Read the thread](https://github.com/robhunter/agentdeals/issues/1102) · 2026-08-28 · open · 1 comment
### Our MCP handshake costs 4,229 tokens, 46% of it a referral program with zero participants, and states three different offer counts
An agent's first two messages to us are `initialize` and `tools/list`. Everything in those two
responses enters its context and stays there for the session. Ours currently costs **~4,229
tokens**, and both the contents and the counts are wrong.
## 46% of the tool payload is a program with no participants
`tools/list` returns 12 tools, 14,240 characters:
| Tool | Chars | |
|---|---|---|
| `search_deals` | 2,567 | product |
| `plan_stack` | 2,125 | product |
| `track_changes` | 2,006 | product
[Read the thread](https://github.com/robhunter/agentdeals/issues/1099) · 2026-08-27 · open · 1 comment
### The MCP notification stream dies every 125 seconds — Codex fails 37% of its requests to /mcp
Cloudflare closes the server-to-client SSE stream on `/mcp` after **125 seconds**, measured. The
session itself survives — a `POST` on the same session ID still works at 240s idle, and
`SESSION_IDLE_TIMEOUT_MS` in `src/serve.ts:249` is 15 minutes. It is only the long-lived `GET`
that dies.
Clients that want notifications reconnect, and the reconnect races the server's own cleanup of
the stream slot. The result is a per-client error rate that is high enough to see from the edge log.
## What the
[Read the thread](https://github.com/robhunter/agentdeals/issues/1098) · 2026-08-27 · open · 4 comments
### No change detector is scheduled — the daily job cannot notice a pricing change
The daily re-verification workflow does not pass `--ai`, so the only mode that can detect a
pricing change never runs. URL mode reports a hardcoded zero. Nothing is scheduled to write
to `data/deal_changes.json`.
This is one durable signal for a condition elapsed time cannot measure. The change log ages
whether or not anything out there has changed, so a day-counting alarm on it would be red
every day, and an alarm that is red every day is one nobody reads.
The staleness gate reads `days_since
[Read the thread](https://github.com/robhunter/agentdeals/issues/1087) · 2026-08-27 · closed · outside contributor · 4 comments
The remaining reports are on [the project's issue tracker](https://github.com/robhunter/agentdeals/issues).