This Model Context Protocol (MCP) server provides comprehensive access to HackerNews through the Algolia API, enabling AI assistants to search, browse, and analyze content via natural language queries.
Core Capabilities:
• Advanced Search - Find stories, comments, and polls by keyword with complex filtering: tag filtering (story, comment, poll, show_hn, ask_hn, author-specific), numeric operators (<, <=, =, >=, >) for points/comments/dates, AND/OR logic, and pagination (1-1000 results per page)
• Front Page Access - Retrieve currently trending posts ranked by HackerNews' algorithm
• Latest Posts - Monitor newest content in chronological order with optional content type filtering
• Item Details - Fetch complete metadata for any item ID including full nested comment trees, titles, URLs, text, points, authors, and timestamps
• User Profiles - View public profile information including karma scores, bios, account creation dates, and username validation
Key Features: Real-time data access, pagination support across all operations, date range queries using Unix timestamps, and the ability to combine multiple filters simultaneously.
Provides access to HackerNews content through the Algolia HackerNews API, enabling search of posts and comments, retrieval of front page stories, latest posts, item details with nested comment trees, and user profile information
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., "@HackerNews MCP Server show me the top stories on HackerNews right now"
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.
Connect your AI assistant to HackerNews! This Model Context Protocol server gives Claude, GitHub Copilot, and other AI assistants the ability to search HN, read discussions, and explore user profiles.
🔍 Search Posts - Find stories, comments, and discussions by keyword with advanced filters
📰 Front Page - Access currently trending posts
🆕 Latest Posts - Monitor newest content in real-time
💬 Item Details - Retrieve full posts with nested comment trees
👤 User Profiles - View author information, karma, and bios
Related MCP server: HackerNews MCP Server
Add the following MCP server configuration to your client's MCP settings:
{
"hn-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "hn-mcp-server"]
}
}Once configured, you can ask your AI assistant natural language questions like:
"What are the top stories on HackerNews right now?"
"Search HackerNews for discussions about Rust programming"
"Show me the latest AI-related posts with at least 100 points"
"Get the details and comments for HN item 38456789"
"What's the karma score for user 'pg'?"
The AI will automatically use the appropriate HackerNews tools to answer your questions.
Search HackerNews by keyword with filters for content type, points, and date range.
Example prompts:
"Search for stories about TypeScript"
"Find posts about AI with more than 200 points"
"Search for comments by author 'dang'"
Get the current HackerNews front page posts.
Example prompts:
"What's trending on HackerNews?"
"Show me the HN front page"
Get the most recent posts sorted by date.
Example prompts:
"What are the newest HackerNews stories?"
"Show me recent Ask HN posts"
Retrieve complete item details with nested comments.
Example prompts:
"Get HN item 38456789"
"Show me the discussion for this story"
View user profile information.
Example prompts:
"Tell me about HN user 'pg'"
"What's the karma for user 'tptacek'?"
Node.js 18.0.0 or higher
MCP Client - Any application that supports MCP:
Contributions are welcome! Please see CONTRIBUTING.md for details.
API Reference - Detailed API documentation
Architecture - System design and architecture
MIT License - See LICENSE for details
npm Package: https://www.npmjs.com/package/hn-mcp-server
GitHub Repository: https://github.com/wei/hn-mcp-server
HackerNews API: https://hn.algolia.com/api
MCP Documentation: https://modelcontextprotocol.io
Report Issues: https://github.com/wei/hn-mcp-server/issues
Retrieve posts currently on the HackerNews front page.
Returns stories sorted by HackerNews ranking algorithm. The front page typically contains the most popular and trending stories.
Supports:
Pagination to view beyond the first page
Customizable results per page (default: 30)
All posts are tagged with 'front_page'
Examples:
Get first page: { }
Get with custom page size: { "hitsPerPage": 50 }
Get second page: { "page": 1 }
Returns the same structure as search results with hits, pagination info, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (0-indexed, default: 0) | |
| hitsPerPage | No | Results per page (1-1000, default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it describes the sorting algorithm (HackerNews ranking), typical content (most popular/trending stories), pagination support, default and customizable results per page, and return structure. It lacks details on rate limits or error handling, but covers essential operational aspects.
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 appropriately sized and front-loaded, starting with the core purpose, followed by supporting details, examples, and return information. Every sentence adds value without redundancy, making it efficient and easy to scan for key information.
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 moderate complexity, no annotations, no output schema, and rich schema coverage, the description is largely complete. It covers purpose, behavior, parameters, and return structure, but could benefit from more explicit guidance on when to use alternatives or error handling details to be fully comprehensive.
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%, so the baseline is 3. The description adds minimal value beyond the schema by mentioning pagination and customizable results per page in general terms, but does not provide additional syntax, format, or usage nuances for the parameters beyond what the schema already documents.
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 specific action ('Retrieve posts') and resource ('currently on the HackerNews front page'), distinguishing it from siblings like 'get-latest-posts' and 'search-posts' by specifying front-page content with HackerNews ranking algorithm sorting. It explicitly mentions that all posts are tagged with 'front_page', further differentiating its scope.
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 clear context for when to use this tool (to get front-page posts sorted by popularity/trending), but it does not explicitly state when not to use it or name alternatives among sibling tools. It implies usage for paginated retrieval of front-page content without direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information about a specific HackerNews item by ID.
Returns complete item details including the full nested comment tree. Use this to:
View a story with all comments
Read a specific comment with its replies
Explore discussion threads in depth
Get complete metadata for any item
Features:
Full nested comment tree (all levels)
Complete item metadata (title, url, text, points, author, etc.)
Works for stories, comments, polls, and poll options
Includes creation time and item type
Examples:
Get story with comments: { "itemId": "38456789" }
Get specific comment: { "itemId": "38456790" }
Get poll: { "itemId": "126809" }
Note: Large comment threads (>500 comments) may take 2-3 seconds to load due to nested fetching. Returns error if item doesn't exist or has been deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | HackerNews item ID (e.g., '38456789') |
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. It does well by specifying performance characteristics ('Large comment threads (>500 comments) may take 2-3 seconds to load due to nested fetching'), error conditions ('Returns error if item doesn't exist or has been deleted'), and what the tool returns ('complete item details including the full nested comment tree'). However, it doesn't mention rate limits or authentication requirements, which would be helpful for a public API tool.
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 well-structured with clear sections (purpose, use cases, features, examples, notes) and front-loads the core purpose. While comprehensive, it could be slightly more concise by combining some bullet points or reducing redundancy between 'Features' and the opening description. Every sentence adds value, but there's minor room for tightening.
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 single-parameter read operation with no output schema, the description provides excellent context about what information is returned (full nested comment tree, complete metadata), performance characteristics, error conditions, and supported item types. The main gap is the lack of output format details (structure of returned data), which would be helpful since there's no output schema. However, it covers most other aspects well.
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 'itemId' well-documented in the schema. The description adds minimal value beyond the schema by providing examples of item IDs in the 'Examples' section, but doesn't explain parameter semantics beyond what's already in the schema description. This meets the baseline of 3 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 specific action ('Retrieve detailed information') and resource ('specific HackerNews item by ID'), distinguishing it from sibling tools like get-front-page (list of stories), get-latest-posts (recent posts), get-user (user profiles), and search-posts (search functionality). It explicitly mentions what types of items it works for (stories, comments, polls, poll options).
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 explicit guidance on when to use this tool through bullet points: 'View a story with all comments', 'Read a specific comment with its replies', 'Explore discussion threads in depth', and 'Get complete metadata for any item'. It also implicitly distinguishes from siblings by focusing on single-item retrieval rather than lists or searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the most recent HackerNews posts sorted by date.
Returns posts in chronological order (newest first), including all types of content unless filtered.
Supports:
Filter by content type using tags (story, comment, poll, show_hn, ask_hn, etc.)
Pagination to view older posts
Customizable results per page (default: 20)
Empty query to get all recent posts
Examples:
Get latest stories: { "tags": ["story"] }
Get latest comments: { "tags": ["comment"] }
Get all recent activity: { }
Get with custom page size: { "hitsPerPage": 50 }
Use this to monitor real-time HackerNews activity or find the newest content.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional filter tags (e.g., ['story'], ['comment']) | |
| page | No | Page number (0-indexed, default: 0) | |
| hitsPerPage | No | Results per page (1-1000, default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: returns posts in chronological order (newest first), includes all content types unless filtered, supports pagination, has a default page size of 20, and allows an empty query. It doesn't mention rate limits, authentication needs, or error handling, but covers the core functionality well for a read-only tool.
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 well-structured and appropriately sized. It starts with the core purpose, lists key features with bullet points, provides concrete examples, and ends with usage guidance. Every sentence adds value with no redundancy or fluff. The bullet points make it scannable 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?
For a read-only tool with 3 parameters and 100% schema coverage but no output schema, the description is quite complete. It explains what the tool does, how to use it, and provides examples. The main gap is the lack of output format details (what fields posts include), which would be helpful since there's no output schema. Otherwise, it covers the essential context well.
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 all parameters thoroughly. The description adds some value by explaining that tags filter by content type (e.g., story, comment) and providing examples, but doesn't add significant semantic meaning 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 tool's purpose: 'Retrieve the most recent HackerNews posts sorted by date.' It specifies the resource (HackerNews posts), verb (retrieve), and sorting (newest first). It also distinguishes from siblings like 'get-front-page' (which likely shows curated content) and 'search-posts' (which likely searches by keyword).
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 clear context for when to use this tool: 'Use this to monitor real-time HackerNews activity or find the newest content.' It distinguishes from 'search-posts' by focusing on recency rather than search queries. However, it doesn't explicitly state when NOT to use it or compare all alternatives (e.g., 'get-front-page' for curated content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve public profile information for a HackerNews user.
Returns user profile including karma, bio, and account creation date. Use this to:
Check user reputation (karma score)
Read user bio and about information
See when account was created
Verify user existence before searching their content
Features:
Username (case-sensitive)
Karma score (total upvotes received)
About/bio text (may contain HTML)
Account creation date (Unix timestamp)
Examples:
Get famous user: { "username": "pg" }
Check moderator: { "username": "dang" }
Verify author: { "username": "tptacek" }
Username validation:
Alphanumeric characters and underscores only
Case-sensitive
Must exist on HackerNews
Returns error if user doesn't exist or username format is invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | HackerNews username (alphanumeric + underscores, e.g., 'pg') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: case-sensitivity, username validation rules (alphanumeric+underscores), existence requirement, and error conditions. It also mentions that bio may contain HTML. However, it doesn't cover rate limits or authentication needs.
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 well-structured with clear sections (purpose, use cases, features, examples, validation, error handling) and every sentence adds value. It could be slightly more concise by combining some bullet points, but overall it's efficiently organized and front-loaded with the core purpose.
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 single-parameter read-only tool with no output schema, the description provides comprehensive context: purpose, usage guidelines, parameter details, examples, validation rules, and error conditions. The main gap is lack of output format details (structure of returned profile), but otherwise it's quite 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 baseline is 3. The description adds some value by providing username validation details (alphanumeric+underscores, case-sensitive, must exist) and examples, but doesn't significantly enhance the parameter understanding beyond what the schema already documents.
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 specific action ('Retrieve public profile information') and resource ('for a HackerNews user'), distinguishing it from sibling tools like get-item or get-latest-posts which handle posts/items rather than user profiles. It provides concrete details about what information is retrieved (karma, bio, creation date).
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 explicitly lists four specific use cases (check reputation, read bio, see creation date, verify existence before searching content), providing clear guidance on when to use this tool. It also distinguishes from siblings by focusing on user profiles rather than posts/items, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search HackerNews for stories, comments, and other content by keyword.
Supports:
Keyword search across titles, text, and authors
Tag filtering (story, comment, poll, show_hn, ask_hn, front_page, author_USERNAME)
Numeric filters for points, comments, and dates
Pagination with customizable results per page
Advanced filtering with OR logic and multiple conditions
Basic Examples:
Search for AI stories: { "query": "AI", "tags": ["story"] }
Find popular posts: { "query": "Python", "numericFilters": ["points>=100"] }
Filter by author: { "query": "startup", "tags": ["author_pg"] }
Date range: { "query": "startup", "numericFilters": ["created_at_i>1640000000"] }
Advanced Filtering Examples:
High engagement posts: { "query": "programming", "numericFilters": ["points>=100", "num_comments>=50"] }
OR logic for tags: { "query": "web", "tags": ["(story,poll)"] } - returns stories OR polls
Author with filters: { "query": "", "tags": ["author_pg", "story"], "numericFilters": ["points>=50"] }
Multiple conditions: { "query": "AI", "tags": ["story"], "numericFilters": ["points>=200", "num_comments>=100"] }
Numeric Filter Operators: < (less than), <= (less than or equal), = (equal), >= (greater than or equal), > (greater than) Numeric Filter Fields: points, num_comments, created_at_i (Unix timestamp)
Tag Syntax:
Single tag: ["story"] - only stories
Multiple tags (AND): ["story", "show_hn"] - stories that are also show_hn
OR logic: ["(story,poll)"] - stories OR polls
Author filter: ["author_USERNAME"] - posts by specific author
Returns paginated results with hits, total count, and page information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query text (minimum 1 character) | |
| tags | No | Optional filter tags (e.g., ['story'], ['comment'], ['(story,poll)'] for OR logic, ['author_pg'] for author filter) | |
| numericFilters | No | Optional numeric filters (e.g., ['points>=100'], ['num_comments>=50'], ['created_at_i>1640000000']). Multiple filters use AND logic. | |
| page | No | Page number (0-indexed, default: 0) | |
| hitsPerPage | No | Results per page (1-1000, default: 20) |
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. It effectively describes key behaviors: it's a read-only search operation (implied by 'search'), supports pagination with customizable results per page, returns paginated results with hits, total count, and page information, and explains advanced filtering logic (AND/OR). It doesn't mention rate limits or authentication needs, but covers most operational aspects well.
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 well-structured with clear sections (Supports, Basic Examples, Advanced Filtering Examples, Numeric Filter Operators, Tag Syntax, Returns). While comprehensive, it could be slightly more concise by reducing some example repetition. Every sentence adds value, and key information is front-loaded.
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 search tool with 5 parameters, 100% schema coverage, but no output schema or annotations, the description provides excellent context. It explains what the tool does, how to use parameters, provides multiple examples, describes return format (paginated results with hits, total count, page info), and covers filtering logic. The main gap is no explicit mention of error cases or rate limits.
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 significant value beyond the schema by providing detailed examples of parameter usage, explaining numeric filter operators and fields, detailing tag syntax with OR logic examples, and showing how parameters combine in practice. This goes well beyond the schema's basic descriptions.
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 searches HackerNews for stories, comments, and other content by keyword. It specifies the verb 'search' and resource 'HackerNews content', distinguishing it from sibling tools like get-front-page (specific content), get-item (single item), get-latest-posts (recent posts), and get-user (user info).
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 explicitly provides usage guidance through examples and context. It shows when to use this tool (e.g., for keyword searches, tag filtering, numeric filtering) versus alternatives like get-front-page (front page only) or get-latest-posts (recent posts without search). The examples illustrate various use cases, making it clear when this tool is appropriate.
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.
get-front-pageget-itemget-latest-postsget-usersearch-postsEach tool has a distinct purpose: get-front-page retrieves the front page, get-item fetches a specific item with comments, get-latest-posts shows recent posts, get-user provides user profiles, and search-posts enables keyword searches. There is no overlap or ambiguity in functionality.
All tool names follow a consistent verb_noun pattern with hyphens: get-front-page, get-item, get-latest-posts, get-user, and search-posts. This uniformity makes the set predictable and easy to understand.
With 5 tools, the server is well-scoped for interacting with HackerNews. It covers key areas like front page, items, recent posts, users, and search without being too sparse or overwhelming.
The tool set covers most essential HackerNews operations, including reading, searching, and user lookup. However, it lacks write operations (e.g., posting comments or stories), which might be a minor gap for full interaction, though not critical for a read-focused server.
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.
HN front-page, Algolia full-text search, and Show HN launch tracker.
Hacker News MCP — search and retrieve stories from Hacker News
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wei/hn-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server