Skip to main content
Glama

Get item thread

get_item_thread

Retrieve Hacker News stories with their comment threads using item IDs, controlling thread depth and comment limits for focused analysis.

Instructions

Fetch a Hacker News story and its comment thread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemIdYes
depthNo
maxChildrenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
threadYes

Implementation Reference

  • The handler implementation for the 'get_item_thread' tool.
    handler: async ({ itemId, depth, maxChildren }, context) => {
      await context.log("info", `Fetching Hacker News thread ${itemId}`);
      return {
        thread: await this.client.getThread({ itemId, depth, maxChildren }),
      };
    },
  • The tool registration for 'get_item_thread' in the HackerNewsServer class.
    this.registerTool(
      defineTool({
        name: "get_item_thread",
        title: "Get item thread",
        description: "Fetch a Hacker News story and its comment thread.",
        inputSchema: {
          itemId: z.number().int().nonnegative(),
          depth: z.number().int().min(1).max(6).default(2),
          maxChildren: z.number().int().min(1).max(50).default(20),
        },
        outputSchema: {
          thread: threadSchema,
        },
        handler: async ({ itemId, depth, maxChildren }, context) => {
          await context.log("info", `Fetching Hacker News thread ${itemId}`);
          return {
            thread: await this.client.getThread({ itemId, depth, maxChildren }),
          };
        },
        renderText: ({ thread }) => `${thread.title} with ${thread.replies.length} top-level replies.`,
      }),
    );
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. While 'Fetch' implies a read-only operation, the description does not confirm idempotency, error handling for invalid itemIds, rate limits, or the hierarchical structure of the returned thread despite the existence of an 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of a single, efficient sentence with no redundant or wasted words. It is appropriately front-loaded with the core action. However, the extreme brevity contributes to insufficient coverage of other dimensions.

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 three undocumented parameters, no annotations, and the complexity of retrieving hierarchical comment threads, the description is inadequate. It fails to explain critical parameters like depth and maxChildren, which control the shape of the returned data, leaving significant gaps despite the existence of an output schema.

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

Parameters2/5

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

Schema description coverage is 0%, meaning none of the three parameters (itemId, depth, maxChildren) are documented in the schema. The description fails to compensate by explaining these parameters—particularly what 'depth' and 'maxChildren' control regarding comment nesting and pagination limits. Only the implied necessity of an identifier can be inferred.

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 verb (Fetch) and resource (Hacker News story and comment thread). It implicitly distinguishes from siblings: get_top_stories retrieves a list without specific thread details, and search_stories performs queries, whereas this retrieves a specific item by ID with its full discussion thread. However, it lacks explicit differentiation guidance.

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 the alternatives (get_top_stories or search_stories). It does not mention prerequisites such as needing a valid Hacker News item ID, nor does it indicate when a user might prefer this over browsing top stories.

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/Markgatcha/universal-mcp-toolkit'

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