Skip to main content
Glama

Get Revert Counts

get_revert_counts

Count revert-tagged Wikipedia edits per article in a date window, ordered by most reverted, to identify pages with frequent edit reversions.

Instructions

Revert-tagged edits (mw-reverted, mw-undo, mw-rollback) per article in a date window, most reverted first.

Wikipedia only keeps recent changes for about 30 days, so older windows return partial or empty results. The scan can take a minute or more.

Input Schema

NameRequiredDescriptionDefault
endNoLast day, YYYY-MM-DD (default: today, UTC).
langNoWikipedia language code (default "en").en
startNoFirst day, YYYY-MM-DD (default: 7 days before `end`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: result ordering, a hard data-availability limit (~30 days of recent changes), and a latency warning ('can take a minute or more'). It omits auth/permission requirements and whether counts are of edits or editors, so it falls short of exhaustive.

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?

Two tight paragraphs, zero filler. The core purpose and ordering are front-loaded, and the caveats follow in a clearly subordinate second paragraph.

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?

There is no output schema, so the description should ideally sketch the return shape; 'per article ... most reverted first' implies a ranked list but never states what fields come back (article title, count?). Given the tool's simplicity and the strong coverage of limitations and latency, it is nearly complete.

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 all three date/lang parameters document their defaults and formats, so the schema does the heavy lifting. The description only adds the consequence of choosing an old window, not syntax or format detail beyond the schema.

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 (revert-tagged edits per article), the scope (date window), the tagging mechanism (mw-reverted, mw-undo, mw-rollback), and the result ordering (most reverted first). No sibling tool in the list covers reverts, so an agent can route to it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The 30-day retention note effectively tells the agent when the tool is and is not useful ('older windows return partial or empty results'), which is real usage guidance. It does not name alternatives, but no sibling covers revert data, so the gap is minor.

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