A
licenseA
qualityD
maintenanceEnables browsing Hacker News, searching discussions, analyzing users, and tracking tech trends with zero setup required—no API keys or authentication needed.
5
26
6
MIT
hn-mcp-server
Server Details
Browse Hacker News feeds, threads, and user profiles with full-text search.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/hn-mcp-server
- GitHub Stars
- 4
- Server Listing
- @cyanheads/hn-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.2/5.0
Tool DescriptionsA
Average 3.9/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct aspect of Hacker News: stories by feed type, individual threads with comments, user profiles, and content search. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with the 'hn_' prefix and snake_case (e.g., hn_get_stories, hn_search_content). No naming irregularities.
Tool Count5/5
4 tools is appropriate for a focused Hacker News server covering the core data access patterns: listing, detail view, user info, and search.
Completeness4/5
Covers the primary read operations (stories, threads, users, search). Missing write or auth operations, but those are likely out of scope for this server.
Available Tools
4 toolshn_get_storiesHn Get StoriesARead-onlyInspect
Fetch stories from an HN feed (top, new, best, ask, show, jobs), with title, URL, score, author, and comment count for each story.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| feed | Yes | Which HN feed to fetch. "top" includes jobs. "ask" and "show" are Ask HN / Show HN posts. | |
| count | No | Number of stories to return. Larger counts take longer. | |
| offset | No | Number of stories to skip from the start of the feed. Use with count for pagination. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The count cap that was applied. |
| feed | Yes | Which feed was fetched. |
| shown | No | Number of stories returned on this page. |
| total | Yes | Total items in the feed (up to 500 for top/new/best, 200 for ask/show/jobs). |
| notice | No | Recovery hint when a page is empty — e.g. offset past end of feed or feed has no items. Absent on non-empty result pages. |
| offset | Yes | Offset that was applied to this page. |
| hasMore | Yes | Whether more stories are available beyond this page. |
| stories | Yes | Stories from the feed, ordered by HN ranking. |
| truncated | No | True when the feed was capped by the count parameter. |
Tool Definition Quality
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, which the description does not contradict. The description adds context about the returned fields but does not disclose other behavioral traits such as sorting, rate limits, or pagination behavior. With annotations covering the safety profile, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys the essential information: fetch stories, which feeds, and what data is returned. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 3 parameters fully documented in the schema and an output schema present. The description covers the core purpose and return fields. It is complete enough for an agent, though it could mention the default sorting or the fact that results are ordered by feed order.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed annotations for each parameter (enum values, defaults, limits). The description does not add additional parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (fetch stories), the resource (HN feed), and the returned fields (title, URL, score, author, comment count). Distinguishes from siblings by focusing on feed listings rather than threads, users, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the feed types listed, but the description does not explicitly state when to use this tool over alternatives like hn_get_thread or hn_search_content. Sibling names are provided in context but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hn_get_threadHn Get ThreadARead-onlyInspect
Get an item and its comment tree as a threaded discussion, with child comments resolved recursively. Use depth 0 for an item-only lookup.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | How many levels of replies to resolve. 0 = just the item, no comments. 1 = direct replies only. Popular stories often have more top-level comments than maxComments — to see nesting, raise maxComments together with depth, or call again with a specific comment's itemId to drill into a subtree. | |
| itemId | Yes | ID of the story, comment, or poll to fetch the thread for. | |
| maxComments | No | Maximum total comments to include across all depth levels. Highest-ranked top-level comments resolve first; replies fill in only after the level above is exhausted. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxComments cap that was applied. |
| item | Yes | The root item (story, comment, or poll). |
| shown | No | Number of comments returned. |
| notice | No | Truncation context: counts of deleted/dead comments dropped during traversal, or pagination hint when totalLoaded < totalAvailable. Absent when no comments were dropped and all available comments were loaded. |
| comments | Yes | Flat comment list ordered breadth-first by rank: highest-ranked top-level comments first, then their replies. Use depth/parentId to reconstruct nesting. |
| truncated | No | True when the comment list was capped by maxComments. |
| totalLoaded | Yes | Number of comments actually fetched and included. |
| totalAvailable | No | Total comment count from the root item. If totalLoaded < totalAvailable, raise maxComments (and depth, if you want nested replies) and call again. |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that child comments are resolved recursively, which is key behavioral info. Does not mention potential performance implications or rate limits, but the recursive behavior is sufficiently disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core function, second gives a practical tip. No fluff, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered elsewhere. Description explains recursive thread resolution, parameter behaviors, and a usage tip. Complete for a threaded discussion tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds context for depth ('item-only lookup') and for maxComments ('highest-ranked top-level comments resolve first') but itemId parameter is not enhanced beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'Get an item and its comment tree as a threaded discussion' — clear verb and resource. Recursive resolution distinguishes it from sibling tools like hn_get_stories or hn_get_user, which fetch lists or flat data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one specific guideline: 'Use depth 0 for an item-only lookup.' Does not explicitly contrast with siblings or state when not to use this tool, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hn_get_userHn Get UserARead-onlyInspect
Get an HN user profile with karma, about, and optionally their most recent submissions resolved into full items.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | HN username. Case-sensitive. Trimmed; blank or whitespace-only input is rejected. | |
| submissionCount | No | Page size — how many submissions to resolve per call. Only used when includeSubmissions is true. | |
| submissionOffset | No | How many submissions to skip before resolving, counting back from the most recent. Use with submissionCount to page through a long history: request offset 0, then offset submissionCount, and so on. The enrichment block echoes submissionOffset and, when more remain, the offset to send next. Only used when includeSubmissions is true. | |
| includeSubmissions | No | Resolve the user's most recent submissions into full items. Without this, only the submission count is available. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The submissionCount cap that was applied. |
| user | Yes | User profile. |
| shown | No | Number of submissions returned. |
| notice | No | Pagination context — which window of the history this page covers and the submissionOffset to send next, or a warning that the offset is past the end. Absent when the page reaches the end of the history, or when no submissions were resolved. |
| truncated | No | True when submissions remain beyond this page. |
| submissions | No | One page of submissions, most recent first, starting at submissionOffset. Absent when includeSubmissions is false or the user has never submitted. Empty when the page holds no live items — either the offset is past the end, or every item in the window was deleted or flagged. |
| submissionOffset | No | The offset this page started at. Absent when includeSubmissions is false or the user has never submitted. |
Tool Definition Quality
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that submissions can be 'resolved into full items', which is a minor behavioral detail. However, it does not disclose potential rate limits or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Get an HN user profile') and tucks optional details afterward. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers the tool's behavior. It explains the optional submission resolution and paging mechanics. Slight gap: no mention of pagination limits beyond max submissionCount.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage. The description further clarifies username case-sensitivity, trimming, and paging behavior for submissionOffset, adding value beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an HN user profile with specific fields (karma, about) and optionally resolves recent submissions. It distinguishes itself from sibling tools (hn_get_stories, hn_get_thread, hn_search_content) by focusing on user profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving user profiles but does not explicitly state when to use this tool versus alternatives like hn_search_content for searching users. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hn_search_contentHn Search ContentARead-onlyInspect
Search Hacker News stories and comments via Algolia. Filterable by content type, author, date range, and minimum points.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (0-indexed). | |
| sort | No | Sort order. "relevance" for best match, "date" for most recent first. | relevance |
| tags | No | Filter results by content type. Omit to search all types. | |
| view | No | How much of each hit to return. "full" includes every field. "compact" omits the two body-text fields — `text` and `highlights.text` — which together can repeat a long comment twice per hit; everything else (id, title, url, domain, author, points, comment count, timestamp, parent story, title highlight, matchedWords) is unchanged. Use "compact" to scan many results, then pass a hit id to hn_get_thread to read the body you skipped. | full |
| count | No | Number of results to return. | |
| query | Yes | Search terms. Supports simple keywords — Algolia handles stemming and relevance. Trimmed before searching; blank or whitespace-only input is rejected. | |
| author | No | Filter results to a specific author. Useful for finding a user's posts on a topic (hn_get_user only shows recent submissions). Trimmed before filtering; omit the field to search all authors rather than passing a blank string. | |
| dateRange | No | Filter to a date window. Useful for finding discussions about recent events. | |
| minPoints | No | Minimum score/points. Filters out low-engagement content. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The count cap that was applied. |
| hits | Yes | Search results ranked by sort order. |
| page | Yes | Current page number (0-indexed). |
| query | Yes | The query that was searched. |
| shown | No | Number of hits returned. |
| notice | No | Recovery hint when results are empty — names the filters applied, for relaxing the search. Absent on non-empty result pages. |
| totalHits | Yes | Total matching results across all pages. |
| truncated | No | True when the hit list was capped by the count parameter. |
| totalPages | Yes | Number of pages Algolia will actually serve for this query. Not derived from totalHits — broad queries report a totalHits far larger than the reachable page range, so paginate against this value. |
Tool Definition Quality
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral details beyond the readOnlyHint annotation. It mentions Algolia as the backend which is extra context, but does not elaborate on safety, destructive actions, or rate limits, which are already covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the core purpose and key features. No wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects, output schema exists), the main description is brief but the schema fills in the details. The description covers the essential functionality and mentions the backend. It could mention pagination or default sort, but those are in the schema defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The main description only summarizes filtering capabilities (content type, author, date range, minPoints) without adding further detail. The schema itself already provides thorough descriptions for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Hacker News stories and comments via Algolia, with filtering options. It distinguishes itself from sibling tools (hn_get_stories, hn_get_thread, hn_get_user) by focusing on search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main description does not explicitly state when to use this tool vs siblings. However, the 'view' parameter description mentions a workflow hint (use compact then hn_get_thread), implying usage context. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityCmaintenanceEnables searching and retrieving top stories and individual items from Hacker News, with access to scores, comments, authors, and timestamps.11MIT
- FlicenseAqualityDmaintenanceEnables AI assistants to read and search Hacker News for top stories, comments, user profiles, and job listings using the Firebase and Algolia APIs. It facilitates natural language research into community discussions and technological trends across the HN platform.8
- AlicenseAqualityDmaintenanceProvides programmatic access to Hacker News content via the HN Algolia API. It enables AI assistants to search stories, retrieve comments, access user profiles, and explore the front page in real-time.919MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.