How to organise knowledge-base categories with MCP Hub in Blesta
MCP Hub’s category tools can create a topic section, place it under an existing parent and change its description or visibility. Start by reading the current hierarchy so an assistant does not create a second category with the same purpose.
Check the editorial connection
Use a dedicated content connection with a Write ceiling, the required content area and staff permissions. The separate read-only override must permit the intended write. The company needs an active Support Manager plugin, and the bound active staff member’s group needs its Knowledge Base permission. A connection limited to selected clients cannot operate on the shared knowledge base.
Ask the assistant to List knowledge base categories before making changes. Read the returned category names, IDs, parents and visibility. A list restricted to one parent does not show the entire hierarchy.
Create the intended section
- Identify the existing parent category, or explicitly choose the top level.
- Specify the new category name and a short description of the topics it will contain.
- State the intended visibility rather than accepting a default.
- Ask the assistant to use Add a knowledge base category with that parent and visibility.
- List the parent’s categories again and verify the returned category ID, name and setting.
Choose the category’s access deliberately: the offered values are public, private, hidden and staff. Private is for signed-in clients, hidden is reachable by link, and staff is staff-only. Hidden is therefore not a substitute for staff-only review.
Blesta categories belong to the company active for the connection. Confirm that company before selecting a parent with a familiar name. Review the article’s own access as well as the category; do not infer the complete audience from the category label alone.
Rename or move without duplicating
Use Edit a knowledge base category with the existing category ID when the task is changing a name, description, parent or visibility. Moving an existing category is different from creating another one with the same name. Do not move a category into itself or one of its descendants.
A visibility change can affect the articles filed there. Review the affected content and native client view as part of the intended change, rather than treating a category edit as a cosmetic update.
If a create request has an uncertain outcome, list the categories and reconcile the result before retrying. Read back the saved hierarchy after an authorised change; the assistant’s success message alone is not the final check.
See the PD MCP Hub Blesta guide for related tasks, or explore PD MCP Hub.