Skip to main content
Glama

mediawiki_find_broken_internal_links

Read-only

Scan MediaWiki pages to detect broken internal [[links]] that point to missing pages, then report the source page, line, and context for fixes.

Instructions

Find internal wiki [[links]] pointing to non-existent pages.

USE WHEN: User asks "find broken wiki links", "check for dead internal links", "find [[links]] to missing pages".

NOT FOR: Checking external HTTP URLs (use mediawiki_check_links).

PARAMETERS:

  • pages: Array of pages to scan (optional)

  • category: Scan all pages in category (optional)

  • limit: Max pages to scan (default 20)

RETURNS: Broken links with source page, line number, and context.

Input Schema

NameRequiredDescriptionDefault
limitNoMax pages to check (default 20, max 100)
pagesNoPage titles to check for broken internal links
categoryNoCategory to get pages from (alternative to pages)
rationaleNoOptional one-sentence explanation of why you are calling this tool. Used for audit trails when present.

Output Schema

NameRequiredDescriptionDefault
pagesYes
broken_countYes
pages_checkedYes

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scoping context (what counts as broken, default 20 pages) and return structure, though it doesn't address the idempotentHint=false nuance or scanning cost. Solid but not rich beyond annotations.

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?

Uses labeled sections (USE WHEN, NOT FOR, PARAMETERS, RETURNS) with a front-loaded purpose sentence. Every line is scannable and earns its place, no redundancy.

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?

An output schema exists, so return-value detail is redundant but harmless. The description fully covers purpose, selection criteria, exclusions, and parameter roles for a read-only scan tool. Nothing needed to call it correctly is missing.

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 the schema already documents all parameters including the max-100 limit and the rationale field. The description's PARAMETERS block largely restates the schema and omits the rationale audit parameter, adding little beyond it. 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 (Find) and resource (internal wiki [[links]] pointing to non-existent pages), which precisely names the operation. It explicitly distinguishes itself from the sibling mediawiki_check_links, so an agent can differentiate 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?

Provides explicit USE WHEN triggers with quoted user phrasings, plus a NOT FOR exclusion that names the alternative tool (mediawiki_check_links) for external URLs. This is exactly the when/when-not/alternative structure an agent needs.

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