Verified Handles

Hand fields or handles to Wikidata, or take them back

set_wikidata_ownership

Destructive

Say who manages an entry’s fields and handles. relinquish_* hands them to the Wikidata sync (the next sync refreshes them, and a relinquish queues one); takeover_* takes them back, so the sync leaves them alone. release_held_handles lets the sync add back handles that were held back after a removal. A live edit, audited. Dry run by default. To ask a reviewer instead, use propose_entry_change.

Input Schema

Name	Required	Description
`entry`	Yes	The entry: its VHID (11 digits), its short name (as in verifiedhandles.org/<short>), or its Wikidata QID (Q42).
`dry_run`	No	true (the default): write nothing — show the change and the exact request it would send. false: make the change.
`summary`	No	Why you made this edit, in a few plain words; shown in the entry’s public history. At most 200 characters. Never an internal tracking ID (a backlog or ticket number); a VHID is fine.
`idempotency_key`	No	Optional: a key you choose (1–255 printable ASCII, e.g. a UUID), sent as the write’s Idempotency-Key. Calling again with the same key and the same change within 24 hours answers the first call’s result (replayed: true) and writes nothing; the same key with another change is refused (422).
`takeover_fields`	No
`base_revision_id`	No	The revision you read (get_entry → editing.baseRevisionId). If the entry has changed since, the edit is refused as a conflict. Left out, the current revision is used.
`takeover_handles`	No
`relinquish_fields`	No
`relinquish_handles`	No	Only while Wikidata lists the value.
`release_held_handles`	No

Output Schema

Name	Required	Description
`note`	No	A dry run: what to do next to make the change, in words.
`result`	No	A real run: the route’s own answer, where the tool adds facts of its own beside it.
`confirm`	No	A dry run of a change that needs it: the exact target to send back as `confirm` with dry_run: false.
`dry_run`	No	true: a dry run, which wrote nothing. Absent from a real run.
`replayed`	No	A real run with an idempotency_key already used for this change: the first call’s answer, given back; nothing was written now.
`would_send`	No	A 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_live`	No	A dry run of a live edit: whether this key’s account may edit this entry live.
`refused_because`	No	A dry run the real run would be refused for: why, in words.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations (which already flag destructiveHint=true and idempotentHint=false), the description adds real context: the edit is live and audited, dry_run defaults to true, a relinquish queues a sync, and takeover makes the sync "leave them alone." It does not describe the conflict/idempotency replay behavior, but the schema covers those. No contradiction with annotations.

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?

Roughly six short sentences that are front-loaded with the core operation, then the mode semantics, then the fallback tool. Dense but every sentence carries information; no filler or repetition.

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?

For a 10-parameter mutation tool with an output schema, the description covers the essential mental model (ownership transfer, sync effects, dry-run default, audit trail, reviewer alternative). Remaining details (constraint that a handle must currently be on Wikidata, revision conflicts) are already in the schema, so nothing critical is missing.

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?

With 60% schema coverage, the description earns credit by giving meaning to the parameter families it names: what relinquishing does to the sync, that takeover reverses it, and that release_held_handles re-adds held-back handles. Individual params like entry, summary, and base_revision_id are left to the schema, which documents them well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys a specific operation: transferring management of an entry's fields and handles between the editor and the Wikidata sync, with relinquish_*/takeover_* semantics spelled out. It also differentiates from the sibling propose_entry_change. The phrasing "Say who manages..." is a bit abstract as a verb, but the surrounding sentences make the effect unambiguous.

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 explicitly routes the agent to an alternative ("To ask a reviewer instead, use propose_entry_change") and explains the differing behaviors of relinquish vs takeover vs release. It stops short of contrasting with other direct-write siblings such as update_entry_fields or update_entry_handles, so the when-to-use picture is partial.

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

All Verified Handles tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.