Skip to main content
Glama

Propose several changes to one Wikidata item, as one group

propose_wikidata_changes
Idempotent

Propose several changes to one item (one no entry links included: its statements are then read live) as ONE proposal (Console → Wikidata → Review shows it as one card with every change ticked; an administrator may untick some, which are dismissed, and approves the rest, which are made in this order, one edit each; a change that does not go through stops the ones after it). Filed as curated by your account and this key, and only proposed: nothing is written to Wikidata here. Trusted editors and administrators may; each change counts toward a trusted editor’s 200 a day, and there is no limit on the changes in one proposal. qid the item, kind the kind of every change (superseded, duplicate or update), evidence the reason they share (why, and the summary you would like, never naming this site), and changes in order, each exactly as propose_wikidata_correction takes one change but without qid, kind or dry_run: a term (set_label, set_description, set_aliases), add_claim, add_reference, replace_reference, add_qualifier, change_qualifier, remove_qualifier, set_rank or supersede, or alone a move_to_item or copy_to_item (its steps are on two items); a change may give an evidence of its own. Never a deprecation or a merge, and never two changes to one term in one language, or one value added twice (duplicate_change). Two changes may be to one statement (two qualifiers on it, a qualifier and a reference), and a change may be to the statement an earlier change adds: give its statement_guid as step:N, N that change’s place in the list. Each change is checked as it would be alone, against the item as the changes before it will leave it, and the proposal is filed only if every one passes: a refusal names its step (from 1), and nothing is filed. Audited. Dry run by default: the site checks every change and shows each step it would file, in order (a preferred rank’s end times and the superseded bundle’s steps in their place). The owner’s Wikidata conventions are checked as for propose_wikidata_correction: a new channel ID statement (P2397) needs its title (P1810), and a YouTube handle’s channel must be on the item or added by an earlier change (refused, with step, message and suggestion), and so are a web archive’s copy as a reference’s url, an add_claim the item states already, and a Bluesky handle changed with no DID; the other slips come back as warnings, each naming its step (a second preferred count of one account in another open proposal included, and an account deprecated as not the subject’s while this proposal leaves follower counts of it current: account_counts_apart). An account and its counts deprecated in one call are one group, with no warning; any of them already open apart is taken into it. A change a person proposed before and is still open is taken into the group only when it writes the same thing (the whole value, its qualifiers and rank, and the same reference, the day retrieved aside): the dry run names it (adopts), and the answer (adopted); one written otherwise (another reference, qualifier or rank) refuses the proposal (409 already_proposed, naming its step and the open row’s id), dry run or not, and nothing is filed: leave that change out, or have the open row dismissed first. A proposal of one change gets the answer that change alone gets from propose_wikidata_correction: beside a person’s open change to something else on its statement it is joined to that one’s group as its next step (joins; the answer’s joined and group_id). A change a person dismissed before (the same kind, action, statement, value seen and new value, and the whole value written: a quantity’s range, a new statement’s qualifiers, and its reference, the day retrieved aside) refuses the proposal (409 dismissed, naming its step, with when it was dismissed), dry run or not, and nothing is filed; refile: true files it all the same. An official website (P856; test.wikidata.org’s P206) a proposal adds or changes, and each of the item’s other official websites with no language of work or name (P407; test.wikidata.org’s P77090), gets a step of its own after the proposal’s, adding the language its page declares (its , else its Content-Language header; en-US is English, Q1860), made as an edit of its own once the statement exists; a page that declares no language, several, or one with no item, or that does not load, gets no step, and nothing is guessed. The dry run and the answer name each (website_languages: the step, the language and what the page declared, or left_out with a message), and a reviewer may untick any. A statement the proposal gives a P407 itself is left as given.

Input Schema

NameRequiredDescriptionDefault
qidYes
kindYes
refileNoFile every change even where a person dismissed the same change before (refused 409 `dismissed` otherwise).
changesYesThe changes, in the order they are to be made.
dry_runNotrue (the default): write nothing — show the change and the exact request it would send. false: make the change.
evidenceNoWhy, shared by every change that gives none of its own.

Output Schema

NameRequiredDescriptionDefault
noteNoA dry run: what to do next to make the change, in words.
resultNoA real run: the route’s own answer, where the tool adds facts of its own beside it.
confirmNoA dry run of a change that needs it: the exact target to send back as `confirm` with dry_run: false.
dry_runNotrue: a dry run, which wrote nothing. Absent from a real run.
replayedNoA real run with an idempotency_key already used for this change: the first call’s answer, given back; nothing was written now.
would_sendNoA dry run: the exact request the real run would send (`method`, `path`, any `headers` such as an Idempotency-Key, and its `body`, `form` or `query`), or the requests, in order.
may_edit_liveNoA dry run of a live edit: whether this key’s account may edit this entry live.
refused_becauseNoA dry run the real run would be refused for: why, in words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / refile
      Added value: +{
      +  "description": "File every change even where a person dismissed the same change before (refused 409 `dismissed` otherwise).",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / changes / items / properties / action / enum
      Previous value: -[
      -  "set_label",
      -  "set_description",
      -  "set_aliases",
      -  "add_claim",
      -  "add_reference",
      -  "replace_reference",
      -  "add_qualifier",
      -  "change_qualifier",
      -  "remove_qualifier",
      -  "set_rank",
      -  "supersede"
      -]New value: +[
      +  "set_label",
      +  "set_description",
      +  "set_aliases",
      +  "add_claim",
      +  "add_reference",
      +  "replace_reference",
      +  "add_qualifier",
      +  "change_qualifier",
      +  "remove_qualifier",
      +  "set_rank",
      +  "supersede",
      +  "move_to_item",
      +  "copy_to_item"
      +]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds extensive behavior beyond the annotations: dry-run defaults, no writes to Wikidata, review/card workflow, ordered edits, stop-on-failure, permissions, rate limits, 409 refusal cases, warnings, adoption/joining of open changes, and extra website-language steps. This is unusually rich disclosure and does not contradict `readOnlyHint=false`, `destructiveHint=false`, or `idempotentHint=true`.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and most details are relevant to correct invocation, but the description is a very long, dense paragraph with legalistic parentheticals and repeated refusal wording. It is comprehensive but could be structured with bullets or sections to make the operational rules easier to scan.

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?

Given the tool's complexity, the description covers the critical operational context: permissions, dry-run behavior, ordering, validation, refusal cases, warnings, adoption/joining, and post-processing. Since an output schema exists, the description need not explain return values, and it is otherwise complete enough for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 67%, the description adds substantial meaning: `qid` identifies the item, `kind` applies to every change, `evidence` is shared unless overridden, and `changes` are ordered and shaped like `propose_wikidata_correction` entries without `qid`, `kind`, or `dry_run`. It also explains allowed action families, per-change `evidence`, and `statement_guid` references such as `step:N`.

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 verb and resource: propose several changes to one Wikidata item as one group/proposal. It clearly distinguishes this from `propose_wikidata_correction` by emphasizing multiple changes and by explaining that a one-change proposal falls back to that tool's behavior.

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?

It gives strong context for when this tool is appropriate: multiple changes to one item, filed as one proposal, dry-run by default, with trusted/administrator permissions and rate-limit rules. It also references `propose_wikidata_correction` as the per-change schema and single-change behavior, though it does not give a crisp explicit routing rule between the two.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.