Verified Handles

Change an entry’s setting

set_entry_setting

DestructiveIdempotent

Set one of an entry’s settings, as the Entry manager’s switches do: who may edit it live (edit_policy: "trusted" | "admin" — "admin" locks it), who may propose changes (propose_policy: "registered" | "trusted" | "admin" | "closed"), protected from the Wikidata sync, history hidden (needs the Hide history permission), kept off Trending, verified, follow this entry’s handle links (follow_links: its handle links are followed as a verified entry’s are), how many accounts its page shows before “Show more” (handles_shown: a whole number, 0 = every account, null = the site-wide rule; use sparingly), or its spotlight rank (a whole number, 0 = none). A Verified change takes an optional message, kept in the audit log. Audited; undo by setting it back. To delete an entry use delete_entry. Dry run by default.

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).
`value`	Yes
`reason`	No	Why, for a Verified change (either way), kept in the audit log. Plain words; any other setting keeps none.
`dry_run`	No	true (the default): write nothing — show the change and the exact request it would send. false: make the change.
`setting`	Yes

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.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / reason

Added value: +{
+  "description": "Why, for a Verified change (either way), kept in the audit log. Plain words; any other setting keeps none.",
+  "maxLength": 500,
+  "type": "string"
+}

Changed2 schema fields changedOct 25, 2026

changedInput schema / properties / setting / enum

Previous value: -[
-  "edit_policy",
-  "propose_policy",
-  "protected",
-  "history_hidden",
-  "trending_hidden",
-  "verified",
-  "follow_links",
-  "spotlight"
-]New value: +[
+  "edit_policy",
+  "propose_policy",
+  "protected",
+  "history_hidden",
+  "trending_hidden",
+  "verified",
+  "follow_links",
+  "spotlight",
+  "handles_shown"
+]

changedInput schema / properties / value / anyOf

Previous value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "maximum": 1000000,
-    "minimum": 0,
-    "type": "integer"
-  },
-  {
-    "maxLength": 20,
-    "type": "string"
-  }
-]New value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "maximum": 1000000,
+    "minimum": 0,
+    "type": "integer"
+  },
+  {
+    "maxLength": 20,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / setting / enum

Previous value: -[
-  "edit_policy",
-  "propose_policy",
-  "protected",
-  "history_hidden",
-  "trending_hidden",
-  "verified",
-  "spotlight"
-]New value: +[
+  "edit_policy",
+  "propose_policy",
+  "protected",
+  "history_hidden",
+  "trending_hidden",
+  "verified",
+  "follow_links",
+  "spotlight"
+]

AddedOct 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: dry run is default, changes are audited, they can be undone by setting the value back, and history hiding requires the Hide history permission. It also explains locking behavior, the optional audit reason for Verified changes, and cautions that handles_shown should be used sparingly.

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?

The purpose is front-loaded and every clause carries specific information, which is justified by the nine settings. However, the main sentence is very long and could be more scannable as a list, and the final dry-run sentence partly repeats the schema description.

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, destructive potential, and permission-sensitive settings, the description provides enough operational context: what each setting does, required permissions, audit behavior, undo path, and deletion routing. An output schema exists, so return-value detail is not needed here.

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?

Schema coverage is only 60%, but the description compensates extensively by explaining every setting and its accepted values, including edit_policy, propose_policy, follow_links, handles_shown semantics (0 vs null), and spotlight rank. It also clarifies the reason and dry_run parameters beyond what the schema states.

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 and resource: "Set one of an entry’s settings," then enumerates the actual settings and values. It also distinguishes deletion by pointing to delete_entry, so an agent can separate it from the delete sibling.

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?

Gives clear context through the setting list, the dry-run default, and the explicit "To delete an entry use delete_entry" alternative. It does not contrast with other update siblings such as update_entry_fields, bulk_change_entries, or set_trending, so some alternative routing is left implicit.

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.