Skip to main content
Glama
Sign In
olgasafonova

mediawiki-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

mediawiki_manage_categories

Destructive

Add or remove categories on a MediaWiki page without editing full content. Preview changes first, then apply with an edit summary to update page categories.

Instructions

Add or remove categories from a page without editing the full content.

USE WHEN: User says "add category X to this page", "remove this from category Y", "categorize this page".

NOT FOR: Listing categories (use mediawiki_list_categories). Not for viewing category members (use mediawiki_get_category_members).

PARAMETERS:

  • title: Page name (required)

  • add: Array of category names to add (without "Category:" prefix)

  • remove: Array of category names to remove (without "Category:" prefix)

  • preview: Preview changes without saving. Omit to preview (default true, for safety); set preview=false to apply.

  • summary: Edit summary

RETURNS: Which categories were added, removed, already present, or not found. Includes revision ID, diff URL, and undo instructions.

NOTE: Requires authentication (bot password) to apply changes. Anonymous sessions cannot edit.

Input Schema

NameRequiredDescriptionDefault
addNoCategory names to add (without 'Category:' prefix)
titleYesPage title to manage categories for
removeNoCategory names to remove (without 'Category:' prefix)
previewNoPreview changes without applying them. Omitted means preview (the safe default): the category edit is not saved and the planned add/remove set is returned. Set false to apply the change.
summaryNoEdit summary
rationaleYesRequired one-sentence explanation of why you are making this change. Stored in the audit log for post-hoc intent reconstruction.

Output Schema

NameRequiredDescriptionDefault
undoNo
addedNo
titleYes
messageYes
previewYes
removedNo
successYes
revisionNo
not_foundNo
revision_idNo
already_presentNo
current_categoriesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.36.0
    • changedInput schema / properties / preview / description
      Previous value: -"Preview changes without saving"New value: +"Preview changes without applying them. Omitted means preview (the safe default): the category edit is not saved and the planned add/remove set is returned. Set false to apply the change."
    • changedInput schema / properties / preview / type
      Previous value: -"boolean"New value: +[
+  "null",
+  "boolean"
+]
  2. Changed2 schema fields changedv1.31.0
    • addedInput schema / properties / rationale
      Added value: +{
+  "description": "Required one-sentence explanation of why you are making this change. Stored in the audit log for post-hoc intent reconstruction.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "title"
-]New value: +[
+  "rationale",
+  "title"
+]
  3. Addedv1.30.0

TDQS

A4.8/5.0
Behavior5/5

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

Discloses beyond the annotations: that preview defaults to true for safety, that authentication (bot password) is required to apply, and that anonymous sessions cannot edit. Annotations cover the safety profile (destructiveHint true, idempotentHint false); the description adds the auth requirement and the default-preview behavior, which the agent needs to invoke correctly.

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 the core action, then structured USE WHEN / NOT FOR / NOTE blocks. Slightly dense with the RETURNS and NOTE sections, but each carries an agent-relevant fact.

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?

Complete for a mutation tool: states the when/when-not, auth requirements, the safe default behavior for preview, and what gets returned (added/removed/already present/not found). Output schema exists, yet the description still gives the agent enough to decide and call correctly.

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 is 3. The description adds the 'without Category: prefix' convention and emphasizes the preview default and its rationale, plus notes the required rationale parameter's audit purpose. Marginal but genuine value beyond the schema.

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?

Specific verb+resource ('Add or remove categories from a page') with an explicit scoping qualifier ('without editing the full content') that distinguishes it from the sibling mediawiki_edit_page. Clearly names the resource and the operation.

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

Usage Guidelines5/5

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

Provides explicit USE WHEN triggers with user phrasings and a NOT FOR section that names two alternative siblings (mediawiki_list_categories, mediawiki_get_category_members) with their distinct purposes. Routing is unambiguous.

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