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?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't specify whether this is a read-only operation, what happens if the ID doesn't exist, authentication requirements, rate limits, or return format. While 'Get' implies retrieval, critical behavioral traits are undocumented.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information, making it easy for an agent to parse quickly.
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 tool with no annotations and no output schema, the description is insufficiently complete. It lacks details on error handling, return values, authentication, and how it differs from sibling tools. Given the context of multiple sibling retrieval tools, more differentiation and behavioral context are needed for effective agent use.
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 coverage is 100%, with the 'id' parameter fully documented in the schema. The description adds no additional semantic context beyond implying the ID is used to retrieve a specific comment, which the schema already covers. This meets the baseline for high schema coverage.
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 action ('Get') and resource ('a single comment by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'getComments' or 'getCommentTree', which would require more specific scope information to earn a perfect score.
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 'getComments' (for multiple comments) or 'getCommentTree' (for hierarchical comments). There's no mention of prerequisites, error conditions, or typical use cases, leaving the agent with minimal contextual direction.
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?
With no annotations, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, how comments are ordered, pagination details, error handling, or rate limits. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. Every word earns its place, but it's under-specified rather than concise.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't cover return values, error cases, or how to handle the limit parameter effectively. For a tool fetching comments, more context on output format and usage is needed to be 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 description coverage is 100%, so the schema already documents both parameters (storyId and limit) fully. The description adds no meaning beyond what the schema provides—it doesn't explain parameter interactions, default behavior for limit, or additional context. Baseline 3 is appropriate when the schema does the heavy lifting.
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 comments for a story' states the basic action (get) and resource (comments for a story), but it's vague about scope and doesn't distinguish from siblings like getComment, getCommentTree, or getStoryWithComments. It lacks specificity about what kind of comments or how they're returned.
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 getCommentTree (for hierarchical comments) or getStoryWithComments (which might include story details). The description implies usage for fetching comments but offers no context about prerequisites, exclusions, or comparison to sibling tools.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify permissions, rate limits, pagination, or what a 'comment tree' entails structurally. This leaves significant behavioral gaps for an 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?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what a 'comment tree' returns (e.g., nested structure, fields included), which is critical for a tool with siblings that handle comments differently. This leaves the agent with insufficient context for effective use.
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% description coverage, with 'storyId' documented as 'The ID of the story'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 action ('Get') and resource ('comment tree for a story'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getComment' or 'getComments', which likely retrieve individual or multiple comments rather than a hierarchical tree structure.
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. With siblings like 'getComment', 'getComments', and 'getStoryWithComments', there's no indication of when this specific tree retrieval is appropriate, leaving usage context unclear.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention pagination behavior, rate limits, authentication requirements, or what format/structure the returned stories have. For a tool fetching multiple items, this leaves significant behavioral gaps.
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, efficient sentence with zero wasted words. It's appropriately sized for this tool's complexity and front-loads the essential information about what the tool does.
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 no annotations and no output schema, the description is incomplete for a tool that fetches multiple items. It doesn't explain what 'stories' are in this context, what fields they contain, how results are ordered/paginated, or any error conditions. The description alone leaves too many contextual gaps.
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 documents both parameters thoroughly. The description mentions 'by type' which aligns with the 'type' parameter but adds no additional semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 resource ('multiple stories'), specifying the action and target. It distinguishes the tool by mentioning story types, but doesn't explicitly differentiate from siblings like 'getStory' or 'getStoryWithComments' beyond the plural 'multiple' aspect.
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 'getStory', 'getStoryWithComments', or 'search'. It mentions story types but doesn't explain why one would choose this tool over others for fetching stories, leaving usage context implicit at best.
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 provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 perfectly concise at just five words, front-loading the essential information with zero wasted words. Every element ('Get', 'single story', 'by ID') earns its place in communicating the core functionality efficiently.
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 is insufficiently complete. It doesn't explain what format the story returns in, whether it includes metadata, how errors are handled, or any behavioral constraints. For a data retrieval tool with no structured output documentation, more contextual information is needed.
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 coverage is 100%, with the single parameter 'id' clearly documented as 'The ID of the story'. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
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 action ('Get') and resource ('a single story by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getStoryWithComments' or 'getStories', which would require more specific scope information to earn a perfect score.
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 'getStoryWithComments' or 'getStories'. There's no mention of prerequisites, context, or comparative use cases, leaving the agent with insufficient information to make optimal tool selection decisions.
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?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It lacks details on permissions, rate limits, error handling, or whether comments are paginated/nested. For a read operation without annotations, this is insufficient behavioral disclosure.
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, clear sentence with zero wasted words. It is appropriately sized for a simple tool and front-loads the core functionality effectively.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'with its comments' entails (e.g., comment structure, limits, ordering) or the return format, leaving significant gaps for a tool that combines story and comment 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?
Schema description coverage is 100%, so the schema already documents the 'id' parameter fully. The description adds no additional meaning about the parameter beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 resource ('a story with its comments'), making the purpose understandable. It distinguishes from 'getStory' by specifying inclusion of comments, but doesn't differentiate from other comment-related siblings like 'getCommentTree' or 'getComments'.
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 about when to use this tool versus alternatives like 'getStory' (for story only) or 'getCommentTree' (for hierarchical comments). The description implies it retrieves both story and comments together, but offers no explicit comparison or usage 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 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?
With no annotations provided, the description carries full burden but only states the basic operation without disclosing behavioral traits. It doesn't mention authentication needs, rate limits, error handling, or what happens if the ID is invalid, which are critical for a tool that fetches user data.
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, clear sentence with zero wasted words, making it easy to parse and front-loaded with essential information. It efficiently conveys the core purpose without unnecessary elaboration.
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 is incomplete for a tool that retrieves user data. It doesn't explain what a 'user profile' includes, potential return values, or error scenarios, leaving significant gaps in understanding how to use the tool effectively.
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 coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional meaning beyond the schema, such as ID format or examples, so it meets the baseline for high schema coverage.
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 action ('Get') and resource ('user profile by ID'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'getUserSubmissions' or 'search', which could retrieve user-related data differently, so it doesn't reach the highest score.
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 'getUserSubmissions' or 'search' for user-related queries. It lacks context about prerequisites or exclusions, leaving usage decisions ambiguous.
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?
With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. It doesn't indicate whether this is a read-only operation (implied by 'Get' but not explicit), what format the submissions are returned in, whether there's pagination, authentication requirements, rate limits, or error conditions. The description adds almost no behavioral context beyond the basic operation.
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 extremely concise - a single four-word phrase that communicates the core function without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration or redundant phrasing.
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 tool with no annotations, no output schema, and minimal description, this is incomplete. The description doesn't explain what 'submissions' means in this context, what data is returned, or how this differs from related sibling tools. While the tool has only one parameter (well-documented in schema), the overall context for proper tool selection and usage is inadequate.
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% description coverage, with the single parameter 'id' clearly documented as 'The ID of the user'. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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' clearly states the verb ('Get') and resource ('user's submissions'), making the basic purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'getUser' or 'getStories' - it's unclear whether submissions are different from stories or comments, or what type of content 'submissions' refers to specifically.
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. With sibling tools like 'getUser', 'getStories', 'getComment', and 'search', there's no indication whether this tool retrieves a specific type of content, whether it's more comprehensive than 'getStories', or what distinguishes 'submissions' from other content types. The agent must infer usage from the tool name alone.
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?
No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits like pagination behavior (implied by 'page' and 'hitsPerPage' parameters but not explained), rate limits, authentication needs, or what the output looks like. This is inadequate for a tool with multiple parameters and no output schema.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the search functionality, result format, or how parameters interact, leaving significant gaps for the agent to infer behavior. This is insufficient for effective tool selection and invocation.
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 fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining search syntax, result ordering, or default behaviors. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 action ('Search for') and target resources ('stories and comments on Hacker News'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getStories' or 'getComments', which appear to retrieve content without searching.
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. With sibling tools like 'getStories' and 'getComments' available, there's no indication of whether this is for filtered retrieval, keyword-based search, or other use cases, leaving the agent to guess based on tool names alone.
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. Dates show when Glama detected each change.
getCommentgetCommentsgetCommentTreegetStoriesgetStorygetStoryWithCommentsgetUsergetUserSubmissionssearchMost 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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devabdultech/hn-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server