Skip to main content
Glama

mediawiki_batch_get_pages

Read-only

Fetch content from up to 50 MediaWiki pages in one API call, returning wikitext or HTML plus exists/missing status.

Instructions

Retrieve content from MULTIPLE pages in a single API call.

USE WHEN: You need content from 2+ pages. Much faster than individual mediawiki_get_page calls.

NOT FOR: Single page (use mediawiki_get_page). Not for metadata only (use mediawiki_batch_get_pages_info).

PARAMETERS:

  • titles: Array of page titles (required, max 50)

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

RETURNS: Page content for each title, with exists/missing status. Missing pages are reported, not errors.

Input Schema

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

Output Schema

NameRequiredDescriptionDefault
pagesYes
found_countYes
total_countYes
missing_countYes

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. Addedv1.30.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context beyond them: the batch limit of 50, and the important return contract that missing pages are reported as status rather than raised as errors. It does not, however, discuss rate limits or partial-failure semantics for a large batch.

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?

Front-loaded one-line summary followed by clearly labeled USE WHEN / NOT FOR / PARAMETERS / RETURNS sections. Every sentence carries selection or invocation value with no filler.

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 batch read tool with an output schema present, the description covers the essentials: when to choose it, the alternatives, the batch cap, and the missing-page behavior. Nothing an agent needs to invoke it correctly is absent.

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%, and the description's parameter block essentially restates the schema (titles array, max 50, format wikitext/html). It adds no format syntax, title normalization, or ordering semantics beyond what the schema already documents, so the baseline 3 applies.

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 and resource ('Retrieve content from MULTIPLE pages') and scopes it to a single API call, which distinguishes it immediately from the per-page sibling mediawiki_get_page.

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 (2+ pages, faster than individual calls) and NOT FOR clauses route the agent to mediawiki_get_page for single pages and mediawiki_batch_get_pages_info for metadata-only requests. Both alternatives are named with their selecting conditions.

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