HelpCenter.io

Delete HelpCenter Article

helpcenter_delete_article

DestructiveIdempotent

Delete an article: it moves to the help center's Trash, readers can no longer reach it, and its URL stops resolving.

DESTRUCTIVE, and reversible only by a person: the article can be restored from the dashboard's Trash (Articles -> Trash), but there is NO restore through the API or any tool here — once you delete it, it is out of your reach.

If the goal is only to take an article off the help center, prefer helpcenter_update_article with published: false. That hides it from readers just as completely, keeps it editable, and you can republish it yourself. Delete what should not exist at all — a duplicate, an article replaced by another.

Links to it from other articles break, and a change set holding it refuses to publish until that item is removed.

Args:

article_id (number, required): the article to delete.

Returns: { status: "success", message: "Article moved to trash.", article: { id, deleted_at } }.

Errors: 403 if the key is read-scoped; 404 if the article is not in this help center — or is already in the Trash.

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

Input Schema

Name	Required	Description	Default
`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 to move to Trash.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint and openWorldHint, but the description adds substantial behavior the annotations cannot convey: there is no API-level restore, recovery requires a human in the dashboard Trash, inbound links break, and a change set containing the article refuses to publish. It even documents the 403 read-scoped-key and 404 already-trashed error conditions.

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 front-loaded: the effect lands in the first sentence, the destructive/reversibility warning second, the alternative third, side effects fourth, then Args/Returns/Errors blocks. It is longer than average for a delete, but nearly every sentence carries distinct operational information; 'out of your reach' lightly restates the no-restore point.

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 destructive single-parameter mutation with no output schema, the description covers everything an agent needs: consequence, irreversibility, the safer alternative, cross-object side effects, the literal return shape, and failure modes.

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%, with site_id documented at length in the schema itself. The description only restates article_id as 'the article to delete,' adding no new constraints or formatting detail, so the baseline 3 applies.

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 (delete an article) plus the concrete effect: it moves to Trash, readers lose access, and its URL stops resolving. It also distinguishes itself from the sibling it most resembles by naming helpcenter_update_article with published: false as the non-destructive route.

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 explicit when-to-use and when-not-to-use guidance: prefer unpublish if the goal is merely to take the article offline, and reserve delete for things that should not exist (duplicates, replaced articles). It also names the alternative tool by exact name, so no inference is required.

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?