Skip to main content
Glama
ni-c

wikijs-mcp

by ni-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List groups

list_groups
Read-onlyIdempotent

List wiki groups with their user counts and flag built-in system groups (Administrators, Guests) that cannot be deleted.

Instructions

Lists the wiki’s groups with how many users each has. Groups marked isSystem are Wiki.js’ own Administrators and Guests — they exist always and should not be deleted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNo
order_byNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
truncatedNoPresent only when the answer was shortened to fit the budget.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": true,
+  "properties": {
+    "truncated": {
+      "additionalProperties": true,
+      "description": "Present only when the answer was shortened to fit the budget.",
+      "properties": {},
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.1.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful context beyond that: it explains that the result includes user counts and that isSystem groups (Administrators and Guests) are permanent and should not be deleted. This helps the agent interpret results and avoid future destructive actions.

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?

Two short, purposeful sentences. The first states exactly what the tool does, and the second conveys an important caveat about system groups. There is no fluff or repetition of schema information.

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 simple, read-only list tool with no required parameters and an output schema, the description is largely complete. It names the resource and result content, and highlights the important isSystem caveat. The only notable gap is the lack of guidance on how 'filter' behaves, though the tool can be safely invoked with no arguments.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the undocumented 'filter' and 'order_by' parameters. It does not mention either parameter, leaving 'filter' ambiguous and forcing the agent to guess its behavior. The enum on 'order_by' provides some self-documentation, but the description adds nothing.

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?

The description starts with a specific verb ('Lists') and resource ('the wiki's groups') and adds the key detail that it includes user counts. This clearly distinguishes it from siblings like get_group, list_users, or search_groups.

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 description makes the basic listing use obvious and even warns that system groups should not be deleted, but it does not explicitly say when to prefer this tool over alternatives like get_group or search_users. Usage context is implied rather than 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