Skip to main content
Glama
Sign In
SpaceParrots

libredesk-mcp

by SpaceParrots
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

libredesk_ai_knowledge

Create, update, import, and review helpdesk snippets that AI assistants answer from, and approve or reject FAQ suggestions mined from resolved conversations.

Instructions

Manage the snippets AI assistants answer from, and review FAQ suggestions. Undocumented API.

Actions:

  • snippet_list(...): List the snippets AI assistants search, with a short preview.

  • snippet_get(id): Get one snippet with its full content.

  • snippet_create(title, content, ...): Add a snippet: a self-contained answer with a clear title.

  • snippet_update(id, ...): Change only the given fields of a snippet.

  • snippet_import_url(url): Import a web page's readable text as a snippet.

  • faq_list(...): List FAQ suggestions mined from resolved conversations.

  • faq_approve(id, ...): Approve a FAQ suggestion as an enabled snippet, optionally edited.

  • faq_reject(id): Reject a FAQ suggestion without creating a snippet.

  • learning_get(): Show whether FAQ learning is on.

Input Schema

NameRequiredDescriptionDefault
idNoSnippet id. For faq_approve, faq_reject: FAQ suggestion id.
urlNoPage URL; the LibreDesk server fetches it.
titleNoThe customer question or topic, for example "How do I get a refund?".
actionYesAction.
answerNoReplaces the suggested answer; keep it self-contained.
searchNoOnly snippets whose title or content contains this text.
statusNoOnly this status; omit for all.
contentNoPlain text answer, quoted by assistants: self-contained, one topic, full sentences with the details a customer needs (steps, limits, prices, links).
enabledNoLet AI assistants answer from the snippet. For snippet_list: Filter by enabled state.
profileNoStored profile to use; omit for the default.
questionNoReplaces the suggested question.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations mark the tool as non-read-only but non-destructive, and the description aligns by making clear which actions mutate (create, update, import_url, approve, reject) and that snippet_update changes only given fields. The 'Undocumented API' note is a useful caveat, but nothing is said about permissions, whether rejected/updated data is recoverable, or error behavior — and no annotation-supplied context is extended.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A one-line scope statement followed by a scannable action list where every bullet earns its place by pairing an action with its parameters. Front-loaded and free of filler.

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

Completeness4/5

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

For a nine-action tool with 11 parameters and no output schema, the description covers the action surface and gives brief return hints ('short preview', 'full content', 'show whether FAQ learning is on'). The remaining gap is that the 'Undocumented API' caveat is stated without any guidance on constraints or failure modes across those actions.

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 the schema already defines all 11 parameters; the description still adds real value by mapping parameters to actions (snippet_create(title, content, ...), faq_approve(id, ...), learning_get() with none), which the flat schema cannot express. It marks optional slots with ellipses but does not explain which optional fields each action honors.

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 opening sentence names a specific verb and resource — managing the snippets AI assistants answer from plus reviewing FAQ suggestions — and the action list makes each verb+resource concrete. It falls short of a 5 because it never distinguishes these snippets from the knowledge-base content handled by siblings like libredesk_articles and libredesk_help_center, which is where confusion is most likely.

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 breakdown (snippet_get for one item's full content vs snippet_list for a preview, faq_approve vs faq_reject, partial update vs create) implies when to pick each action. However there is no explicit guidance on when to use this tool instead of the sibling knowledge/article tools, and no prerequisites or exclusions are stated.

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

Deploy Server

Other Tools