Skip to main content
Glama
olgasafonova

mediawiki-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

mediawiki_find_similar_pages

Read-only

Find wiki pages with similar content to detect duplicates or overlaps, returning similarity scores and linking recommendations.

Instructions

Find pages with similar content (potential duplicates or overlaps).

USE WHEN: User asks "find similar pages", "are there duplicates", "what pages overlap with X".

NOT FOR: Finding related pages by links (use mediawiki_get_related).

PARAMETERS:

  • page: Source page name (required)

  • category: Limit search to category (optional)

  • min_score: Minimum similarity threshold 0-1 (default 0.1)

  • limit: Max similar pages (default 10)

RETURNS: Similar pages with similarity scores and linking recommendations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYesPage title to find similar pages for
limitNoMaximum similar pages to return (default 10, max 50)
categoryNoLimit search to pages in this category
min_scoreNoMinimum similarity score 0-1 (default 0.1)
rationaleNoOptional one-sentence explanation of why you are calling this tool. Used for audit trails when present.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNo
source_pageYes
similar_pagesYes
total_comparedYes

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.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false, covering the safety and determinism profile. The description adds the return shape and parameter defaults but discloses no behavioral traits beyond that, such as computational cost, permissions, or why results are non-idempotent. Adequate but not rich.

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?

Header-delimited sections (USE WHEN, NOT FOR, PARAMETERS, RETURNS) make it skimmable, and the core purpose plus the key sibling distinction are front-loaded in the first two lines. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be spelled out, yet the description summarizes them anyway. Combined with clear use-case routing, exclusions, and parameter listing, it is nearly complete; only the undocumented rationale parameter is left to the schema alone.

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 restates four of the five parameters with their defaults (page, category, min_score, limit), which duplicates rather than extends the schema; it omits the schema's rationale parameter entirely and adds no new semantics such as what 'similarity' is measured against.

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 ('Find pages with similar content') and immediately scopes it with '(potential duplicates or overlaps)'. Explicitly distinguishes itself from the confounding sibling mediawiki_get_related, so an agent can disambiguate 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a USE WHEN section with concrete user phrasings ('find similar pages', 'are there duplicates', 'what pages overlap with X') and a NOT FOR section naming the alternative tool mediawiki_get_related with its distinguishing condition (link-based relatedness vs content similarity). Both routing conditions are explicit.

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