Skip to main content
Glama
Sign In

HelpCenter.io

by io.helpcenter
OverviewDiscussionsAdmin

Moderate HelpCenter Comment

helpcenter_moderate_comment
DestructiveIdempotent

Approve or reject a reader comment. Requires a write-scoped API key.

'published' approves it and shows it to readers. 'unpublished' rejects it — the comment leaves the help center but is not destroyed, so this is the reversible way to take something down.

What this tool deliberately CANNOT do: edit the body. Rewording somebody else's words under their name is a dashboard action with a human looking at whose comment it is, not an API one.

Side effect worth knowing: approving a REPLY emails the person being replied to, exactly as approving it in the dashboard does. That send is idempotent per reply, so re-approving something already published mails nobody twice.

Args:

  • comment_id (number, required): from helpcenter_list_comments or helpcenter_get_article_comments.

  • status ('published' | 'unpublished', required).

Returns: { status: "success", message, comment: {...} } with the updated comment.

Errors: 403 if the key is read-scoped; 404 if the comment is not in this help center, is an internal team note (which this API never exposes or touches), or has been DELETED — a deleted comment is off the help center whatever its status says, so it must be restored from the dashboard before it can be moderated; 422 for any status other than the two above.

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": {
      "comment_id": "<comment_id>",
      "status": "<status>"
    },
    "name": "helpcenter_moderate_comment"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusYes'published' approves the comment and shows it to readers; 'unpublished' rejects it. To remove a comment entirely, that is a delete in the dashboard — this tool cannot destroy anything.
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.
comment_idYesId of the comment to approve or reject.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: write-scoped key requirement, the email side effect on approving a reply and its per-reply idempotence, and the full error taxonomy (403 read-scoped, 404 including deleted/internal-note cases, 422 bad status). This is exactly the kind of disclosure annotations cannot carry. One nuance: destructiveHint=true while the text stresses 'this tool cannot destroy anything' — the description is clarifying that the mutation is a reversible state change rather than a hard delete, which is a useful reconciliation rather than a contradiction.

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?

Purpose is front-loaded in the first sentence, and the subsequent blocks (reversibility, non-capability, side effect, args, returns, errors) are each a coherent unit. It runs long for a two-required-parameter tool, and the emphatic phrasing ('deliberately CANNOT', 'Side effect worth knowing') is slightly editorial, but nearly every sentence carries decision-relevant information.

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 correctly supplies the return shape, and for a mutating moderation tool it covers permissions, side effects, irreversibility boundaries and every expected error code. An agent has everything needed to decide, call, and recover from failure without consulting other sources.

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 schema already documents status, comment_id and site_id thoroughly, making baseline 3 appropriate. The description adds one genuinely new piece of meaning — that comment_id should come from helpcenter_list_comments or helpcenter_get_article_comments — but never mentions site_id, leaving the multi-help-center parameter entirely to the schema. That provenance hint keeps it above a bare baseline but not high.

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?

Opens with a specific verb pair and resource: 'Approve or reject a reader comment.' It immediately distinguishes itself from the other comment tool (helpcenter_reply_to_comment) by scoping to moderation of an existing comment, and the status semantics ('published' approves, 'unpublished' rejects) pin down exactly what the two outcomes mean.

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

Usage Guidelines4/5

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

Gives clear when-to-use guidance for both enum values, states the reversible path for takedowns, and explicitly rules out a nearby use case ('What this tool deliberately CANNOT do: edit the body') with the correct alternative (dashboard). It also tells the agent where comment_id comes from. What it lacks is an explicit contrast with sibling helpcenter_reply_to_comment, which an agent could plausibly confuse with moderating.

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

All HelpCenter.io toolsInspect
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