---
summary: "hn_get_thread gains a resumable cursor, root relationships, and poll options; hn_get_stories/hn_get_thread/hn_get_user report failed item fetches instead of dropping them, and a 429's Retry-After now reaches the recovery hint."
breaking: false
security: false
---

# 0.5.19 — 2026-09-23

## Added

- **`hn_get_thread.cursor` / `nextCursor`** resume a traversal cut by `maxComments`, a new 64,000-byte response budget, a 1,000-item ceiling on what one call examines, or a rate limit, without skipping or repeating comments. `truncationReason` (`count`, `size`, `rate_limited`, `depth`) replaces the old raise-`maxComments`-or-`depth` guidance, and an `invalid_cursor` reason fires when a cursor is passed with a different `itemId`. ([#20](https://github.com/cyanheads/hn-mcp-server/issues/20))
- **`hn_get_thread`'s root** carries `parent` (comment roots), `poll` (poll-option roots), `parts` and resolved `options` (poll roots, resolved at every `depth` including `0`), and `deleted`/`dead` markers; the `content[]` heading is type-aware. `hn_get_user` submissions carry the same `parent`/`poll` links. ([#19](https://github.com/cyanheads/hn-mcp-server/issues/19))
- **`failedIds`** on `hn_get_stories`, `hn_get_thread`, and `hn_get_user` names items whose fetch failed after retries, apart from deleted, dead, or missing ones, with a retry notice. An `hn_get_stories` or `hn_get_user` page where every item failed now throws the classified upstream error instead of returning empty; `hn_get_thread` still returns its root. A rate-limited item stops the batch rather than sending every remaining item through its own retry ladder. ([#18](https://github.com/cyanheads/hn-mcp-server/issues/18))
- **A 429's `Retry-After` header** passes through unchanged as `data.retryAfter` and the recovery hint, naming the exact wait instead of a generic "several seconds". ([#26](https://github.com/cyanheads/hn-mcp-server/issues/26))

## Fixed

- **`hn_search_content.dateRange.end`** rounds a fractional second up instead of down, so an item created in that same whole second is no longer excluded.
- **`hn_search_content`'s `invalid_date_range` check** compares `start` and `end` as exact instants instead of truncated seconds, so two bounds within the same second are no longer rejected as out of order.