Skip to main content
Glama
ni-c

wikijs-mcp

by ni-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get site and system information

get_site_info
Read-onlyIdempotent

Get Wiki.js site summary: version, database, host, title, description, and totals for pages, users, groups, tags. Use as first call to verify URL and API key when issues occur.

Instructions

Version, database, host summary and the site’s own title and description, plus totals for pages, users, groups and tags. The first call to make when something is not behaving — it proves the URL and the API key work at all. Fields describing the host filesystem and database host are deliberately not requested.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

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

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value beyond annotations by disclosing that host filesystem and database-host fields are 'deliberately not requested,' setting expectations about the response scope, and framing the call as proof that the URL and API key work. No contradiction with annotations exists.

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?

Three sentences, each earning its place: the content summary is front-loaded first, followed by the when-to-use diagnostic guidance, then the deliberate field-exclusion caveat. There is no filler and no repetition of what the schema or annotations already state.

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?

With zero parameters, full annotation coverage of the read-only/idempotent safety profile, and an output schema present, the only remaining job for the description is scope and usage — both are covered, including a caveat about deliberately omitted host-level fields. Nothing an agent needs to correctly select and invoke this tool 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?

The tool takes zero parameters, so the rubric's baseline of 4 applies; there are no parameter semantics to clarify. The description instead enumerates the response contents (version, database, host summary, counts), which is more useful for this no-argument tool than parameter prose would be.

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 enumerates exactly what is returned — version, database, host summary, site title/description, and totals for pages, users, groups, and tags — going well beyond the terse title. This site-level resource is clearly distinct from all 60+ sibling tools, which target pages, users, tags, assets, comments, and other specific resources. An agent can identify what this tool provides 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?

The description gives an explicit scenario: 'The first call to make when something is not behaving — it proves the URL and the API key work at all.' This tells the agent when to invoke it as a diagnostic smoke test. It does not name when-not-to-use cases or alternatives, though none of the siblings genuinely compete with a site-info call, so this is a minor gap.

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