Skip to main content
Glama
hillaryTse

HackerNews MCP Server

by hillaryTse

get_post

Retrieve complete HackerNews post details including title, author, points, URL, and the full hierarchical comment tree with nested replies and metadata.

Instructions

Retrieve full details of a specific HackerNews post by its ID. Returns the complete post data including title, URL, author, points, and the entire comment tree with nested replies. Comments are returned in hierarchical structure preserving parent-child relationships. Includes metadata like total comment count and nesting depth.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
postIdYes

Implementation Reference

  • The primary handler function for the 'get_post' tool. It validates the input using GetPostInputSchema, fetches the post data via apiClient.getPost, builds the comment tree, calculates metadata (total comments and nesting depth), and formats the response for the MCP tool protocol.
    export async function handleGetPost(args: unknown) {
      // Validate input
      const parseResult = GetPostInputSchema.safeParse(args);
    
      if (!parseResult.success) {
        throw new ValidationError("Invalid post ID", parseResult.error.errors);
      }
    
      const input: GetPostInput = parseResult.data;
    
      // Get post from API
      const post = await apiClient.getPost(input.postId);
    
      // Build comment tree (already nested from API)
      const postWithTree = buildCommentTree(post);
    
      // Calculate metadata
      const totalComments = countComments(postWithTree);
      const nestingDepth = calculateNestingDepth(postWithTree);
    
      // Format response
      const response = {
        post: postWithTree,
        metadata: {
          totalComments,
          nestingDepth,
          hasComments: totalComments > 0,
        },
        remainingQuota: apiClient.getRemainingQuota(),
      };
    
      return formatToolResponse(response);
    }
  • Zod schema for validating the input to the get_post tool, ensuring postId is a numeric string. Also exports the inferred TypeScript type.
     * Schema for get_post tool input
     */
    export const GetPostInputSchema = z.object({
      postId: z.string().regex(/^\d+$/, "Post ID must be a numeric string"),
    });
    
    export type GetPostInput = z.infer<typeof GetPostInputSchema>;
  • Tool registration in the MCP tools list, including name, description, and input schema converted to JSON schema for the protocol.
    {
      name: "get_post",
      description:
        "Retrieve full details of a specific HackerNews post by its ID. Returns the complete post data including title, URL, author, points, and the entire comment tree with nested replies. Comments are returned in hierarchical structure preserving parent-child relationships. Includes metadata like total comment count and nesting depth.",
      inputSchema: zodToJsonSchema(GetPostInputSchema),
  • src/index.ts:58-59 (registration)
    Handler dispatch registration in the main MCP server request handler switch statement, mapping 'get_post' tool calls to the handleGetPost function.
    case "get_post":
      return await handleGetPost(args);
  • API client method used by the handler to fetch the specific post data from the HackerNews Algolia API.
    async getPost(postId: string): Promise<HackerNewsPost> {
      return this.request<HackerNewsPost>(`items/${postId}`);
    }
Behavior4/5

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's a read operation (implied by 'Retrieve'), returns hierarchical comment trees with nested replies, and includes metadata like comment count and nesting depth. It doesn't mention rate limits, authentication needs, or error handling, but covers core functionality adequately.

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 appropriately sized and front-loaded, starting with the core purpose and progressively adding details about returned data and structure. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.

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 moderate complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It explains what the tool does, what it returns, and the data structure. However, it lacks details on error cases (e.g., invalid post ID) and doesn't fully compensate for the missing output schema by not specifying exact return fields beyond examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It adds meaning by specifying that the parameter is a 'post ID' for HackerNews, implying it's a numeric identifier (though not explicitly stated). This clarifies the parameter's purpose beyond the schema's pattern constraint, but doesn't detail format examples or validation rules.

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 specific action ('Retrieve full details'), resource ('HackerNews post by its ID'), and scope ('complete post data including title, URL, author, points, and the entire comment tree'). It distinguishes from siblings like get_front_page (list), get_user (user data), and search_posts (search).

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 usage context by specifying 'by its ID' and listing returned data, suggesting it's for detailed post inspection rather than browsing or searching. However, it doesn't explicitly state when to use this tool versus alternatives like get_front_page for overview or search_posts for discovery, nor does it mention prerequisites like needing a post ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/hillaryTse/hn-mcp-server'

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