hn-mcp-server get-item silently ignores limiting params — full 1.6MB comment tree dumped regardless

Reproduced on hn-mcp-server v1.1.0 via npx

The problem

get-item accepts only itemId (string) — there is no parameter to limit comment tree depth, count, or response size. Worse, the Zod schema does not use .strict(), so extra properties like maxComments, depth, and limit are silently accepted and ignored. An agent that tries to be defensive gets zero feedback that its limiting params had no effect.

Repro

# Launch: npx -y hn-mcp-server
# Initialize, then:

# Agent tries to limit to 1 comment, depth 0:
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get-item","arguments":{"itemId":"13541679","maxComments":1,"depth":0,"limit":1}}}

# Result: isError=false, 1640KB response, 940 top-level children, 1217 total nested comments
# ALL limiting params silently ignored

Measurements

Why this matters for agents

1. No defensive option: Unlike search-posts (where agents can set hitsPerPage=5), get-item offers zero control over response size. The full comment tree is always returned.

1. Silent param swallowing: An agent passing maxComments: 5 gets isError: false and a 1.6MB response — it has no way to know its limiting intent was ignored. The non-strict Zod schema accepts any extra property without error.

1. Compound amplification: An agent searching "who is hiring" finds stories with 1000+ comments. Following up with get-item on 3 results generates ~5MB. Combined with search-posts at hitsPerPage=1000 (5.1MB per call), a naive agent flow pulls 10+ MB in a few tool calls.

1. Context window exhaustion: Most LLM context windows are 128K-200K tokens. 1.6MB of comment text is ~400K tokens — a single get-item call can overflow the context.

Additional findings (same server)

• search-posts with query="a" and hitsPerPage=1000 returns 5.1MB (1000 hits from 44.9M matches). Reports nbPages: 1 with nbHits: 44985404 — the 45M figure is misleading since only 1000 results are accessible.
• search-posts with page=999 (beyond valid range) returns isError: false with nbHits: 0, nbPages: 0 — indistinguishable from "no results match your query."

Root cause

The get-item tool schema declares only itemId with no additional parameters for response control. The underlying HN API (Algolia) does support filtering, but the MCP server does not expose any mechanism to limit comment depth, count, or response size. The Zod schema uses non-strict mode, silently dropping unknown properties rather than rejecting them.