Skip to main content
Glama
olgasafonova

mediawiki-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

mediawiki_get_page

Read-only

Fetches full MediaWiki page content by title in wikitext or HTML, enabling assistants to read and present wiki articles on request.

Instructions

Retrieve full wiki page content.

USE WHEN: User says "show me the X page", "what's on the Main Page", "read the FAQ".

NOT FOR: Getting page structure/TOC (use mediawiki_get_sections). Not for searching content (use mediawiki_search_in_page). Not for metadata only (use mediawiki_get_page_info). If title not found, use mediawiki_resolve_title to handle typos and case sensitivity.

PARAMETERS:

  • title: Page name (required)

  • format: "wikitext" (default) or "html"

RETURNS: Page content in requested format. Large pages truncated at 25KB.

Input Schema

NameRequiredDescriptionDefault
titleYesPage title to retrieve
formatNoOutput format: 'wikitext' (default) or 'html'
rationaleNoOptional one-sentence explanation of why you are calling this tool. Used for audit trails when present.

Output Schema

NameRequiredDescriptionDefault
titleYes
formatYes
contentYes
messageNo
page_idYes
timestampYes
truncatedNo
revision_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.31.0
    • addedInput schema / properties / rationale
      Added value: +{
+  "description": "Optional one-sentence explanation of why you are calling this tool. Used for audit trails when present.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's added value is the 25KB truncation limit and the format-dependent return behavior, both genuinely useful operational facts. It does not explain the non-obvious idempotentHint=false on what looks like a pure read, nor auth/rate behavior, so it stops short of a 5.

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?

Roughly five short lines with a labeled USE WHEN / NOT FOR / RETURNS structure; the core action and scope are front-loaded and every sentence carries routing or constraint information. Minor duplication of the format enum against the schema is the only overhead.

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 an output schema present, the description need not restate return values, and it still covers the truncation caveat that the output schema alone would not reveal. Routing to resolve_title closes the main failure mode for a title-keyed lookup.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description's PARAMETERS block largely restates the schema (title, format with wikitext default) rather than adding syntax, casing rules, or naming-convention detail for ambiguous titles beyond a pointer to resolve_title.

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?

Opens with a specific verb+resource ('Retrieve full wiki page content') and immediately distinguishes itself from four siblings by name. An agent can route between get_page, get_sections, get_page_info, and search_in_page without opening any schema.

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 trigger phrasings, explicit NOT FOR exclusions each mapped to the correct alternative, and a failure-path instruction (use mediawiki_resolve_title on title-not-found). This is the full when/when-not/fallback triad.

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