Skip to main content
Glama
Sign In
mediawiki-mcp-server

mediawiki-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

mediawiki_search_and_read

Read-only

Search a wiki and read top results in one call to answer wiki-content questions without separate search and read steps.

Instructions

Search wiki AND read the top result(s) in a single call.

USE WHEN: User asks a question about wiki content. This is the fastest path from question to answer — eliminates the search-then-read round trip.

NOT FOR: Known page titles (use mediawiki_get_page directly). Not for listing search results without reading (use mediawiki_search).

PARAMETERS:

  • query: Search text (required)

  • read_count: How many top results to read (default 1, max 5)

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

RETURNS: Full content of top result(s) plus remaining search hits as summaries.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch query text
formatNoContent format: 'wikitext' (default) or 'html'
rationaleNoOptional one-sentence explanation of why you are calling this tool. Used for audit trails when present.
read_countNoNumber of top results to read (default 1, max 5)

Output Schema

NameRequiredDescriptionDefault
pagesYes
queryYes
messageYes
other_hitsNo
total_hitsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.36.0
    • addedOutput schema / properties / other_hits / items / properties / url
      Added value: +{
+  "type": "string"
+}
  2. 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"
+}
  3. Addedv1.30.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint=false, so the safety profile is covered. The description adds genuine context beyond that: it explains the round-trip elimination and what content comes back (full top result(s) plus remaining hits as summaries), though it says nothing about rate limits, large-page behavior, or why idempotency does not hold.

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?

Headers and front-loading are excellent: purpose first, then when, then anti-patterns, then params, then returns. The PARAMETERS block duplicates schema content that the schema already supplies, which is the only notable waste.

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, annotations covering safety, and 100% schema description coverage, the description supplies everything else an agent needs: purpose, selection criteria, alternatives, and a return summary. Nothing material is missing for correct invocation.

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 coverage is 100%, so both the parameters and their descriptions are already documented in structured form; the description's PARAMETERS block largely restates defaults and bounds (read_count max 5, format wikitext default) that the schema carries. Baseline 3 is appropriate — no added syntax or edge-case semantics.

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?

The description states a specific compound verb+resource: 'Search wiki AND read the top result(s) in a single call.' It explicitly distinguishes itself from mediawiki_search and mediawiki_get_page, so an agent can place it against siblings without opening schemas.

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?

It gives an explicit USE WHEN condition (user asks a question about wiki content) and a NOT FOR clause naming two alternatives by name with the conditions that select them (known titles, listing without reading). 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

Other Tools