MCP server for accessing Hacker News stories and items
The server defines 7 well-structured tools with consistent naming, reasonable descriptions, and explicit input schemas using Zod validation. All tools follow verb_noun naming conventions (hn_get_*) and are read-only, which is appropriate for a Hacker News client. However, descriptions are uniformly brief (34 - 76 chars), and parameter descriptions lack detail about constraints, ranges, and edge cases. The output schema is documented implicitly through JSON stringification but not explicitly declared in parameter descriptions. Error handling is minimal, tools return raw API responses without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The schema quality is solid across all tools: all use Zod with explicit type declarations, min/max constraints, and defaults. Naming is clear and consistent. The main gaps are shallow descriptions and missing error guidance patterns.
Get the latest Ask HN stories
Get the best stories on Hacker News
Retrieve a Hacker News item (story, comment, job, poll, or poll option) by its ID
Get the latest job postings
Get the newest stories on Hacker News
Get the latest Show HN stories
Get the current top stories on Hacker News
Descriptions lack actionable context. 'Get the current top stories on Hacker News' (58 chars) omits what fields are returned, typical use cases, or when to prefer this tool over hn_get_best_stories or hn_get_new_stories. LLMs struggle to disambiguate similar tools without explicit contrast.
Parameter 'limit' descriptions state constraints (e.g. 'max: 500') but do not explain why defaults exist or what happens if the API returns fewer results. Missing guidance on pagination and result handling.
No error recovery guidance. Tools return raw JSON or errors without actionable next steps. If hn_get_item returns null, the agent has no hint whether the ID is invalid, the item was deleted, or the API is down. Missing pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No tool annotations present. All tools are read-only and idempotent, but this is not declared via readOnlyHint or idempotentHint metadata. This prevents clients from optimizing caching and safety checks.
Output schema not explicitly documented. Tools return JSON.stringify(result, null, 2), but the structure of HNItem and result arrays is not described in tool metadata. LLMs cannot plan downstream transformations without seeing the schema.