The Hacker News MCP Server provides comprehensive access to Hacker News data, enabling you to:
Search Hacker News: Search stories and comments using Algolia's search API with customizable parameters
Fetch Stories by Type: Retrieve stories filtered by type (top, new, best, ask, show, job)
Access Story Data: Get details of individual stories, either alone or with their associated comments
Explore Comment Trees: Retrieve hierarchical comment structures for stories
View User Profiles: Access user profile details, including karma, creation date, and about text
Get User Submissions: Fetch a user's submitted stories and comments
Real-Time Data: Access up-to-date Hacker News data seamlessly
Uses Algolia's HN Search API to search for stories and comments on Hacker News
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hacker News MCP Server search for recent posts about AI safety"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official Hacker News MCP Server - Adds powerful Hacker News integration to Cursor, Claude, and any other LLM clients. Access stories, comments, user profiles, and search functionality through the Model Context Protocol.
Search stories and comments using Algolia's HN Search API
Get stories by type (top, new, best, ask, show, job)
Get individual stories with comments
Get comment trees and user discussions
Get user profiles and submissions
Real-time access to Hacker News data
Related MCP server: HackerNews-Search
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"hackernews": {
"command": "npx",
"args": ["-y", "@devabdultech/hn-mcp-server"]
}
}
}To install Hacker News MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @devabdultech/hn-mcp --client claudesearch
Search for stories and comments on Hacker News using Algolia's search API
Inputs:
* query (string): Search query
* type (optional string): Filter by type ('story' or 'comment')
* page (optional number): Page number for pagination
* hitsPerPage (optional number): Results per page (max 100)
Returns: Search results with stories and comments
getStories
Get multiple stories by type (top, new, best, ask, show, job)
Inputs:
* type (string): Type of stories to fetch ('top', 'new', 'best', 'ask', 'show', 'job')
* limit (optional number): Number of stories to fetch (max 100)
Returns: Array of story objects
getStoryWithComments
Get a story along with its comment thread
Inputs:
* id (number): Story ID
Returns: Story details with nested comments
getCommentTree
Get the full comment tree for a story
Inputs:
* storyId (number): ID of the story
Returns: Hierarchical comment tree structure
getUser
Get a user's profile information
Inputs:
* id (string): Username
Returns: User profile details including karma, created date, and about text
getUserSubmissions
Get a user's submissions (stories and comments)
Inputs:
* id (string): Username
Returns: Array of user's submitted stories and comments
Fork the repository
Create your feature branch
Commit your changes
Push to the branch
Create a new Pull Request
This MCP server is licensed under the MIT License. See the LICENSE file for details.
This MCP server is built and maintained by devabdultech. It uses the official Hacker News API and Algolia Search API to provide comprehensive access to Hacker News data through the Model Context Protocol.
Get a single comment by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description accurately reflects a read operation; no annotations to contradict, but lacks detail on response format or post-fetch behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID fetch with no output schema, the description is sufficient and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters; description adds no extra meaning beyond restating the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (get), resource (comment), and scope (single by ID), distinguishing it from siblings like getComments and getCommentTree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives; context is implied by sibling names but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments for a story
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The ID of the story | |
| limit | No | The maximum number of comments to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral details (pagination, sorting, error handling, etc.). This is insufficient for a tool that may be called by an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. Could be expanded slightly but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description is too minimal to fully guide an agent, especially given the presence of overlapping sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond what the schema already provides for 'limit' and 'storyId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get', resource 'comments', and context 'for a story'. It distinguishes from siblings like 'getComment' (single) and 'getCommentTree' (hierarchical).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings such as 'getCommentTree' or 'getStoryWithComments'. No explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comment tree for a story
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The ID of the story |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the tool's function without mentioning read-only nature, authentication needs, rate limits, or return structure. This is insufficient for informed invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence that directly states the purpose. It is efficiently front-loaded, but could be slightly more structured to include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description fails to provide needed context about what a comment tree is, what the output contains, and when to prefer this tool over siblings. The tool is simple, but the description does not adequately compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter (storyId) described. The description does not add extra semantics beyond the schema. Per guidelines, baseline is 3 when schema coverage is high, and no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get) and resource (comment tree for a story). It hints at a hierarchical structure, but does not explicitly distinguish from siblings like getComments or getStoryWithComments, which could also retrieve comments. The specificity is good but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as getComments, getStoryWithComments, or getComment. An agent would need to infer the appropriate scenario without any help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple stories by type (top, new, best, ask, show, job)
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | The type of stories to fetch | |
| limit | No | The maximum number of stories to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It states 'get multiple stories' but does not disclose ordering, pagination, rate limits, or the format of returned data (e.g., story IDs vs full objects). The limit parameter is described in the schema, but behavioral details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, efficiently conveying the tool's purpose. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description is moderately complete. It covers the core functionality, but omits details about the output format (list of story objects or IDs) and potential behavior with invalid types or limits. Slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds no additional meaning beyond listing the enum values, which are also in the schema. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves multiple stories and specifies the exact story types (top, new, best, ask, show, job). It distinguishes from sibling tools like getStory (single story) and getComments, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (by story type) but does not explicitly mention when not to use it or provide alternatives. However, the sibling tool names suggest getStory for a single story, so the usage context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single story by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the story |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a simple read operation but does not disclose whether there are any side effects, error conditions, or details about the return value beyond retrieving a story.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and effectively communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with no output schema, the description is largely adequate. However, it could be improved by contrasting with getStoryWithComments or mentioning default behavior (e.g., returns story details without comments).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (id parameter with description). The tool description adds no additional meaning beyond what the schema already provides ('The ID of the story'). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single story by ID' clearly states the verb (get), resource (story), and identifier method (by ID), distinguishing it from siblings like getStories (plural) and getStoryWithComments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like getStories or getStoryWithComments. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a story with its comments
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the story |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether comments are top-level only or include nested replies, if the tool is read-only, or any rate limits. The name implies a combined result but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it could be slightly expanded to include key behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving a story with its comments (likely nested) and the absence of an output schema, the description is too brief. It does not explain the response format or pagination behavior, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the only parameter 'id' is already provided ('The ID of the story'), and the tool description does not add any additional meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a story along with its comments, which is a specific verb-resource pair. It distinguishes from siblings like getStory (story only) and getComments (comments only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives like getStory plus getComments, or how it handles nested comments. The agent has no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user profile by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral details like error handling or rate limits. However, for a simple read operation, the minimal disclosure is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one required parameter, no output schema), the description is mostly adequate. It could mention what a user profile contains, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'id' is described in the schema as 'The ID of the user'. The description merely echoes this, adding no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'user profile', with the parameter 'by ID'. It distinguishes from sibling tools like getComment and getStory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as getUserSubmissions or search. The description only states what it does, not the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's submissions
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Get a user's submissions' without revealing whether the operation is read-only, what side effects occur, any rate limits, or what happens with invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with one sentence. While it is concise, it lacks substance and fails to provide value beyond a basic label. It could be improved by adding more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It does not explain what constitutes a 'submission', the expected output format, pagination, or error handling, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter 'id', which already has a description. The tool description adds no additional meaning or context beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a user's submissions' uses a specific verb ('Get') and resource ('user's submissions'), clearly indicating what the tool does. However, it does not differentiate from siblings like getComments or getStories, which also retrieve user-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or any justification for selecting this tool over sibling tools like getUser or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stories and comments on Hacker News
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| type | No | The type of content to search for | all |
| page | No | The page number | |
| hitsPerPage | No | The number of results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the tool searches, without mentioning pagination behavior, ordering, rate limits, or what happens with no results. This leaves key behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It efficiently conveys the core functionality without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is too minimal. It does not explain search mechanics (e.g., full-text search, ordering), result expectations, or how to effectively use parameters like type and pagination. It lacks completeness for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 description adds no extra meaning beyond the schema; it merely restates the tool's purpose. Parameter details (page, type, hitsPerPage) are already adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for stories and comments on Hacker News' clearly states the action (search) and target (stories and comments on Hacker News). It effectively distinguishes from sibling tools like getStories, findAskHN, etc., which are more specific retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like getStories, findAskHN, or extractStartupInsights. It lacks context about when a general search is appropriate versus more targeted queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
getCommentgetCommentsgetCommentTreegetStoriesgetStorygetStoryWithCommentsgetUsergetUserSubmissionssearchScored across 9 tools
Most tools have distinct purposes, but there is some overlap between getComments, getCommentTree, and getStoryWithComments, which all retrieve comments for stories in slightly different formats. This could cause confusion for an agent about which to use for a given scenario, though the descriptions clarify the differences.
All tool names follow a consistent verb_noun pattern with camelCase (e.g., getComment, getStories, search). The naming is predictable and readable throughout the set, with no deviations in style or convention.
With 9 tools, this server is well-scoped for interacting with Hacker News, covering core resources like stories, comments, and users. Each tool has a clear role, and the count is neither too sparse nor bloated for the domain.
The toolset provides comprehensive read-only coverage for Hacker News, including stories, comments, users, and search. However, it lacks write operations (e.g., posting stories or comments), which might be expected for a full API but are not essential for basic interaction, leaving a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browse Hacker News feeds, threads, and user profiles with full-text search.
Hacker News MCP — search and retrieve stories from Hacker News
Your portable context layer — load it into any AI.
HN front-page, Algolia full-text search, and Show HN launch tracker.