mediawiki-mcp-server

Overview Schema Source Related Servers Discussions Admin

mediawiki_get_page_info

Read-only

Retrieve page metadata such as last edit time, creator, size, and protection status. Use it to check when a wiki page was last edited, who made it, or if it is protected, without fetching content.

Instructions

Get page metadata without content.

USE WHEN: User asks "when was X last edited", "who created the FAQ", "is the page protected".

NOT FOR: Getting page content (use mediawiki_get_page). Not for full edit history (use mediawiki_get_revisions).

PARAMETERS:

title: Page name (required)

RETURNS: Last edit timestamp, page size, protection status, creator.

Input Schema

Name	Required	Description	Default
`title`	Yes	Page title
`rationale`	No	Optional one-sentence explanation of why you are calling this tool. Used for audit trails when present.

Output Schema

Name	Required	Description	Default
`title`	Yes
`exists`	Yes
`length`	Yes
`page_id`	Yes
`touched`	Yes
`redirect`	Yes
`namespace`	Yes
`categories`	No
`protection`	No
`links_count`	Yes
`redirect_to`	No
`content_model`	Yes
`page_language`	Yes
`last_revision_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.31.0May 14, 2026

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"
+}

First observedMar 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint, so the safety profile is covered; the description adds genuinely new context by naming the returned fields and stressing that page content is deliberately excluded (a payload/size consideration). It does not address the unusual idempotentHint=false on a read-only metadata call, which an agent might want explained.

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?

Four short, front-loaded blocks (purpose, USE WHEN, NOT FOR, RETURNS) with zero filler. Every line earns its place and the most decision-relevant information leads.

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?

For a simple single-parameter lookup with an output schema, the description covers purpose, exclusions, alternatives, and the shape of the result. An agent has everything needed to select and invoke it correctly without opening the schema.

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 both parameters are already documented in the schema and the baseline is 3. The description restates 'title: Page name (required)' but adds no format, disambiguation, or naming-convention guidance, and it never mentions the optional 'rationale' parameter.

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+resource (get page metadata) and immediately constrains scope with 'without content', which is the key differentiator from mediawiki_get_page. Sibling routing is made explicit by naming mediawiki_get_page and mediawiki_get_revisions in the exclusion clause.

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?

Explicit USE WHEN triggers are given as quoted user phrasings ('when was X last edited', 'who created the FAQ'), and NOT FOR clauses redirect to the correct alternatives with the condition that selects each. Nothing is left to inference.

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

Deploy Server