@isteam/hackernews-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct resource: story lists by category, individual story retrieval, search, user profiles, and comments. Even with multiple story list tools, the category names (top, new, best, ask, show, job) clearly differentiate them.
Naming Consistency4/5
All tool names use snake_case, but there is a slight inconsistency: list tools are noun phrases (e.g., top_stories) while retrieval tools use get_ (e.g., get_story). However, the pattern is predictable and readable, with no mixed conventions.
Tool Count5/5
10 tools is well-scoped for a Hacker News reader. Each tool serves a clear purpose in covering story lists, individual stories, comments, user profiles, and search, without unnecessary duplication.
Completeness4/5
The read-only surface is fairly complete: it offers all major story categories, specific story retrieval, comments, user info, and search. Minor gaps include lack of direct item retrieval for non-story items or user submission history, but these are not critical for the core use case.
Average 3.6/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It only states 'Get Ask HN stories,' implying a read operation but provides no details on sorting, pagination, rate limits, or response structure. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is under-specified, lacking valuable context. It is essentially a one-liner that does not fully earn its place by helping an agent decide or invoke correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity and schema coverage, a short description might suffice, but the absence of usage guidance, return value description, or behavioral notes makes it incomplete for a tool with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameter (limit), so description need not add detail. The description adds no parameter-specific meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides a clear verb ('Get') and resource ('Ask HN stories'), which distinguishes from sibling story tools like top_stories or show_stories. However, it is terse and doesn't elaborate on scope or returned data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or exclusions. The description simply restates the function without contextualizing among related story-fetching endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states the core action without revealing ordering, pagination, default limits, or any side effects. Since it is a read operation, one might infer safety, but the lack of explicit behavioral detail leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no wasted words. It is front-loaded and easy to parse. However, it is so terse that it borders on being a label rather than a structured description, which is why it does not receive a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should at least hint at what the tool returns (e.g., a list of Show HN stories, order, or count). It does none of this. While the tool is simple, the description still feels incomplete because it leaves return value and default behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'limit', including a description, default, min, and max. The tool description adds no additional semantic context beyond what the schema already states, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Show HN stories' uses a specific verb ('Get') and resource ('Show HN stories'), which clearly distinguishes it from sibling tools like top_stories, new_stories, and ask_stories. However, it is minimal and reads more like a title than a functional explanation, so it loses a point for not elaborating on what 'Show HN' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention that it should be used specifically for Show HN posts, nor does it contrast with sibling tools such as top_stories or search. Users must infer usage solely from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states what the tool does, but does not mention ordering, default limit, pagination, response format, or any side effects. This minimal transparency is insufficient for a tool with no structured safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly communicates the core function without redundancy, making it an example of effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides a basic understanding but lacks details on the return structure or how results are ordered. Without an output schema, the description should more fully explain what 'stories' includes, leaving a minor gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter 'limit' with description, default, and constraints. The tool description adds no additional parameter context, so the baseline score of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets highest-voted stories on Hacker News. The verb 'Get' and resource 'highest-voted stories' are specific, but it does not explicitly differentiate from the sibling tool 'top_stories', making the purpose slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'top_stories' or 'new_stories'. It lacks any mention of context or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action without explaining return format, ordering, potential rate limits, or what 'top' means. This is insufficient for a tool with no safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded and contains no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, but the description lacks details on return values or ordering. It is minimally adequate but leaves room for ambiguity about what 'top stories' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the 'limit' parameter includes a clear description. The description adds no additional parameter context, which aligns with 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current top stories on Hacker News' uses a specific verb (Get) and clearly identifies the resource (top stories on Hacker News). It also distinguishes itself from sibling tools like new_stories and best_stories by specifying 'top'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 how it differs from new_stories or best_stories, nor any preconditions for using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It states the return fields, which is helpful, but it does not mention what happens for missing or invalid IDs, nor any error behavior or response format. The verb 'Get' implies read-only, but additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that immediately conveys the action, resource, scope, and expected output fields. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description adequately lists the returned fields and input requirement. It is slightly incomplete in not addressing not-found or error cases, but overall it provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', which is described as 'Hacker News story ID'. The tool description adds no further semantics beyond that, such as constraints on the value or formatting, so it does not exceed the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the resource ('Hacker News story'), and scopes it by 'ID'. It also lists the returned fields (title, URL, score, text), which clearly distinguishes it from sibling list/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies that the tool should be used when a story ID is known, but the description does not explicitly state when to use it versus siblings like search or top_stories. No alternatives or exclusions are mentioned, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It tells what fields the profile includes but does not mention error cases (e.g., nonexistent username) or response format. This is adequate for a simple read operation but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose and includes relevant detail without fluff. Every part contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is mostly complete. It explains what the tool does and what the profile contains. It could add a note about handling unknown users, but given the simplicity, it is not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter 'username' with 'HN username', so schema coverage is 100%. The description adds context about the returned profile fields, but not additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('Hacker News user profile'), and specifies the profile contents (karma, about, member since). This distinguishes it from sibling tools like story fetchers and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicitly stated. There is no direct mention of when to use this tool versus alternatives, nor any exclusions, but the focus on user profile makes the use case reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. The word 'Get' implies a read-only operation, which is a positive signal, but the description does not disclose other behavioral traits such as ordering, pagination, or whether it returns all job postings or only recent ones. It provides minimal but non-misleading context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without any redundant or irrelevant information. It is front-loaded and every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is largely complete. It identifies the source and category, and the schema covers the only parameter. However, it lacks explicit context about how this relates to sibling story-list tools or what 'job postings' precisely entails (e.g., the 'jobs' item type), which would slightly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with full description coverage (100%). The description itself does not mention the limit parameter, but since the schema already documents its meaning and constraints, the baseline score of 3 is appropriate. The description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get job postings from Hacker News'. It uses a specific verb ('Get') and resource ('job postings'), which distinguishes it from sibling tools like top_stories, ask_stories, and show_stories. The purpose is unambiguous and directly actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the job posting category, but it does not explicitly state when to use this tool versus alternatives like top_stories or new_stories. There is no mention of exclusions or alternative tools, so the guidance is only implied through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does add meaningful behavioral context by disclosing that comments are 'threaded' and 'depth-limited', which is beyond a simple 'get comments'. However, it doesn't mention other behaviors like whether pagination or rate limits apply, or the response format, so it's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly and efficiently conveys the tool's purpose and key constraints. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple read tool with full parameter descriptions and no output schema, the description plus schema adequately cover selection and invocation. It could be more complete by mentioning the response shape or what happens with invalid story IDs, but given the tool's simplicity, it's close to fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema already provides (e.g., depth is max reply depth, limit is top-level comments). It doesn't compensate or enrich the parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get comments') and the resource ('on a Hacker News story'), and adds specific qualifiers ('threaded, depth-limited'). This distinguishes it from sibling tools like get_story (which retrieves the story itself) and the various story list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need comments for a specific story. It doesn't explicitly mention alternatives or exclusions, but the resource specificity provides clear context. No explicit when-not guidance is given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a retrieval operation ('Get') and the resource type, but it only provides minimal behavioral insight, lacking explicit mention of output format or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It directly communicates the tool's purpose without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and no output schema, the description is adequate. However, it could mention the return format (e.g., list of story objects) to be more complete, so it falls short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'limit' parameter, including default, range, and explanation. The description itself adds no parameter information, so the baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get newest stories on Hacker News', using a specific verb and resource. It clearly distinguishes from sibling tools like top_stories and best_stories by emphasizing 'newest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need the most recent stories. However, it does not explicitly mention alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds context about the Algolia backend and sorting options but does not disclose non-obvious behaviors such as rate limits, pagination, or whether it is strictly read-only. It is not misleading, just minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description provides sufficient context about scope and sorting, though it omits any mention of result shape or pagination. Still, the core usage is clear and the schema covers the parameters well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic meaning by reinforcing the sort parameter ('relevance or date sorting') and the type parameter ('stories and comments'), clarifying what these enums represent beyond their raw definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching Hacker News stories and comments via Algolia with full-text search and relevance/date sorting. This distinguishes it from sibling list tools like top_stories and get_story, which are about browsing specific categories or fetching individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword-based search across stories and comments but does not explicitly state when to use it versus alternatives like top_stories or get_user. It provides context (full-text search) but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hackernews-mcp MCP server](https://glama.ai/mcp/servers/isteamhq/hackernews-mcp/badges/card.svg)](https://glama.ai/mcp/servers/isteamhq/hackernews-mcp)

Score Badge

Copy to your README.md:

[![hackernews-mcp MCP server](https://glama.ai/mcp/servers/isteamhq/hackernews-mcp/badges/score.svg)](https://glama.ai/mcp/servers/isteamhq/hackernews-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/isteamhq/hackernews-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server