HelpCenter.io

Reply To HelpCenter Article Note

helpcenter_reply_to_article_note

Answer a private editorial note on an article — "rewrote the second paragraph and staged it for review".

Stays internal: the reply joins the team's thread in the editor and is never shown to readers. Attributed to the account the credential authenticates as; there is no author field.

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.

The natural pairing is with the staged-changes tools: revise the article with helpcenter_stage_article_changes (which readers cannot see), then say so here, then resolve. That way a human still decides what goes live.

NOT IDEMPOTENT: calling this twice posts two replies. Read the thread back with helpcenter_list_article_notes before retrying.

Args:

article_id (number, required), note_id (number, required): from helpcenter_list_article_notes.
note (string, required): the reply body, 1-5000 characters, plain text.

Returns: { status: "success", note: {...} } with the thread including your reply (each reply carries via, the API key or app it came through).

Errors: 403 'insufficient_scope' without the notes.write scope (separate from content.write, and from notes.read); 403 'notes_forbidden' if dashboard access to team comments has been lost; 404 if the note is not on this article — including when the id belongs to a READER comment, which this surface never touches.

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>",
      "note_id": "<note_id>",
      "note": "<note>"
    },
    "name": "helpcenter_reply_to_article_note"
  }
}

Input Schema

Name	Required	Description
`note`	Yes	Your reply, up to 5000 characters. Plain text. Stays internal — readers never see it.
`note_id`	Yes	Id of the note thread to answer.
`site_id`	No	Which 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_id`	Yes	Id of the article the note is on.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond annotations: highlights non-idempotency with retry guidance (read the thread back with helpcenter_list_article_notes), explains attribution comes from the credential with no author field, and enumerates specific error semantics including the separate notes.write scope and 404 for reader-comment ids.

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 and well-organized with clear sections (privacy, pairing, idempotency, args, returns, errors). Slight redundancy: the 'never shown to readers' point is stated in the opening and again in the PRIVATE paragraph, costing a bit of economy.

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?

For a non-idempotent mutation with no output schema, the definition covers return shape, error cases, scope requirements, retry behavior, and correct workflow pairing — nothing an agent needs to call it safely is missing.

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 baseline is 3; the description adds sourcing for article_id/note_id (from helpcenter_list_article_notes) and clarifies the reply body is plain text, 1-5000 characters, and internal-only. Marginal but real added value.

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 (reply) and resource (private editorial note on an article) with a concrete example, and explicitly distinguishes itself from helpcenter_reply_to_comment. An agent can tell exactly what this does and what it is not.

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 workflow: revise with helpcenter_stage_article_changes, say so here, then resolve — with a note that a human decides what goes live. It also states the exclusion clearly: never quote a note into reader-facing text or reply_to_comment.

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

All HelpCenter.io tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?