Skip to main content
Glama

List HelpCenter Article Notes

helpcenter_list_article_notes
Read-onlyIdempotent

Read the private editorial notes the help-center's team has left on an article in the HelpCenter.io editor.

This is how you pick up human feedback on a draft: each note is anchored to a specific passage, so it tells you WHICH sentence to change, not just that something is wrong.

PRIVATE — these notes are written by the help-center's own team and are never shown to readers. Use them to decide what to change in the article. Do NOT quote or paraphrase a note into any reader-facing text: not into an article body, and never into helpcenter_reply_to_comment. A note may say precisely what the team has decided NOT to say publicly.

These are NOT reader comments. Visitor comments on the published article are a different tool (helpcenter_get_article_comments) and the two never return each other's content.

Args:

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

  • include_resolved (boolean, optional): also return threads already marked done. Off by default — the question this answers is what is still being asked of the draft.

  • lang (string, optional): language code; notes are per-language like the draft.

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

Returns: { article, notes: [ { id, note, lang, anchor: { mark_id, quote, highlighted }, author, via, resolved, replies: [...] } ], meta: { threads_count, open_count, includes_resolved } }. anchor.highlighted is false once the passage was rewritten or deleted (quote still says what the note was about), or for a note that never had a highlight. via names the API key or app a note or reply came through, null for one written in the dashboard.

Errors: 403 'insufficient_scope' if the credential lacks the notes.read scope — content access does NOT imply it, and an API key holds it only if it was issued with it, so this is fixed by provisioning a new key, not by retrying. 403 'notes_forbidden' if the account behind the credential can no longer reach team comments in the dashboard. 404 if the article is not in this help center.

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_list_article_notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoLanguage code — notes are per-language, like the draft they sit on.
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 notes to read.
response_formatNoOutput format: 'markdown' for a human-readable summary or 'json' for the full structured payload.markdown
include_resolvedNoAlso return threads already marked done. Off by default: the question this answers is what is still being asked of the draft.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent and open-world hints, so the bar is lower, yet the description adds substantial context they cannot express: the private/internal nature of the content and the leakage risk, the anchor.highlighted staleness semantics, the meaning of a null via, and two distinct 403 error modes with the crucial note that content access does not imply notes.read and retrying will not fix it. That error guidance alone meaningfully changes agent behavior.

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?

Well organized and front-loaded: what it is, then privacy, then disambiguation from comments, then args, returns and errors. The privacy point is made twice in close succession ("PRIVATE — never shown to readers" and "Do NOT quote or paraphrase"), and repeating schema-documented args is mild waste, but almost every line carries real decision value.

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?

With no output schema, the description carries the full burden of the return shape and does so precisely, down to the anchor sub-fields and meta counters. Combined with explicit error semantics and sibling disambiguation, there is nothing an agent needs to call this correctly that is missing.

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 Args block largely restates the schema (include_resolved and lang wordings are near-verbatim), and it omits site_id entirely even though that parameter carries non-trivial multi-help-center routing guidance in the schema. It adds rationale ("the question this answers is what is still being asked of the draft") but no meaning the schema does not already carry.

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 the private editorial notes the team left on an article in the HelpCenter.io editor. It goes further and pins down what the resource actually is (notes anchored to a specific passage) and explicitly excludes the nearest sibling, helpcenter_get_article_comments, so the agent can discriminate without opening a 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 framing ("This is how you pick up human feedback on a draft ... Use them to decide what to change in the article") plus a hard when-not rule: do not quote or paraphrase a note into reader-facing text, and never into helpcenter_reply_to_comment. It names the alternative tool for visitor comments and states the two never return each other's content, which is exactly the routing information an agent needs.

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