mediawiki-mcp-server

by olgasafonova

Overview Schema Source Related Servers Discussions Admin

Hybrid

mediawiki_upload_file

Destructive

Upload images or documents to MediaWiki from base64 data or a public URL, with optional description and comment.

Instructions

Upload a file to the wiki from base64 bytes or a URL.

USE WHEN: User says "upload this image", "add file to wiki", "import document".

PARAMETERS:

filename: Target filename on wiki (required)
file_data: Base64-encoded file contents (one of file_data or file_url required). Use this when you already have the bytes; it skips the URL-fetch path. Mutually exclusive with file_url.
file_url: Source URL for the wiki to fetch (alternative to file_data). Mutually exclusive with file_data.
text: File description page content (optional)
comment: Upload comment (optional)
ignore_warnings: Overwrite existing file (default false)

RETURNS: Upload status and file page URL. Includes revision ID, diff URL, and undo instructions.

NOTE: Requires authentication. For file_url, the URL must be publicly accessible.

SECURITY: file_data uploads bytes directly and never triggers a server-side fetch, so the allowlist/SSRF gates do not apply to that path. For file_url, the source host must be on the MEDIAWIKI_UPLOAD_ALLOWED_DOMAINS env-var allowlist (fail-closed when unset), and private/internal IPs are blocked unconditionally. Decoded file_data is capped at 100 MiB by default — matching MediaWiki's default max upload size — and is adjustable via MEDIAWIKI_MAX_UPLOAD_DATA_BYTES. ignore_warnings=true overwrites existing files; the destructive-hint annotation is set so hosts that gate destructive operations will prompt before this runs.

Input Schema

Name	Required	Description
`text`	No	File description page content (wikitext)
`comment`	No	Upload comment for the log
`file_url`	No	URL to fetch and upload. Mutually exclusive with file_data.
`filename`	Yes	Target filename on the wiki (e.g., 'Example.png')
`file_data`	No	Base64-encoded file contents to upload directly (standard base64, RFC 4648). Use this for files the agent already has — it avoids the URL-fetch path and its allowlist/SSRF gates. Mutually exclusive with file_url.
`file_path`	No	Local file path to upload (rejected via MCP; CLI use FileData)
`rationale`	Yes	Required one-sentence explanation of why you are making this change. Stored in the audit log for post-hoc intent reconstruction.
`ignore_warnings`	No	Ignore duplicate/overwrite warnings

Output Schema

Name	Required	Description	Default
`url`	No
`size`	No
`message`	Yes
`page_id`	No
`success`	Yes
`filename`	Yes
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.32.0Jun 26, 2026

addedInput schema / properties / file_data

Added value: +{
+  "description": "Base64-encoded file contents to upload directly (standard base64, RFC 4648). Use this for files the agent already has — it avoids the URL-fetch path and its allowlist/SSRF gates. Mutually exclusive with file_url.",
+  "type": "string"
+}

changedInput schema / properties / file_path / description

Previous value: -"Local file path to upload"New value: +"Local file path to upload (rejected via MCP; CLI use FileData)"

changedInput schema / properties / file_url / description

Previous value: -"URL to fetch and upload (alternative to file_path)"New value: +"URL to fetch and upload. Mutually exclusive with file_data."

Changed2 schema fields changedv1.31.0May 14, 2026

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: -[
-  "filename"
-]New value: +[
+  "rationale",
+  "filename"
+]

First observedMar 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: authentication requirement, fail-closed SSRF/allowlist behavior for file_url, the fact that file_data skips the fetch path, a 100 MiB decode cap and its env-var override, and explicit overwrite semantics for ignore_warnings. This is far richer than the destructive/openWorld hints alone.

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?

Labelled sections (USE WHEN, PARAMETERS, RETURNS, NOTE, SECURITY) make it easy to scan and front-load the essential action. It is slightly long and repeats some parameter text already in the schema, but nothing is truly wasteful.

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?

An output schema exists, yet the description still summarizes the return (status, file page URL, revision ID, diff URL) and covers auth, security gates, and size limits. Nothing needed to invoke this 8-param mutation tool correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains when to prefer file_data over file_url and that they are mutually exclusive, plus the default for ignore_warnings. It omits file_path (rejected via MCP) and rationale from the prose, keeping it just short of a 5.

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?

States a specific verb (upload) and resource (file to the wiki) and distinguishes the two source modes (base64 bytes vs URL). An agent can tell this apart from siblings like mediawiki_edit_page or mediawiki_get_images 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 'USE WHEN' block gives concrete user phrases that trigger the tool, and it explains the file_data vs file_url choice with mutual-exclusivity rules. It lacks an explicit 'when not to use' or named alternative tool, but the context is clear.

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

Deploy Server