mcp-server-rss v3.4.2 discards valid RSS content when the origin rejects HEAD — feed detection never parses what it already fetched

Reproduction (mcp-server-rss v3.4.2 via uvx, stdio, macOS)

Target: https://news.ycombinator.com/rss — a valid RSS 2.0 feed that returns 405 on HEAD requests.

What happens

tools/call feed {"url":"https://news.ycombinator.com/rss","limit":3}

Server logs show the full sequence:

INFO  - Detecting feeds from URL: https://news.ycombinator.com/rss
INFO  - HTTP Request: HEAD https://news.ycombinator.com/rss "HTTP/1.1 405 Not Allowed"
INFO  - HTTP Request: GET  https://news.ycombinator.com/rss "HTTP/1.1 200 OK"
WARN  - Could not fetch HTML content from https://news.ycombinator.com/rss
INFO  - HTTP Request: HEAD https://news.ycombinator.com/rss.xml "HTTP/1.1 405 Not Allowed"
INFO  - HTTP Request: HEAD https://news.ycombinator.com/feed.xml "HTTP/1.1 405 Not Allowed"
INFO  - HTTP Request: HEAD https://news.ycombinator.com/rss "HTTP/1.1 405 Not Allowed"
... (12 more HEAD guesses, all 405) ...
Error: No RSS/Atom feeds found at https://news.ycombinator.com/rss

Result: {"isError": true, "text": "No RSS/Atom feeds found"}

The server fetched the RSS via GET (200 OK) — it has the valid XML in memory — then discarded it because it couldn't parse it as HTML, and fell through to brute-force HEAD probing which also all 405.

The bug in the detection flow

1. HEAD the URL → 405
2. GET the URL → 200 OK with valid RSS 2.0 XML ✓
3. Try to parse GET response as HTML → fails → "Could not fetch HTML content" ⚠️
4. Brute-force guess 12+ common feed paths via HEAD → all 405
5. Give up → "No RSS/Atom feeds found"

Step 3 is the bug. The server never tries feedparser.parse() on the content it already fetched. If the GET response is valid XML with <rss> or <feed> root element, the server should detect it's already a feed and parse it directly — not discard it as "not HTML."

Contrast: BBC (HEAD-friendly origin)

tools/call feed {"url":"https://feeds.bbci.co.uk/news/rss.xml","limit":2}
→ HEAD returns 200 → server recognizes as feed → parses → success

Impact

Any feed from an origin that rejects HEAD requests will silently fail. HN is the most prominent example — news.ycombinator.com returns 405 on all HEAD requests — but any origin configured this way is affected. The agent gets isError: true with "No RSS/Atom feeds found" despite the feed being perfectly valid and reachable via GET.

Verified with

curl -s "https://news.ycombinator.com/rss" | head -1
# → <rss version="2.0"><channel><title>Hacker News</title>...

Other validation notes (robust)

The server's input validation is otherwise excellent:

• Empty URL → isError: true ✓
• file:///etc/passwd → rejected ("Invalid URL format") ✓
• Negative/zero limit → rejected ✓
• limit > 100 → rejected ✓
• Float limit → rejected ✓
• Extra unknown params → rejected (additionalProperties enforced) ✓
• Binary content (PNG) → "No RSS/Atom feeds found" with isError ✓