unofficial-HackerNews-MCP-CLI

Get comments

get_comments

Read-onlyIdempotent

Fetch threaded comment replies for any Hacker News story or comment, with configurable nesting depth and plain-text output.

Instructions

Get the threaded comment tree for an item.

Each comment includes a nested replies list bounded by max_depth and max_per_level. Comment text is HTML unless strip_html is set.

Input Schema

TableJSON Schema

Name	Required	Description
`offset`	No	Skip this many top-level comments.
`item_id`	Yes	Id of the story or comment to expand.
`max_depth`	No	Reply nesting depth (0 = top-level comments only).
`strip_html`	No	Return plain text instead of HTML in comment bodies.
`max_per_level`	No	Max comments to expand per level.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Sep 21, 2026

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Skip this many top-level comments.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / strip_html

Added value: +{
+  "default": false,
+  "description": "Return plain text instead of HTML in comment bodies.",
+  "type": "boolean"
+}

Changed4 schema fields changedv0.2.0Sep 7, 2026

addedOutput schema / $defs

Added value: +{
+  "Comment": {
+    "additionalProperties": true,
+    "description": "A comment in a threaded discussion, with its nested replies.\n\nHackerNews comments may be deleted (``deleted``/``dead``) yet still carry\nan id. Extra API fields are always allowed so parsing never breaks.",
+    "properties": {
+      "by": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "The comment's author."
+      },
+      "dead": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "True if the comment is dead."
+      },
+      "deleted": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "True if the comment is deleted."
+      },
+      "hn_url": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Canonical HackerNews discussion link.",
+        "readOnly": true
+      },
+      "id": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "The comment's id, if present."
+      },
+      "kids": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "integer"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "The ids of the comment's replies, in display order."
+      },
+      "replies": {
+        "description": "The comment's expanded child replies.",
+        "items": {
+          "$ref": "#/$defs/Comment"
+        },
+        "type": "array"
+      },
+      "text": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "The comment body (HTML)."
+      },
+      "time": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Creation date, in Unix time."
+      }
+    },
+    "required": [
+      "hn_url"
+    ],
+    "type": "object"
+  }
+}

addedOutput schema / properties / result / items / $ref
```
Added value: +"#/$defs/Comment"
```
removedOutput schema / properties / result / items / additionalProperties
```
Removed value: -true
```
removedOutput schema / properties / result / items / type
```
Removed value: -"object"
```

First observedv0.1.0Jul 14, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those hints: replies are nested and bounded by max_depth and max_per_level, and comment text defaults to HTML unless strip_html is set. This clarifies output-shaping behavior that annotations cannot convey.

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?

Two tight sentences: the first states the primary purpose, the second delivers the key behavioral details. There is no filler, repetition of schema data, or redundant phrasing; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the input schema covers all parameter details, the description needs only to convey the core purpose and non-obvious behavior. It covers the threaded nature, bounding limits, and HTML default, leaving an agent well-equipped to select and invoke the tool correctly.

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 description coverage is 100%, establishing a baseline of 3, and the description adds value by explaining the effect of max_depth, max_per_level, and strip_html on the returned comment tree and text format. Offset and item_id semantics remain in the schema, but the description meaningfully connects parameters to behavior.

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 states a specific verb ('Get') and resource ('threaded comment tree for an item'), immediately distinguishing it from sibling tools that retrieve items, stories, users, or updates. The qualifier 'threaded' adds precision beyond the name alone, so an agent can tell this tool apart from get_item for comment-related needs.

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 intended use case is implied: call this tool when you want comments for an item rather than items or stories. However, the description does not explicitly state when to prefer get_comments over get_item, whether get_item already returns some comment data, or any exclusions. The guidance is adequate but inferred from the name and resource scope.

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

Deploy Server