Skip to main content
Glama

Edit an entry’s text

update_entry_fields
Destructive

Change an entry’s title, subtitle, description or short name, or remove its “from Wikipedia” credit or name the Wikipedia page it came from — a live edit, as the editor saves one: a new revision, audited. Give only what changes; null clears a field. The description is HTML (sanitised on save). A field you change here is no longer managed by the Wikidata sync; to hand one back, so the next sync refreshes it from the item, use set_wikidata_ownership (relinquish_fields). Dry run by default. To ask a reviewer instead, use propose_entry_change.

Input Schema

NameRequiredDescriptionDefault
entryYesThe entry: its VHID (11 digits), its short name (as in verifiedhandles.org/<short>), or its Wikidata QID (Q42).
shortNoThe short name in the entry’s URL; null removes it (the VHID URL stays).
titleNo
dry_runNotrue (the default): write nothing — show the change and the exact request it would send. false: make the change.
summaryNoWhy 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.
subtitleNo
descriptionNo
idempotency_keyNoOptional: 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).
base_revision_idNoThe 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.
credit_wikipedia_pageNoCredit the description “from Wikipedia”: an English Wikipedia article or draft, by title ("Draft:Dominic McLaughlin") or address. The server reads the page (redirects followed) and refuses it unless at least half of the description’s three-word phrases are the page’s lead (credit_text_differs, with the share).
remove_wikipedia_creditNotrue: remove the “from Wikipedia” credit from the description.
credit_let_wikidata_manageNoWith a draft named in credit_wikipedia_page: false keeps the description site-authored. By default a draft’s credit hands the description to the Wikidata sync, which leaves it alone until the draft is an article linked from the entry’s Wikidata item.

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. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructive/not-read-only/not-idempotent, but the description adds substantial context beyond them: live edit creating a new audited revision, dry-run-by-default behavior, null-clears semantics, HTML sanitisation on save, the credit validation threshold (half of three-word phrases, credit_text_differs), and the effect on Wikidata ownership. 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?

Front-loads the core purpose and packs in a lot of value, but the prose is dense and relies on em-dashes and parentheticals that make it read as a single sprawling paragraph. Still, nearly every clause earns its place with routing or behavioral detail.

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 complex 12-parameter mutation tool with an output schema, the description covers what an agent needs: scope, dry-run default, ownership side effects, credit validation, idempotency-key semantics, and the alternative reviewer workflow. Return values are handled by the output schema, so nothing material 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?

Schema coverage is 75% and already documents most params, but the description adds cross-cutting semantics that the schema lacks: 'Give only what changes; null clears a field', the description-is-HTML note, and the ownership handoff for edited fields. It meaningfully enriches the 12-parameter surface.

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 specific verbs and the exact fields it edits (title, subtitle, description, short name, Wikipedia credit) and explicitly names the sibling it is not: propose_entry_change. An agent can distinguish this from propose_entry_change, update_entries, and set_entry_setting without opening any schema.

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

Usage Guidelines5/5

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

Carries explicit routing rules — 'To ask a reviewer instead, use propose_entry_change' and 'to hand one back ... use set_wikidata_ownership (relinquish_fields)' — plus the condition that changed fields exit Wikidata sync management. When-to-use and when-to-use-something-else are both covered.

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.