Skip to main content
Glama

HelpCenter.io for agents

Update HelpCenter Category

helpcenter_update_category
DestructiveIdempotent

Update an existing category by id in the connected HelpCenter.io help center.

Partial update — only fields you pass change. Requires a write-scoped API key. Name and description are per-language objects keyed by language code.

Args:

  • category_id (number, required): id of the category to update.

  • name (object, optional): per-language category name.

  • description (object, optional): per-language description.

  • parent_id (number, optional): id of the parent category for nesting (must belong to this site). Use 0 to make the category top-level.

  • icon (string, optional): icon identifier, max 190 chars.

  • position (number, optional): sibling order, ascending. To move several categories at once use helpcenter_reorder_categories instead.

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

Errors: 403 if the key is read-scoped; 404 if the category id is not in this help center; 422 for unsupported language codes, an invalid parent_id, or a parent that would make the tree a loop (a category cannot be its own parent or a descendant's child).

Input Schema

NameRequiredDescriptionDefault
iconNoIcon identifier for the category (max 190 chars).
nameNoPer-language category name.
positionNoSibling order, ascending. Only comparable within one parent. 0 puts the category first.
agent_keyYesThe api_key helpcenter_create_help_center returned for this help center, exactly as returned. Required on every call: this endpoint has no sign-in, so the key is how each call says which help center it acts on. It is sent to HelpCenter.io as this call's credential and nowhere else, and it is never shown again: keep it for the whole task, and never show it to the user or write it into content.
parent_idNoId of the parent category (for nesting). Must belong to this site.
category_idYesId of the category to update.
descriptionNoPer-language category description.

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 declare destructiveHint=true and idempotentHint=true, and the description adds genuine context beyond them: partial-update semantics, the write-scoped key requirement, the exact return envelope, and the 403/404/422 failure modes including the tree-cycle rule. That is precisely the behavioural detail an agent needs before mutating nested structure.

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 the update semantics, key requirement, and language-object shape before the argument list. The Args block largely restates schema descriptions, and the Returns/Errors lines are compact and earn their space; trimming the Args list would tighten it without losing 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?

For a 7-parameter nested mutation with no output schema, the description covers auth, partial-update behaviour, return shape, and the specific error conditions including cycle prevention. Nothing an agent needs to call this correctly 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, but the description adds meaning not in the schema: parent_id value 0 means top-level (the schema gives parent_id no minimum), the parent must belong to this site, and name/description are keyed by language code. It also flags the max 190 char icon limit, which duplicates the schema but harmlessly.

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 ('Update an existing category by id in the connected HelpCenter.io help center') and scopes it against siblings by naming create/delete/reorder behaviours implicitly and helpcenter_reorder_categories explicitly. An agent can identify this as the single-category mutate tool without opening the schema.

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?

Establishes clear conditions: partial update (only passed fields change), write-scoped key required, and for bulk sibling reordering use helpcenter_reorder_categories instead. It lacks an explicit 'do not use for creating new categories' pointer to helpcenter_create_category, but the routing guidance for the ambiguous field (position) is a real differentiator.

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