Skip to main content
Glama

Delete an entry whose Wikidata item was deleted

delete_wikidata_deleted_entry
Destructive

The Delete button on Deleted on Wikidata’s “To review” list: delete an entry because its Wikidata item is deleted. It comes off the public site, and its address answers 410 with a public notice saying its Wikidata item was deleted, with its name unless hide_title (set_delete_notice changes or suppresses it). It comes back by itself if Wikidata restores the item (restore_deleted_entry brings it back by hand), and the notice goes with the delete. A deletion on Wikidata is a reason to look at an entry, not to delete it. Audited. Dry run by default; the real run needs confirm set to the entry’s VHID.

Input Schema

NameRequiredDescriptionDefault
entryYesThe entry: its VHID (11 digits), its short name (as in verifiedhandles.org/<short>), or its Wikidata QID (Q42).
confirmNoNeeded with dry_run: false: this change’s exact target, as the dry run gives it in `confirm`.
dry_runNotrue (the default): write nothing — show the change and the exact request it would send. false: make the change.
hide_titleNoLeave the entry’s name off its public notice.

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 / hide_title
      Added value: +{
      +  "default": false,
      +  "description": "Leave the entry’s name off its public notice.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond destructiveHint=true: it discloses the public-site effect (410 response with a public notice), that the entry's name appears in the notice unless hide_title is set, that deletion reverses automatically if Wikidata restores the item, that the action is audited, and that it dry-runs by default requiring confirm. That is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with the core action and its trigger, then consequences, then safety mechanism. Dense but nearly every clause adds information; the nested parentheticals ('with its name unless hide_title (set_delete_notice changes or suppresses it)') make a few sentences harder to parse than necessary.

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?

For a destructive, non-idempotent mutation with an output schema already present, the description covers effect, reversibility, audit trail, and the dry-run/confirm safety gate. An agent has everything needed to decide and to invoke correctly without needing return-value details.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema doesn't: confirm must be set to the entry's VHID as returned by the dry run, hide_title controls the public notice content rather than just a flag, and the dry-run/real-run pairing is explained. It does not restate the entry parameter's VHID/short-name/QID forms, but the schema covers those fully.

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, and triggering condition: 'delete an entry because its Wikidata item is deleted', and anchors it to the 'Delete' button on the 'Deleted on Wikidata' review list. This clearly separates it from delete_entry (ordinary deletion) and keep_wikidata_deleted_entry (the opposite action).

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?

Places the tool in a concrete workflow (the 'To review' list) and warns 'A deletion on Wikidata is a reason to look at an entry, not to delete it', which is real usage guidance. It names restore_deleted_entry and set_delete_notice as related tools, but never mentions keep_wikidata_deleted_entry, the sibling that represents the alternative decision, so the when-not-to-use branch is implied rather than stated.

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.