How the rankings work — and what we refuse to count

RSS Atlas — Fri, 14 Aug 2026 16:57:52 +0000

Ads in RSS Atlas take no part in the ranking calculation. There are ad slots, but they are separate and labelled "Ad".

Anyone can write that sentence, so here is what is actually counted — and, more importantly, what is deliberately not.

The three signals

Signal	What it represents
Favorites	Someone decided they wanted to come back to it
Page views	The feed's detail page was opened
AI fetches	An AI tool retrieved the feed over MCP

These are combined with time decay, so recent interest counts for more. A feed read heavily last year sits below one being read this week.

The ordering is public: favorites weigh most, then views, then AI fetches. The coefficients and thresholds are not. Publishing the exact numbers would amount to publishing which signal is cheapest to inflate.

Why count AI fetches at all

This is the axis other directories do not have.

Search traffic is falling while assistants increasingly compose the answer, which makes what the AI reads a separate fact from what humans open. Feeds exist — reference documentation is the obvious case — that people rarely click through to but agents pull repeatedly.

What is deliberately excluded

This half matters more.

Ads and sponsor slots. Inserted at the render layer only; they touch neither the score nor the ordering
Payment. There is no way to pay for a position. Slots may be sold later, but a slot is not a rank
Article volume. A site publishing ten posts a day has no claim over a good weekly one
Age. Having existed since 2005 says nothing about being worth reading now
Unreviewed feeds. Submissions that have not passed review stay out of rankings entirely

Making the numbers hard to inflate

Publishing what you count invites people to manufacture it. AI fetches are the exposed surface, since there is an unauthenticated demo path, so:

Deduplicated per client per day. The same client pulling the same feed a thousand times counts once
Contribution scales logarithmically in the number of distinct clients, so spinning up more of them does not pay linearly
Day-over-day outliers are held back. A sudden spike has that day's increment withheld pending a look

None of that is airtight, which is why AI fetches carry the smallest weight of the three.

No ads in MCP responses

When an AI tool calls get_rankings, what comes back is purely organic. The sponsored-placement data is not consulted by that query at all.

The website shows ads. MCP responses, search results, OPML exports and badges never will. Mixing advertising into the data an agent reads would remove the reason for this directory to exist.

Checking it yourself

The rankings table shows position, feed count, favorites, AI fetches and score as columns. You can follow why something sits where it does without taking our word for it.

Category and tag rankings work the same way, ordered by the summed score of the feeds they contain.

The transparency is not altruism. A directory whose ordering cannot be trusted has no value left — the moment positions become purchasable, it is a list of adverts, not a directory.

Letting an AI ask 'what shipped in this field this week?'

RSS Atlas — Thu, 13 Aug 2026 16:48:03 +0000

Ask an assistant about recent developments and you get one of two things: whatever was in its training data, or the top few web search results. What you cannot ask is the thing you actually want — "what came out in Rust tooling in the last two weeks" — scoped to a field, across the sources that cover it.

Those sources exist. They are RSS feeds. They are just not reachable from an AI tool.

So I built a directory of them and gave it an MCP server. This post is about four decisions that only became obvious after shipping, not a tour of the product.

What it is

2,907 RSS feeds across 19 languages and 37 categories, holding 51,483 articles. An MCP server exposes it to AI tools.

claude mcp add --transport http rss-atlas https://mcp.rssatlas.com/mcp

Other clients take it in settings.json:

{ "mcpServers": { "rss-atlas": { "httpUrl": "https://mcp.rssatlas.com/mcp" } } }

It runs on Cloudflare Workers (site and MCP server), Supabase (Postgres), and Cloud Run Jobs (crawler). There is a no-auth demo at https://mcp.rssatlas.com/demo if you want to poke at it.

1. Four tools, and adding a parameter instead of a fifth

The server exposes exactly four tools: search_feeds, get_feed, get_articles, get_rankings.

Building "fetch articles from only my favourited feeds" wanted to be a fifth tool — get_favorite_articles. It became a parameter instead:

favorites_only: z.boolean().optional()
  .describe("Restrict results to the signed-in user's favorites"),

The reason is that every added tool is another choice the model has to get right. With get_articles and get_favorite_articles side by side, the model decides between them on every call. As a parameter it is not a decision at all — it is an argument. One less branch.

The rule now is: before adding a tool, check whether an existing tool's parameters can carry it.

2. Auth failures must be HTTP 401, not a 200 with an error

This one cost the most time.

MCP lets a tool return isError: true in its result. I used that for unauthenticated requests at first — HTTP 200, error in the payload.

Clients do not show a sign-in prompt for that.

They decide "authentication needed" from HTTP 401 plus a WWW-Authenticate header. A 200 means the call succeeded as far as the transport is concerned, so whatever is inside gives the client no reason to start an auth flow. To the user it looks like a tool that throws a confusing error.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.rssatlas.com/.well-known/oauth-protected-resource"

The authorization server is discovered from that header. So: authentication is expressed at the HTTP layer, not in tool results. Ordinary failures inside a tool call — no matches, bad argument — are still fine as isError. Do not mix the two.

3. Take the user id out of the arguments

For anything scoped to a user, the user id is not a tool parameter. The only identity used is sub from the verified access token:

if (favorites_only && !caller.userId) return fail("favorites_only requires a signed-in user");

Validation would have caught a wrong id. But with MCP the model composes the arguments, so an argument that can name another user is a shape that invites the mistake. If the field does not exist, the class of bug does not exist.

Structure beats validation for anything that must never be passed.

4. The Workers Rate Limiting binding does not block

Cloudflare Workers has a Rate Limiting binding. I used it for the MCP server's limits.

It did not work — more precisely, it did not block.

The docs say plainly that it is not intended for precise counting. It is distributed, counts do not settle instantly across edges, and near the threshold requests get through. It is for shaping rough traffic, not for reliably stopping the 31st call.

Rewrote it on a Durable Object, which serialises to a single instance and therefore counts exactly. Measured afterwards: the 31st request returns 429 for authenticated users, the 11th for the demo.

The habit that came out of this: after implementing a rate limit, hammer past the threshold and watch it actually refuse.

No AI on the site itself

Worth stating because it drove several decisions: there is no summarisation and no AI classification in the product. Classification is rules and thresholds. Summarising happens in your own LLM.

The reason is that the reader is already paying for a model. Calling one server-side means they pay twice, indirectly. Over MCP the summary belongs on their side anyway — faster, cheaper, and their choice of model.

For the same reason feed content is capped at title + 500-character excerpt + link. Nothing is stored in full. You read it at the source, which is what RSS was for.

Bonus: 500 healthy feeds silently stopped updating

Not MCP, but it ate a comparable amount of time.

Conditional GET plus redirects: /feed → 301 → /feed/ → 304 Not Modified.

304 is a 3xx. Treat "3xx means redirect" literally and you go looking for a Location header, which a 304 does not have, and you error out.

The nasty part is that only feeds that once succeeded well enough to store an ETag can hit this — so your best-behaved sources break first, and because the listing still renders, they just quietly go stale.

Fixing the redirect check to mean "3xx except 304" and requeueing took failures from 501 to 13.

Takeaways

Solve it with a parameter before adding a tool; every tool is a decision the model can get wrong
Auth failures are HTTP 401 — isError on a 200 never triggers a sign-in prompt
Delete arguments that must never be passed; do not merely validate them
The Workers Rate Limiting binding does not block. Use a Durable Object when the count must be right

Demo, no auth required: https://mcp.rssatlas.com/demo — and the directory is at rssatlas.com.

DEV Community: RSS Atlas