Skip to main content
Glama

libredesk_help_center

Create and manage help centers, collections, and their settings, themes, and locales. List, inspect, reorder, and analyze search insights to organize public knowledge base content.

Instructions

Manage help centers and their collections. Undocumented API.

Actions:

  • list(): List all help centers.

  • get(id): Get one help center with all settings and theme.

  • locales(): List the locale codes a help center can use.

  • tree(id, ...): Collections and articles of a help center as a tree, without content.

  • insights(id): Top and zero-result search terms of the public help center.

  • create(name, slug, page_title, ...): Create a help center.

  • update(id, ...): Change only the given settings of a help center.

  • collection_list(help_center_id): List the collections of a help center.

  • collection_create(help_center_id, name, ...): Create a collection in a help center.

  • collection_update(help_center_id, id, ...): Change only the given fields of a collection.

  • collection_reorder(help_center_id, order): Sort many collections at once.

Input Schema

NameRequiredDescriptionDefault
idNoHelp center id. For collection_update: Collection id.
iconNoLucide icon name, for example "rocket".
nameNoHelp center name. For collection_create, collection_update: Collection name.
slugNoURL slug (/hc/<slug>): unique; a-z, 0-9, - and _; not articles, search, api, sitemap.xml.
orderNoMap of collection id to position, for example {"3":0,"5":1}.
themeNoBranding object such as {"color":"#1f93ff"}. Replaces the whole theme: send the full object from get.
actionYesAction.
localeNoLocale code, for example "en". For tree: Only this locale; omit for all.
profileNoStored profile to use; omit for the default.
templateNoPage layout, "classic" by default.
custom_jsNoExtra JavaScript for the public pages.
parent_idNoParent collection id (max 3 levels); null for top level.
custom_cssNoExtra CSS for the public pages.
page_titleNoTitle of the public pages.
sort_orderNoPosition among siblings, lowest first.
descriptionNoShort text under the collection name.
custom_domainNoOwn domain origin such as "https://help.example.com"; "" removes it.
default_localeNoDefault locale code (from locales); "en" when unset.
help_center_idNoHelp center id.
allowed_localesNoLocale codes (from locales) content can use; ones with articles cannot be removed.
meta_descriptionNoSEO description, up to 500 characters.
livechat_inbox_idNoLive chat inbox for the public chat widget; null removes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations mark it readOnlyHint=false / destructiveHint=false, but the tool bundles read actions (list, get, tree, insights) with mutating ones (create, update, collection_reorder) under a single non-readOnly hint, and the description never disambiguates which actions write. It does add useful behavioral detail like 'Change only the given fields' and flags the API as undocumented, but omits side effects such as custom_domain pointing public traffic at a new origin.

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 a one-line purpose, then a scannable action digest where each bullet earns its place. 'Undocumented API' is a useful caveat, though the ellipses shorten lines at the cost of the parameter-to-action mapping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-action, 22-parameter tool with no output schema and no per-action schema discrimination, the description underspecifies which optional parameters belong to create versus update versus collection_create. Return shape is only hinted at ('with all settings and theme'), and there is no coverage of mutation side effects or failure modes.

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 would be 3, but the action signatures (tree(id, ...), collection_reorder(help_center_id, order)) map parameters to the actions that accept them — information the flat schema cannot convey since it has no per-action discrimination. The '...' placeholders leave the full mapping incomplete, keeping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the resource domain (help centers and their collections) and the action enumeration makes the tool's scope concrete enough to separate it from libredesk_articles and other siblings. It stops short of explicitly pointing at a sibling for article editing, which is the only missing piece for a 5.

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

Usage Guidelines3/5

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

The per-action list implies when each action applies (e.g. tree vs get, collection_reorder vs collection_update), and 'Change only the given settings' signals partial updates. However, there is no explicit guidance on choosing this tool over libredesk_articles or libredesk_lookup, and no stated prerequisites such as needing an existing help center before creating a collection.

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