Skip to main content
Glama

Get HelpCenter Article Comments

helpcenter_get_article_comments
Read-onlyIdempotent

Read one article's comment conversation, threaded — replies nested under the comment they answer, to any depth.

Read-only. Use this when the question is about a specific article ("what are people confused about on the SSO page?"); use helpcenter_list_comments when it is about the help center as a whole.

PRIVACY — identical to helpcenter_list_comments:

  • Emails are REDACTED unless include_email is set (write-scoped key only); an absent 'email' does not mean the reader had none.

  • IP addresses are NEVER returned.

  • Internal team notes are excluded at EVERY nesting depth, so a thread can be shorter here than the team sees in the dashboard.

Args:

  • article_id (number, required): the article whose conversation to read.

  • status ('pending' | 'published' | 'unpublished' | 'deleted' | 'all', optional): default 'all'. Filters the WHOLE thread, not just its roots — asking for 'published' will not hand you a pending reply nested under an approved question.

  • lang (string, optional): language code. Also applies at every depth.

  • order ('asc' | 'desc', optional): default 'asc', oldest first — how a conversation reads.

  • include_email (boolean, optional): see PRIVACY above.

  • response_format ('markdown' | 'json'): default 'markdown'.

Returns: { status, article: { id, title }, comments: [ { id, comment, author, status, replies: [...] } ], meta: { threads_count, comments_count } }. threads_count counts top-level comments; comments_count counts every comment in the thread.

Errors: 404 if the article id is not in this help center; 403 for include_email on a read-scoped key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "article_id": "<article_id>"
    },
    "name": "helpcenter_get_article_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoLanguage code to filter by.
orderNoThread order: 'asc' (default, oldest first — how a conversation reads) or 'desc'.
statusNoModeration state to filter by: 'pending' (awaiting approval — the queue), 'published' (visible to readers), 'unpublished' (rejected), 'deleted' (soft-deleted, excluded otherwise), or 'all' (default, everything except deleted).
site_idNoWhich help center to act on: an id from helpcenter_list_sites. Needed when this connection reaches more than one help center; omit it when it reaches one. Applies to this call only — pass it on every call of a task, and ask the user which help center they mean if their request does not say.
article_idYesId of the article whose conversation to read.
include_emailNoInclude the commenter's email address. Off by default and deliberately so: these are readers' personal addresses, not the help center's data. Requires a WRITE-scoped key — a read-scoped key asking for it gets 403. Leave this off unless the task actually needs to contact someone.
response_formatNoOutput format: 'markdown' for a human-readable summary or 'json' for the full structured payload.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds non-obvious behavior: emails redacted by default with an absent 'email' not implying absence, IPs never returned, internal team notes stripped at every depth, and 403/404 error conditions. It also warns that `status` filters the whole thread, not just roots — a real behavioral trap.

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?

Front-loaded with purpose and routing, then privacy, then args — a sensible hierarchy with headers. Some content duplicates the schema (defaults for `status` and `order` are restated) and the PRIVACY block is long, but each line carries operational value rather than filler.

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?

No output schema exists, yet the description documents the return shape including the nested `replies` array and the distinction between `threads_count` and `comments_count`, plus error codes. For a 7-parameter read with threading behavior, an agent has everything needed to call it and interpret results.

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 exceeds that by explaining cascading filter semantics ("asking for 'published' will not hand you a pending reply nested under an approved question") and the rationale for `order` default. It omits `site_id`, one of the seven parameters, leaving multi-help-center scope entirely to 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?

States a specific verb and resource ("Read one article's comment conversation") plus a structural property ("threaded — replies nested under the comment they answer, to any depth"). It explicitly names the sibling it is not (helpcenter_list_comments), so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use rule with a concrete example ("what are people confused about on the SSO page?") and an explicit when-to-use-other rule (helpcenter_list_comments for the help center as a whole). No inference required on scope selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources