MCP server
RSS Amplifier speaks the Model Context Protocol. Point an agent at https://rssamplifier.com/mcp and it can search tens of thousands of independent blogs, read any post in full, and add feeds of its own. No key, no account, no sign-up.
Connect
The transport is Streamable HTTP, so the URL is the whole configuration. In Claude Code:
claude mcp add --transport http rssamplifier https://rssamplifier.com/mcpIn a client configured by file — Claude Desktop, Cursor, Zed and most others read some variant of this:
{
"mcpServers": {
"rssamplifier": {
"type": "http",
"url": "https://rssamplifier.com/mcp"
}
}
}A client that only speaks stdio can bridge to it with npx mcp-remote https://rssamplifier.com/mcp.
Tools
10 of them, wrapping the same queries the JSON API answers. Everything except submit_feed is a read.
search
Full-text search across every post and blog in the directory. Returns matching blogs and matching individual posts, each with the identifiers read_post needs. Use mode="any" to match any one of the terms rather than all of them — useful when a thing goes by several names.
query: string · mode: all|any? · limit: integer?
list_feeds
Page through the whole directory, newest first. Narrow to one category with kind: blog, news, podcast, music, video, comic, live or reel. The category is decided from the feed document on every crawl, never from what the submitter claimed.
kind: blog|news|podcast|music|video|comic|live|reel? · limit: integer? · offset: integer?
get_feed
One blog or podcast: its metadata, the topics it is filed under — including the ones no other feed shares — and its recent posts. Each post carries the feed slug and guid that read_post takes. Use the slug from search or list_feeds, not the site's own URL.
slug: string · limit: integer?
list_topics
What the directory covers, by how many feeds cover it. Only subjects at least two feeds share are indexed — a topic one blog uses is that blog's own vocabulary, and lives on its page instead. Raise min to find the well-covered subjects.
min: integer? · limit: integer? · offset: integer?
get_topic
Every feed filed under one topic. The keyword is normalised, so "Home Lab", "home lab" and "home-lab" all reach the same topic and you can pass a phrase you read anywhere. Each feed says whether it landed here from the publisher's own tag or from a phrase counted across its writing.
keyword: string · limit: integer? · offset: integer?
topic_posts
What the feeds covering a topic have actually published lately, newest first — the river rather than the roster. Note the difference from get_topic, which lists who covers the subject; this lists what they wrote. Drawn from the feeds most strongly filed under the topic, so a very broad keyword is a sample rather than a census.
keyword: string · limit: integer?
read_post
The full text of one post, extracted from the publisher's own page and returned as prose. Takes the feed slug and post guid that search, get_feed and topic_posts return. The first reader pays for the fetch and everyone after them reads it out of the database, so the publisher is asked once rather than once per view. A post behind a paywall, or on a site that is down, comes back with the feed's summary and a reason instead — never an error.
feed: string · guid: string
random_feed
One feed from the directory, chosen at random, with its recent posts. The web without a ranking function: what is here rather than what is popular.
No arguments.
directory_stats
How big the directory is, what it is made of, and whether the crawler is keeping up. `stale` is active feeds not read successfully in a day; `due` is a backlog that should drain within a tick or two. Answer this before concluding a feed is missing — it may simply not have been crawled yet.
No arguments.
submit_feedwrites
Submit one URL or a list of them. A site URL works as well as a feed URL — the feed is discovered from the page. Anyone may submit; there is no account and no review queue. Feeds resolve inline up to a handful and the rest are queued for the crawler, so the answer says which. Rate limited per caller.
urls: array
Resources
One: llms.txt, the directory described in a single document — what it holds, how it is organised, and every endpoint it serves. A client can attach it as context instead of spending a tool call working out what to ask for.
There is deliberately no resource for the directory itself. It is tens of thousands of feeds; an agent that attaches all of them has spent its context on a list rather than on any of the writing.
Try it without a client
The endpoint is plain HTTP, so curl is enough to see it work:
curl -s https://rssamplifier.com/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-H 'mcp-protocol-version: 2026-07-28' \
-H 'mcp-method: tools/call' \
-H 'mcp-name: search' \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": { "query": "home lab" },
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28"
}
}
}'Protocol versions
The server answers 2026-07-28, which carries its metadata on every request and needs no handshake, and the older handshake-based revisions 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05. Whichever your client speaks, the same URL works.
It is stateless: no session is minted, nothing is remembered between calls, and there is no server-initiated stream to hold open. A GET or DELETE here answers 405 for that reason. The endpoint also answers at /api/mcp, alongside the rest of the JSON API.
Limits
Reads are unmetered and need no identification, though we would rather you sent a user-agent that says who you are. submit_feed shares the submission form's per-IP budget of twenty an hour, so an agent and a browser draw on one allowance rather than the agent having a private one.
Keyword discovery — the thing behind /discover — is not exposed as a tool. Every keyword is a credit against a metered search plan, and a tool that quietly spends money is the wrong shape for something anyone can connect to. It stays a form a person submits.