Verified Handles

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

Adds traits the annotations don't: 'staff-only' discloses visibility scope, 'Audited' discloses that the action is logged, and 'Dry run by default' warns that the call previews rather than writes unless overridden. This is meaningful context for a non-readOnly, non-idempotent mutation, though it omits who is authorized and whether repeated identical adds create duplicates.

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

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

Three compact fragments, purpose front-loaded, no filler. Each clause ('staff-only', 'links are kept', 'Audited', 'Dry run by default') carries a distinct piece of information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the identifier semantics for entry are covered in-schema. The description covers visibility, audit, and the dry-run gate, leaving only minor gaps around authorization and duplicate-note behavior.

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

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

Schema coverage is 67%: entry and dry_run are documented in-schema, while text is not. The description partially compensates by specifying that text is 'plain text' and that 'links are kept', which is real semantic value the schema lacks, but it says nothing about length limits or content restrictions.

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

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

States a specific verb+resource ('Add a ... note to an entry') and qualifies the note as 'staff-only internal', which sets it apart from public comments like comment_on_application. It doesn't explicitly differentiate from edit_entry_note or delete_entry_note, but the verb choice makes the distinction inferable.

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

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

No statement of when to use this tool versus edit_entry_note, delete_entry_note, or list_entry_notes, and no prerequisites or exclusions. The only usage signal is the default dry_run behavior, which is implied rather than explained as a workflow step.

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

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

Annotations already flag this as destructive, non-idempotent and mutating, and the description goes well beyond them: it discloses that a live entry is created, the applicant is emailed, the assessment is overwritten with the given fields, the action is audited, and the dry run surfaces policy shortfalls and Wikidata-item conflicts.

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

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

Front-loaded with the action and its effects, and every sentence carries information — side effects, warning behavior, the self-approval restriction, auditability, default mode. It is dense and slightly packed but has no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-effect approval tool with an output schema and fully documented parameters, the description covers side effects, preconditions, the self-approval restriction, and the safe default. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top, explaining that dry_run defaults to true and only warns, and that assessment fields are applied as changes to the current assessment rather than supplied wholesale.

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

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

States a specific verb and resource (approve an application) and enumerates the concrete consequences: the entry goes live from its proposal, the assessment is recorded alongside it, and the applicant is emailed. This clearly separates it from siblings like reject_application or assess_application without opening a schema.

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

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

Gives an explicit exclusion — never approve your own application unless you could create that entry directly — plus the default dry-run posture and the conditions the dry run warns about. It stops short of naming an alternative tool, but the when/when-not conditions are clear.

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

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

Annotations declare non-readOnly, non-destructive, non-idempotent, but the description adds the real behavioral payload: the question is posted to the thread, the applicant is emailed, the application enters a waiting (needs_info) state until reply, and the action is audited. That is exactly the beyond-annotations context an agent needs.

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

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

Three tight sentences with no filler; the core action and its consequences are front-loaded, with the precondition, audit note, and dry-run default following compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, a 100%-covered input schema, and full annotations, the description supplies everything else an agent needs — purpose, side effects, precondition, audit, and default dry-run behavior — leaving no critical gap.

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

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

Schema description coverage is 100%, so parameters are already documented, and dry_run's default and message's limit are fully covered. The description clarifies the effect of the message (thread + email) but adds little parameter-level detail beyond what the schema states, matching the baseline.

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

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

States a specific verb (ask), resource (applicant), and the concrete effects — thread post, email, and transition to needs_info. These side effects clearly distinguish it from a plain comment_on_application, letting an agent pick the right tool without opening schemas.

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

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

'Only for an application waiting on a reviewer' is an explicit precondition that tells the agent when the tool applies. It stops short of naming alternatives (e.g., comment_on_application for non-blocking messages), so it lands just below the top band.

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

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

Annotations already declare the mutation profile (readOnly=false, destructive=true, idempotent=false), so the safety bar is partly covered. The description adds genuinely new behavior: partial-merge semantics ('give only the fields that change; the rest stay as the application has them'), auditing, and the score preview from dry run.

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

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

Three tight clauses with no filler: partial-update rule, dry-run preview, audit note. Front-loaded with the core action and the critical 'without deciding it' qualifier.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter scoring mutation with an output schema, the description covers everything the agent needs: what it writes, the no-decision constraint, merge semantics, dry-run default, and auditability. Return values are legitimately covered by the output schema.

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

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 a semantic the schema does not: unspecified fields are preserved rather than cleared. That merge behavior materially affects how an agent should populate the 8 parameters, so it earns above baseline.

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

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

States a specific verb and resource — 'Save your assessment of an open application against the eligibility policy' — and immediately scopes it as 'without deciding it.' That clause cleanly separates it from the decision siblings (approve_application, reject_application, mark_application_spam) without needing to open either schema.

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

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

Gives clear usage context: it applies to 'an open application' and is explicitly not the deciding action, and it notes the default dry-run posture. It never names an alternative tool explicitly (e.g. 'to decide, use approve_application'), so routing is inferred rather than stated.

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

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

Beyond the destructive annotation, the description adds substantial context: one audit row for the whole change, revertability via revert_bulk_change, dry-run behavior, permission requirements, merged-entry deletion behavior, and that entries already in the target state are left alone.

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

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

The purpose is front-loaded and almost every clause carries necessary information about settings, audit behavior, or confirmation. It is dense and could be easier to scan if split, but there is little actual waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex bulk mutation tool, the description covers selection scope, dry-run safety, confirmation, permissions, audit/revert behavior, and most setting semantics. With annotations and an output schema also present, no major agent-facing gap remains.

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

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

Schema coverage is 50%, so the description must carry weight, and it does: it maps most `setting` values to behavior and explains `dry_run`, `confirm`, and `reason` semantics. However, `handles_shown` is not mentioned and the value-type mapping across settings remains only partially clarified.

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

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

The description states a precise verb and resource: set one setting to one value on up to 500 entries identified by VHID. The scope and bulk nature clearly distinguish it from single-entry siblings such as set_entry_setting.

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

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

It explains the dry-run-first workflow, that the real run requires `confirm` from the dry run, and that revert_bulk_change undoes the whole change. It also notes permission constraints for specific settings, though it does not explicitly name single-entry alternatives like set_entry_setting.

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

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

Adds traits beyond the annotations: the comment is visible to the applicant, does NOT trigger an email, the action is audited, and it runs as a dry run by default. These are concrete, consequential behaviors (safety-by-default, audit trail, notification semantics) not derivable from readOnlyHint/destructiveHint/idempotentHint alone.

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

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

Three tight sentences, front-loaded with the action and its visible effect, then the alternative, then the audit/dry-run notes. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, a 100%-covered schema, and an output schema present, the description supplies exactly the missing context (visibility, notification, audit, dry-run default) an agent needs to call it correctly. Nothing material is omitted.

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

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

Schema coverage is 100%, so body, dry_run, and application_id are already fully documented (including the dry_run default and body length limits). The description only restates the 'applicant sees it' semantics already present in the schema, so the baseline 3 applies.

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

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

States a specific verb (add a message) and resource (an application's thread) and immediately defines the scope ('applicant sees it on their application'). It names the sibling ask_applicant and distinguishes itself from it, so an agent can route without opening a schema.

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

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

Explicitly gives the when-not/alternative: 'To ask them something and wait for the answer, use ask_applicant.' The condition that selects the alternative is stated, leaving nothing to inference.

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

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

Beyond the annotations (readOnlyHint=false, idempotent=false, dry-run not declared there), the description adds real behavioral context: the comment is 'Audited', it is 'Dry run by default', both reviewer and submitter see it, and answering a reviewer's question routes the application back to them — a non-obvious side effect an agent must know. This meaningfully exceeds what the structured fields convey.

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

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

The content is front-loaded: purpose first, then the reviewer/submitter visibility nuance, then the two terse operational flags ('Audited. Dry run by default.'). The parenthetical audience clause is dense but earns its place; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers the important operational facts (auditing, dry-run default, visibility, workflow routing). The only remaining gap is that it doesn't explicitly contrast with the near-identical comment_on_application sibling, which an agent choosing between them would benefit from.

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

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

Schema coverage is 100%, so both required parameters (id, text) and dry_run are fully documented in the schema itself, including formats and limits. The description adds only the audience framing around 'id' and repeats the dry-run default, so it does not go meaningfully beyond the schema — baseline 3 applies.

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

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

The description states a specific verb and resource — adding a message to a submission — and immediately scopes it by audience ('this key's own account's submissions', or 'any they may see' for a reviewer). That audience split is what separates it from the sibling comment_on_application, so an agent can distinguish the two without opening a schema.

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

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

It gives clear context for when this tool applies (commenting on your own submission, or a reviewer commenting on something visible) and notes the concrete case of answering a reviewer's question. It stops short of naming the alternative sibling (comment_on_application) or stating explicit exclusions, so it is clear-but-not-routing.

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

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

Annotations already declare destructive=true and idempotent=false, and the description adds substantial context on top: no review step, ongoing sync of title/subtitle/description/image/handles, audited, and the specific 409 qid_merged refusal with a redirect to wikidata_item. That is exactly the beyond-annotation behavioral detail this dimension rewards.

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

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

Front-loaded with the core action and structured as operation → behavior/refusals → alternative. Dense and long in absolute terms, but nearly every clause (sync, refusals, 409 code, audit, dry run) carries operational weight, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description fills the remaining gaps: creation path, sync behavior, refusal/error handling, audit trail, dry-run default, and the sibling alternative. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and both params are documented in-schema, so the baseline is 3. The description adds meaning beyond the schema, though: it clarifies that dry_run (the default) 'names the entries already on the item,' and explains the QID's merged-away handling that the schema only constrains by regex.

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

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

States a specific verb+resource ('Create a live entry straight from a Wikidata item') and frames it as the Console → Create from QID flow, so the agent knows exactly what operation is performed. It also distinguishes itself from the sibling propose_new_entry by contrasting 'no review step' with 'propose it for review instead.'

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

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

Explicitly names the alternative ('To propose it for review instead, use propose_new_entry with qid') with the condition that selects it. It also documents refusal conditions (already on the item, or on a merged item) and routes the agent to the surviving QID via wikidata_item, which is genuine when/when-not guidance.

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

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

Annotations only say destructive/not idempotent; the description adds what an agent actually needs: the entry leaves the public site but is not erased, reason is private while listed in Console, page and links 404 unless a notice is supplied (then 410 with a fixed line and date), audited, and dry-run-by-default requiring confirm set to the VHID. That is substantive context beyond the structured fields.

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

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

Lead clause states the action and the public/console consequence first, then the notice behaviour, then dry-run/confirm and the sibling alternative. Dense and long, but nearly every clause carries operational information; the notice enumeration could be trimmed since the enum itself lists the values.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 confirm-gated dry-run, the description covers irreversibility (only soft), restoration path, audit trail, public-visibility effects and the 404/410 distinction. Return values are covered by the output schema, so nothing essential is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds public-effect semantics the schema lacks — the 410 status and per-enum fixed line, hide_title suppressing the name on the notice, and reason being private but listed. Minor friction: it says confirm must be the entry's VHID while the schema says 'this change's exact target, as the dry run gives it'.

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

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

Opens with a specific verb+resource ('Delete an entry') and immediately distinguishes it from look-alikes by naming restore_deleted_entry, set_delete_notice and report_entry. An agent can separate this from delete_wikidata_deleted_entry / delete_renamed_short without opening a schema, since the entry-address and 404/410 consequences are stated.

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

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

Gives real routing guidance: 'leave notice out for a removal at the subject's request', 'to ask for it instead, use report_entry', and set_delete_notice for later changes. It stops short of covering the neighbouring deletion variants (delete_wikidata_deleted_entry, delete_renamed_short) or when deletion should be refused in favour of a merge.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the note's content is retained in the audit log (so the deletion is discarding visibility, not history) and the operation is permission-gated to the author or entry managers.

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

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

Three compact sentences, front-loaded with the action and followed by the constraint and the default. 'Dry run by default' mildly duplicates the schema default, but as a headline safety cue it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not needed. The description covers the key things an agent needs: permission scope, audit-log retention, and the dry-run default. It stops short of describing failure modes (e.g., invalid note_id) but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 67%: 'entry' is richly documented in the schema (VHID/short name/QID) and 'dry_run' explains both branches. The description adds no parameter detail of its own beyond restating the dry-run default, and note_id carries only a regex pattern with no prose anywhere. Baseline 3 is appropriate.

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

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

States a specific verb ('delete') and resource ('an internal note on an entry'), which cleanly separates it from add_entry_note, edit_entry_note, and list_entry_notes. It even adds scope qualifiers (author or entry managers), so an agent can identify the operation without opening the schema.

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

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

The permission parenthetical ('its author, or anyone who manages entries') tells the agent who is eligible, and 'dry run by default' hints at the safe call pattern. However, there is no explicit guidance on when to delete versus edit_entry_note, nor any stated precondition or when-not-to-use condition.

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

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

Beyond the destructive annotation, the description discloses immediate behavioral effects: /<key> stops leading to the entry, becomes a 404 at once, and is removed from the site’s cache. It also notes auditing and the dry-run/confirm workflow, adding meaningful operational context.

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

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

The purpose is front-loaded, but the first sentence is dense and contains a confusing clause about an entry taking the old name as its short name. The information is largely useful, but the structure could be clearer and more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with full schema coverage, annotations, and an output schema, the description is complete. It covers effects, prerequisites, exclusions, auditing, and the dry-run/confirm flow.

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

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

Schema description coverage is 100%, so key, confirm, and dry_run are already documented in the schema. The description reinforces their roles but adds little syntax or format detail beyond what the schema already provides.

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

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

The description states a specific verb and resource: removing an entry’s old short name. It also distinguishes this from an entry’s current short name and the old wiki’s aliases, so the agent can tell exactly which resource is targeted.

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

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

It clearly states when to use it: only for an old short name left by a rename, never for the current short name or old wiki aliases. It also explains the dry-run default and the confirm requirement for real execution, though it does not name sibling alternatives.

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

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.

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.

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.

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.

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.

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.

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds real context beyond them: the author-only permission rule, an audit trail, and the dry-run-default behavior. It does not explain what happens to the prior note text or whether history is retained, which is the main residual gap for a destructive edit.

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

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

Three terse clauses, front-loaded with the action and followed by the two facts an agent most needs before calling. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers auth, audit, and dry-run for this mutation. The missing pieces are note_id provenance and whether the overwritten text is recoverable, which matter for a destructive rewrite.

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

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

Schema coverage is only 50%: entry and dry_run are documented inline, while text and note_id have no descriptions anywhere. The description reinforces the dry-run default but does not explain note_id's format or where to obtain it (e.g., list_entry_notes), so it does not compensate for the coverage gap.

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

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

States a specific verb and resource ("Rewrite ... internal notes on an entry") and scopes it with "one of your own," which separates it from add_entry_note, delete_entry_note, and list_entry_notes without ambiguity. It stops short of naming a sibling explicitly, so it is clear but not maximally differentiated.

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

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

"only its author may" gives a hard precondition and "Dry run by default" tells the agent the safe calling pattern. It never states when to pick this over add_entry_note or delete_entry_note, but the rewrite semantics imply the context well enough.

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

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

Annotations only declare readOnlyHint and openWorldHint=false, but the description adds real behavioral context: an empty list is returned when nothing matches, case is ignored where the platform ignores it, and emails are excluded. This goes meaningfully beyond what the annotations convey.

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

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

The purpose is front-loaded as the quoted question, followed by input forms then output behavior. It is a single dense block with no wasted sentences, though the packing of output fields, case rules and the email caveat into one paragraph makes it slightly heavy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't restate return values, yet the tool is a simple read lookup whose annotations and schema cover safety and inputs well. The only meaningful gap is any statement of when this should be chosen over the other entry-retrieval siblings.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds the mutual-exclusivity relationship the schema does not express ('url ... instead of platform and value') and gives concrete value formats (someone or @someone), which helps the agent pick a valid input shape.

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

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

States a specific verb+resource (find entries by handle) and frames it as a reverse lookup, quoting the exact question it answers ('is x.com/someone an official account, and whose?'). This clearly separates it from siblings like get_entries and search_entries, which are not handle-keyed lookups.

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

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

Explains the two input ways ('Give a profile's address as url... or platform... and value') and gives an explicit exclusion ('Email addresses are not looked up'). It does not name a competing sibling tool or state when to prefer this over search_entries, so it stops short of full when/when-not routing.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses per-item result semantics ('each answered as get_entry answers it signed out — the entry, or not_found'), guarantees result ordering, and states that duplicated names are collapsed to one answer. That is genuinely useful behavioral context an agent cannot get from the annotations.

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

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

A single dense sentence with zero filler; the batch size, accepted inputs, and fallback routing are all front-loaded before the per-item result behavior. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, the description covers the remaining gaps an agent needs — input forms, limit, ordering, dedup, and per-item failure mode. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, but the description still adds value: it clarifies the accepted identifier forms, rules out QIDs (a critical constraint the schema's string pattern does not cover), and explains deduplication semantics for repeated names.

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

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

States the specific action (fetch public records for many entries in one call), the identifier forms accepted (VHID or short name), and the batch limit. It explicitly differentiates from siblings by excluding Wikidata QIDs and naming get_entry and search_entries as the tools for the item-based lookup.

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

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

Gives a clear when-not rule ('not a Wikidata QID') and routes the agent to the correct alternatives for that case. Batch-vs-single usage is implied by 'up to 50 ... in one call' rather than stated outright, so it stops short of a full when/when-not/alternatives treatment.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the description's added value is the auth-dependence ('Without an API key, the public record alone') and the disclosure that the payload expands into an `editing` block including live-edit permission. That is meaningful behavior beyond the structured fields; only rate limits / not-found behavior are unaddressed.

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

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

It is a single dense sentence-pair that front-loads the lookup keys before the payload detail, with no filler. It borders on overlong for a read tool, and the em-dash cascade of returned fields is harder to scan than a short list would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description needn't explain return values, yet it does, plus the auth-gated difference between public and editing payloads. What remains missing is minor: not-found/error behavior and whether the entry key is case-sensitive.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the description merely restates the three accepted key forms (VHID, short name, QID). The `include_platforms` auth requirement is stated in the schema, not added here, so baseline 3 applies.

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

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

The description opens with a precise verb+resource and a retrieval key set ('One entry, by VHID, short name or Wikidata QID'), then enumerates the returned record. It implicitly separates itself from get_entries (plural) and get_entry_history by describing the current-record payload, but it never names a sibling to differentiate against explicitly.

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

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

'Without an API key, the public record alone' gives a real conditional on when you get the full editing payload, which is useful context. However, there is no guidance on choosing this over get_entry_admin, get_entry_history, find_by_handle, or search_entries — the agent has to infer the boundary from the return-shape prose.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds useful content-level context, including field_sources, synced_at, retry_at, merge state, duplicates, history, and audit trail, but does not mention admin permissions, access requirements, or pagination behavior.

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

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

The description is front-loaded and keeps to a single dense sentence with no filler. Every listed element corresponds to useful card content, though the long parenthetical sequence is somewhat hard to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, full parameter schema coverage, and read-only annotations, the description does not need to explain return values or parameter syntax. It is complete about the card’s contents but leaves the critical get_entry vs get_entry_admin choice and admin-access expectations unstated.

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

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

Schema description coverage is 100%, so the schema already documents that the entry parameter accepts a VHID, short name, or QID. The description only says 'by VHID', which adds no meaning beyond the schema and slightly under-represents the accepted identifier formats.

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

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

The description specifies a clear verb-and-resource: retrieving the Entry manager’s card for one entry, including deleted and merged entries. It does not explicitly distinguish itself from the sibling get_entry tool, leaving the admin-vs-public distinction implicit in the title and phrasing.

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

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

The description lists what the card contains but gives no explicit guidance on when to use this tool instead of get_entry, get_entries, or get_entry_history. The only hint is that deleted and merged entries are included, which implies an admin use case without stating it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: newest-first ordering, pagination ('next_offset pages on'), and the merged-entry key behavior. Note the response token 'next_offset' is referenced but absent from the schema, which is useful output context.

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

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

Two short sentences, front-loaded with the core purpose and followed by scope/edge-case detail. Nearly no waste, though the parenthetical 'next_offset pages on' is slightly cryptic without schema support.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the read-only nature is covered by annotations. However, the undocumented limit/offset parameters and the absence of any when-to-use framing leave the definition only minimally complete for a paginated history tool.

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

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

Schema description coverage is only 33%: 'entry' is documented, but 'limit' and 'offset' have no description anywhere. The description does not compensate for those gaps (e.g., paging semantics, defaults, max values), leaving half the parameters ambiguous.

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

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

States a specific verb+resource: an entry's public edit history, newest first. It distinguishes itself from get_entry/get_entry_admin by specifying 'public' history, and it handles the merged-entry edge case. Clear, though it does not explicitly name a sibling to avoid.

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

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

No explicit when-to-use/when-not guidance or routing to alternatives (e.g., get_entry_admin for admin history). Usage is implied by the resource name, and the merged-entry note is a partial hint, but nothing tells the agent which of get_entry, get_entry_admin, or this tool to pick.

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

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

Annotations already cover read-only status, but the description adds genuinely new behavior: it 'Reads the item live through the sync's rate limit', explains `state: unknown` when Wikidata did not answer, and describes `propose: null` with `pending_id` while a change waits in Review. That is useful context beyond the annotations, though the write-side routing is buried in output prose.

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

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

The purpose is front-loaded in the first clause, but the remainder is a single sprawling ~400-word block of nested parentheticals detailing return fields. Since an output schema already exists, this return-value exposition largely duplicates structured data and is not appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex reconciliation read with a simple input schema and a present output schema, the description covers read semantics, rate limits, and the meaning of null/pending states and follow-up tools. It falls short only on explicit when-to-use guidance relative to sibling readers.

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

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

There is a single parameter and schema description coverage is 100%, with the schema fully explaining VHID/short-name/QID forms. The description adds nothing about the `entry` argument, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb+resource ('Console → Wikidata, per entry, as JSON: the entry against its Wikidata item, value by value'), which separates it from plain entry readers like get_entry or handle_health. It is clear what the tool is, but the phrasing is idiosyncratic and never states its name's scope plainly.

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

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

Usage is only implied: it says the field `propose` is 'the change propose_wikidata_changes could carry' and that removing a handle is done 'with update_entry_handles', which routes follow-up actions. However it never states when to call get_reconcile rather than get_entry or handle_health, nor any prerequisite.

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

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

Annotations already mark this readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes well beyond that: it explains each check's meaning, that a job auto-adds a missing half when the checker confirmed it and the case is known (with the rest deferred to a person), that YouTube supplies handles lower-cased so `offer.case_known` may be false, and that results are oldest-first, 50 per page. That is real behavioral context the annotations do not carry.

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

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

The bulk is one enormous run-on sentence cramming five check definitions, output shape, pagination, and remediation routing into a single breath. Only the trailing sentences are separable. The key purpose statement is buried mid-clause rather than front-loaded, so the reader must parse the whole thing to learn what the tool is.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the per-check counts and handle listings need not be re-explained, yet the description spends most of its length on them while leaving practical gaps: how the agent obtains a valid `check` id (presumably from the `checks` output), and what happens when no `check` is supplied. For a read-only diagnostic whose safety is annotation-covered, this is adequate but not tight.

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

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

Schema description coverage is 67%: `vhid` and `check` are documented in the schema, `page` is not. The description reinforces `check` semantics ('lists the handles that fail it') and adds pagination/ordering detail ('oldest first, 50 a page'), plus that `vhid` is counted live. That is marginal value over the schema and consistent with the 3 baseline for high-ish coverage.

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

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

The apenultimate clause reveals the tool is a report of malformed/stored handle values, and the check ids establish the resource as 'handles'. But the opening clause is a dense fragment with no verb, so an agent must reconstruct 'this lists handles that fail health checks' from the check vocabulary rather than reading it stated. It is distinguishable from siblings like get_reconcile and update_entry_handles, but only indirectly.

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

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

The final sentence routes the agent: 'Fix or add with update_entry_handles,' which names the alternative for remediation. However, there is no explicit statement of when to reach for this tool (e.g. before a sync, after a reconcile, to audit an entry) and no exclusions. Usage is implied by the check list rather than declared.

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

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

With readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=false already declared, the description still adds real context: the sync keeps reading the item so the entry re-syncs automatically if Wikidata restores it, the QID prevents re-offering as a new item, re-deletion returns it to "To review", and the action is audited. It doesn't reconcile the apparent tension between "leaves it exactly as it is" and destructiveHint=true, nor explain what auditing entails, so it stops short of 5.

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

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

The main effect and the alternative path are front-loaded, followed by consequences, then undo, audit and dry-run in a tight single paragraph with no filler. Dense nesting of quoted UI labels makes it heavier reading than it needs to be, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-machine workflow tool with an output schema and full annotation coverage, the description covers the transitions, the automatic re-sync consequence, the undo path, and the dry-run default. Nothing an agent would need to invoke it correctly in the review workflow is missing.

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

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 genuinely adds meaning: it clarifies what undo actually targets (an entry in "Kept, still linked", reverting to "To review") and that reason is recorded with the decision record, beyond the schema's terse 'why it is kept'. The dry_run default is restated rather than expanded.

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

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

It states a specific verb and resource (keep an entry whose Wikidata item was deleted) and the concrete effect: removes it from the "To review" list while leaving the entry linked to its deleted item. The mapping to the UI action "Keep, still linked" separates it from the sibling delete_wikidata_deleted_entry and restore-style tools. The jargon-laden opening sentence slightly obscures the plain statement of purpose.

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

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

It gives the exact applicability conditions: an entry sitting in "To review" because its Wikidata item was deleted, plus the inverse state ("Kept, still linked") required for undo. It does not explicitly name a sibling tool to prefer instead, but the state-machine framing makes the when-to-use boundary inferable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds real behavior: 30 items per page, ordering (oldest first for review queues), the assessment fallback rule (reviewer's saved one, else what the applicant claims), and per-item flagging of whether this account may approve it. That permission-awareness and sort/fallback context go beyond the annotations, though pagination limits and total counts are not discussed.

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

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

Core purpose is front-loaded, but the body is one sprawling compound sentence with nested parentheticals and semicolon-chained clauses, which is hard to parse. Much of the item-content enumeration duplicates what the output schema already provides.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all four parameters' modes, explains the two tab families and the application_id variant, notes permission awareness, and cross-references the deciding tool. With an output schema present, return-shape detail need not be in the description, and the remaining parameter space is adequately addressed.

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

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

Schema coverage is only 50%, and the description fully compensates: it maps each `tab` enum value to a concrete meaning (open, needs_info, approved, rejected, spam, retracted, all, proposals) and explains the proposals/decided split. It also conveys page size ("30 a page") and the application_id single-record mode, adding meaning the bare enum and schema fields do not.

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

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

Opens with a specific verb+resource: the applications queue for new entries (Console → Applications), and details exactly what each item contains (proposal, applicant's case, assessment, score, existing Wikidata entry, approval eligibility). It is clearly a listing tool for applications, distinguishable from entry-listing siblings such as get_entries or list_review_queue.

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

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

Explains when each `tab` mode applies ("open" to review, oldest first; "needs_info" awaiting the applicant; "proposals" for quick proposals with no eligibility case) and when to pass application_id. It also routes the agent to review_submission for deciding and names propose_new_entry as the source of proposals. It never explicitly excludes or contrasts with adjacent listing tools like list_review_queue or list_my_submissions.

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

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

The annotations already declare read-only and closed-world behavior, and the description adds meaningful context: the latest 50 changes, newest-first ordering, returned fields, and before-values for the bulk_id detail mode. It still does not clarify whether the 50-item cap is truncation with no pagination or how to access older bulk changes.

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

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

The definition is front-loaded with the default result, then immediately explains the bulk_id variant. Every phrase adds useful information, and the parenthetical helps orient the agent to the product area without wasting space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity read-only tool with one optional parameter, full schema coverage, annotations, and an output schema, the description covers both retrieval modes and the most important behavioral traits. No critical calling information is missing.

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

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 real meaning beyond the schema by explaining that bulk_id switches from the latest-50 list to one bulk change plus every affected entry with prior values. It does not repeat the schema's ID pattern, which is fine, and the 'With bulk_id' phrasing usefully implies the parameter is optional.

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

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

The description states a specific verb and resource: listing bulk changes to entries' settings, with a clear default and single-change mode. It is easy to distinguish from mutation siblings by name and behavior, but it does not explicitly name alternatives such as bulk_change_entries or revert_bulk_change.

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

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

It implies when to pass bulk_id by describing the resulting single-change view, but it gives no explicit when-to-use guidance versus sibling tools. There are no exclusions or named alternatives for listing other kinds of entry history.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the result marks which entry a merge would retain, and the no-qid mode is scoped to 'largest clusters still to merge', implying ordering/priority — genuinely useful context.

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

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

Two tight sentences, zero filler, with the core purpose front-loaded and the two input modes following. Every clause carries information about behavior or usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not required, and annotations cover safety. The description explains both invocation modes for a read-only listing tool with 2 params, leaving only minor gaps (no explicit sibling routing) for an otherwise complete definition.

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

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

Schema coverage is only 50% (qid has a pattern but no description), so the description must compensate, and it does: it defines what supplying or omitting `qid` returns. It also contextualizes `limit` via 'largest clusters', adding meaning beyond the schema's bare 'how many clusters'.

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

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

The description clearly states what the tool returns: entries sharing a Wikidata QID, annotated with the entry a merge would keep. It is a specific resource (duplicate QID clusters) distinct from action tools like merge_entry or unmerge_entry, though it never names a sibling to disambiguate against get_entries or search_entries.

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

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

It gives explicit conditional usage: pass a `qid` for that item's cluster, omit it for the largest clusters still to merge. This explains both operating modes clearly, but it stops short of naming alternatives or stating when-not to use the tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description is not carrying the safety burden. It still usefully adds that results are staff-only (an auth requirement), returned oldest-first (ordering), and annotated with per-key permitted actions — none of which the annotations convey.

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

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

A single dense sentence front-loads the resource and scope, then adds ordering and content detail with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained, and the description covers auth scope, ordering, and the per-note permission payload. It omits pagination/volume behavior for what could be a long note list, a minor gap.

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

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

Schema description coverage is 100%, and the single 'entry' parameter is fully documented in the schema (VHID, short name, or QID). The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (list) and resource (staff-only internal notes on an entry), plus scope and ordering (oldest first). The 'list' framing clearly separates it from its write siblings add_entry_note, edit_entry_note, and delete_entry_note, though it never names them explicitly.

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

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

The 'staff-only' qualifier implies a precondition for use, but there is no explicit when-to-use/when-not statement and no reference to alternatives such as get_entry_admin or the note mutation siblings. Usage context is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds non-annotated behavior: newest-first ordering, a fixed page size of 25, the per-row fields returned, and that a single-id fetch can surface submissions a reviewer may also see. No destructive, auth, or rate-limit caveats beyond that.

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

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

Dense but front-loaded: the list behavior and ordering come first, then the filter and the single-id mode. Every clause carries information, though the appositive-heavy style makes it one long breathless run rather than cleanly separated sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return fields need not be spelled out, yet the description still names what each row carries. Pagination, ordering, and auth scope (this key's own account) are covered; only the exact semantics of the alternate `status: all` value and page-boundary behavior are left implicit.

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

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

Schema coverage is only 33% (page and status are undocumented in the schema), but the description compensates: it explains `status: open` as the filter for pending items and states the 25-per-page size, effectively documenting page. It adds meaning to `id` as well (yours or any a reviewer may see, with comment thread).

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

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

States a specific verb+resource (list this key's own submissions), enumerates the record types covered (proposed changes, new-entry proposals, claims, reports, applications), and scopes it to the key's own account, which cleanly separates it from list_review_queue and list_applications. An agent can identify it without opening the schema.

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

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

Gives clear context for how to steer the tool — `status: open` for the still-waiting ones, `id` to fetch a single submission with its comment thread — but never explicitly names an alternative sibling (e.g. list_review_queue) or states when not to use this tool. Clear context, no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real context beyond that: a hard 100-item cap, oldest-first ordering, and the fact that status switches to decided items while defaulting to pending. It does not discuss whether listing is paginated past 100 or what happens to excluded types, leaving a small behavioral gap.

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

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

Front-loaded with purpose, ordering, and limit in the first clause, then routing guidance. The parenthetical about new_entity is long but earns its place as a disambiguation; a few clauses are dense enough to require rereading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't document return shapes, and it covers the main operational facts an agent needs: scope, ordering, cap, exclusion of new_entity, and the deciding tool. Only pagination behavior past the 100-item limit and the less common status values are left unstated.

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

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

Schema coverage is only 33% (only `entry` is documented), but the description compensates by describing the `kind` values (correction/claim/report) in prose and explaining that `status` surfaces decided submissions versus the default pending queue. It doesn't spell out the full status enum semantics (merged, superseded, retracted), so it improves on but doesn't fully close the coverage gap.

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

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

States a specific verb+resource (list submissions awaiting a reviewer) plus scope details: content types (correction, claim, report), ordering (oldest first), and cap (up to 100). It explicitly carves out new_entity proposals and points to list_applications instead, so the agent can distinguish it from siblings without reading schemas.

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

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

Gives explicit when-to-use (reviewer queue, optionally with status for decided ones), when-not-to-use (new-entry proposals belong in list_applications with tab "proposals"), and names the follow-up action (decide with review_submission). Narrowing options are also stated.

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

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

Goes well beyond the annotations: it states the side effect (declined), the absence of notification to the applicant, irreversibility ('Cannot be undone'), and audit logging, plus the dry-run/confirm safety protocol. These are the exact behaviors an agent must know before a destructive call and are not derivable from destructiveHint=true alone.

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

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

Three compact sentences with no filler, and the highest-stakes facts (decline, no notification, irreversible) are front-loaded before the dry-run mechanics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, idempotency-free mutation there is an output schema and full parameter coverage, so the description only had to cover consequences, reversibility, audit, and the confirm workflow — all of which are present.

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

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

Schema description coverage is already 100%, so the baseline is 3; the description earns an extra point by clarifying the default (dry run) and the exact expected value of confirm (the application's id), tightening what the schema expresses more abstractly as 'this change's exact target'.

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

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

States a specific verb and resource ('mark an application as spam') and immediately discloses the concrete effect ('it is declined, and the applicant is not told'), which an agent can distinguish from approve_application or reject_application. It stops short of naming the alternative sibling (reject_application) or the boundary condition that would pick one over the other, so differentiation is inferable rather than explicit.

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

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

Gives a clear precondition ('an open application') and the operational procedure (dry run by default; the real run needs confirm set to the application's id), which is exactly the context needed to invoke it. It does not say when not to use it or point to reject_application as the non-spam alternative, so it falls short of full routing guidance.

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

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

Annotations declare destructive/not-idempotent, but the description adds substantial context beyond them: the kept entry inherits handles, the merged entry leaves the site and redirects permanently, edits are audited, permission to edit both entries is required, and dry_run defaults to true with the real run gated on confirm. This is exactly what an agent needs before a destructive merge.

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

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

Dense but front-loaded: merge semantics first, then preconditions, permissions, undo, and finally the dry-run/confirm gate. Every sentence adds a distinct operational fact with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent tool the description covers preconditions, auth requirements, audit behavior, reversibility, and the two-phase dry-run/confirm flow. With an output schema present, there is no need to explain return values, so nothing material is missing.

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

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 genuine meaning: confirm must be 'the VHID of the entry being merged away' and dry_run is default-true, clarifying the otherwise circular schema wording ('as the dry run gives it in confirm'). It does not restate entry/into beyond the schema's own text.

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

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

States a precise verb+resource with directionality baked in: 'Merge a duplicate entry into the one to keep.' The agent immediately knows which entry survives and which is removed, and it is clearly distinct from unmerge_entry and report_entry named in the same text.

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

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

Explicitly routes between alternatives: list_duplicate_qids to find candidates, unmerge_entry to undo, report_entry to merely ask. It also gives a hard precondition ('Open proposals, claims and reports on the merged entry must be decided first'), so the agent knows when the call will be rejected.

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

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

Goes well beyond the annotations (which only say non-readonly, idempotent, non-destructive): it discloses that nothing changes until a person approves, that a reviewer with Manage entries is required to approve a qid link, that the operation is audited, and critically that it is 'dry run by default' and what the dry run returns. These are high-value behavioral facts not derivable from structured fields.

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

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

Front-loaded with the core propose-for-approval framing and the dry-run default; sentences are dense but purposeful. It is on the longer side for a one-paragraph description, though for a 26-parameter tool the length is largely earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 26-parameter, 81%-covered mutation tool with an output schema, the description covers the highest-risk behaviors: approval gating, dry-run default, audit, and the qid/adopt interaction. It omits some parameters (gallery, idempotency, revision conflict) but those are documented in the schema, so the description is nearly complete for what an agent must understand before calling.

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

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

The description adds real meaning beyond the 81%-covered schema: null clears a field, qid links/re-points/unlinks with adopt controlling managed fields and the server default on first link, and note is framed as the reviewer's rationale. Minor gaps: it doesn't mention idempotency_key, base_revision_id, gallery, or handle ordering, but the schema documents those and coverage is high.

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

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

The description states a specific verb+resource (propose a change for a reviewer to decide) and immediately distinguishes itself from live editing: 'for any entry you may propose to, including ones you could edit live.' Combined with the title and the 'nothing changes until a person approves it' framing, an agent can tell this apart from update_entry_fields/update_entries without opening the schema.

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

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

It establishes when to use it ('including ones you could edit live', propose vs. direct edit) and the key precondition that a reviewer must approve. It does not explicitly name the live-edit siblings or explain when to choose propose_entry_changes (bulk) versus this tool, so it stops short of full when/when-not routing.

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

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

Goes well beyond the annotations: discloses that nothing changes until a person approves each proposal, that changes are audited under one batch id, that re-proposing an identical pending change answers the same proposal, the atomic all-or-nothing behavior, and that it is dry-run by default. These are the exact behavioral traits an agent needs and are not captured by the hint flags.

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

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

Front-loads the core purpose ('Proposals for up to 25 entries in one request') and each following clause carries distinct information (approval gate, batch id, idempotency, atomic, dry run). The opening sentence is long and dense, but there is little redundancy overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch, multi-parameter mutation tool with an existing output schema, the description covers the key facts an agent needs: the approval gate, per-entry vs atomic semantics, dry-run default, and idempotency. Return-value detail is correctly left to the output schema.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema itself documents entry, short, handles, base_revision_id, atomic, dry_run, and idempotency_key in detail. The description restates the atomic and dry-run semantics but adds no syntax or format beyond what the schema already provides.

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

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

States a specific verb and resource with scope ('Proposals for up to 25 entries in one request') and explicitly distinguishes itself from the singular sibling by noting 'each as propose_entry_change files one.' An agent can immediately tell this is the bulk variant of propose_entry_change.

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

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

Clearly frames the batch use case (up to 25 entries in one request) and names the singular alternative by reference, giving strong context for when to pick this tool. However, it never states an explicit 'use this instead when X' or an exclusion, leaving the routing to inference.

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

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

Adds substantial behavior beyond the annotations: the proposal carries only the diff, ownership (Wikidata vs site) is untouched, withdrawn images are omitted and named in the answer, an audit trail exists, and refusal semantics are spelled out. No contradiction with readOnlyHint=false / destructiveHint=false / idempotentHint=false.

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

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

The core action and default dry-run are front-loaded, and nearly every clause carries information (ref_id format, refusal, audit, payload scope). It is dense to the point of being a wall of clauses, which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-step proposal tool with an output schema present, the description covers what the proposal contains, its refusal case, the note's purpose, and the dry-run default, so nothing critical is left for the agent to infer.

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

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 a real constraint on the revision parameter (imported legacy revisions cannot be put back) and explains what the note is for and what dry_run does. That is meaningful semantics beyond the schema text.

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

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

States a precise verb+resource+scope: propose reverting an entry to an earlier revision for a reviewer to decide. It also differentiates from siblings by naming get_entry_history for obtaining the ref_id and characterizing the payload as what propose_entry_change would send, separating it from the direct restore_entry_revision path.

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

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

Gives clear triggering context (needs a reviewer, needs a ref_id from get_entry_history, refused with nothing_to_change when the entry already matches), and the dry-run-by-default note guides invocation. It stops short of an explicit when-not rule contrasting with the sibling restore_entry_revision, so it's strong but not fully exhaustive.

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

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

Adds substantial behavior beyond the annotations: dry run by default, audited, warns when the item belongs to another entry, skips handles the entry already has, sources the description from Wikipedia, and contrasts sync-backed vs copied values. This is well above the bar set by readOnlyHint=false / destructiveHint=false.

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

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

Front-loaded with the purpose, then facets in descending importance. Dense and clause-heavy, with a little repetition around sync upkeep, but nearly every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, dry-run-by-default write path with an output schema, the description covers the decision model (reviewer decides), defaults, side effects, warnings, and audit behavior. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces qid's default and the note's reviewer-facing purpose and adds behavior for the 'take' handles option, but most of this duplicates the schema text.

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

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

States a specific verb and resource: 'Propose ... what a Wikidata item says for an entry,' and enumerates the fields it can carry (handles, title, subtitle, description, image). An agent can distinguish it from generic propose_* siblings, though it never names them explicitly.

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

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

Gives clear conditional usage: qid defaults to the linked item and proposes handing values to the sync; for another item it copies them; default dry_run is true. It does not name alternative tools (propose_wikidata_changes, propose_wikidata_correction, create_entry_from_qid) so the agent must infer when to route elsewhere.

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

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

Goes well beyond the annotations: pause-state refusal (not_accepting), duplicate-on-item refusal, 409 qid_merged with the surviving QID in wikidata_item, 15-minute duplicate-suppression returning the first result, auditing, and dry-run-by-default behavior. It also discloses the non-obvious side effect that related entries auto-cross-link on approval, which no annotation conveys.

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

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

Front-loaded with the core action, then refusal conditions, then dry-run semantics — a sensible ordering for a dense single paragraph. It is on the long side and sentences such as the related-entries linking clause require re-reading, but nearly every clause carries operational information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter mutation with conditional refusals, this covers preconditions, failure modes, idempotency/dedup windows, dry-run preview contents, and post-approval side effects. Return-value description is unnecessary because an output schema exists.

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

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

Schema coverage is 70%, so the schema carries most of the weight, but the description adds genuine meaning: what `note` is for (reviewer-facing rationale), the semantic effect of omitting `qid`, how `let_wikidata_manage` interacts with qid, and the instruction to write titles as plain text because of auto-linking. Parameters like `subtitle`, `description`, and `handles` get no description-level elaboration, which keeps it from a 5.

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

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

The first clause names the exact action and its destination: a proposal queued for a reviewer, visible in Console → Applications under Quick proposals, going live on approval. That is a specific verb+resource plus lifecycle, and it is clearly distinct from siblings like create_entry_from_qid or propose_from_wikidata, which are not described as reviewer-queued proposals.

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

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

It gives explicit selection criteria for the qid parameter (omit for entities with no Wikidata item; include to link) and explains the account-permission condition ('unless this account may create entries itself'). What it lacks is a direct naming of the sibling alternative an agent should pick instead when it does have a Wikidata item and wants an import path, so it stops short of full routing guidance.

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

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.

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.

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.

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.

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.

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.

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

Adds substantial behavior beyond annotations: dry-run by default, nothing written to Wikidata, filing and audit behavior, approval requirements, the trusted-editor 200/day limit, and many 409/422 refusal and warning paths. This is consistent with readOnlyHint=false and destructiveHint=false: the tool writes a proposal row, not a Wikidata edit.

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

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

The opening is front-loaded, but the body is an extremely long, semicolon-heavy wall of text without headings or action-based structure. The detail is mostly relevant, yet readability and scanability suffer badly, so it is not appropriately concise for an agent selecting the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 18 actions, 28 parameters, nested objects, and an output schema, the description covers workflow, edge cases, refusals, warnings, and return-side signals. Nothing material appears missing for correct invocation.

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

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

Schema coverage is already high at 93%, but the description meaningfully expands semantics for value shapes, references, qualifiers, value_seen, outranked, and action-specific requirements. It adds much more than the schema alone, so it earns full credit.

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

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

Opens with a specific verb and resource: 'Propose a correction to a Wikidata statement', names the review workflow, and describes the proposal-only scope. It does not explicitly contrast with the closely named sibling propose_wikidata_changes, so selecting between the two still requires inference.

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

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

Provides extensive when-to-use guidance, including dry-run default, filing behavior, alternatives such as dismiss_wikidata_correction, update_entry_handles, search_commons_images, and propose_wikidata_changes for grouped account/count changes. The guidance is embedded in dense prose rather than a clear top-level selection rule, so the sibling distinction remains easy to miss.

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

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

Goes well past the annotations by disclosing side effects and constraints the agent cannot infer from structured fields: the applicant is emailed both reason and note, the note lands on the application thread, the action is audited, and it is irreversible though the applicant may reapply. This is consistent with destructiveHint=true and idempotentHint=false and adds real operational context.

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

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

Three tight sentences, front-loaded with the action and its side effects, then the irreversibility warning, then the dry-run safety workflow. Every clause carries information an agent needs; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, confirmation-gated mutation the description covers side effects, reversibility, audit, and the dry-run/confirm protocol, and an output schema exists so return values need no explanation. The only shortfall is the lack of explicit contrast with the other application-disposition siblings.

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

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 beyond the schema: it clarifies that confirm must equal the application's id (the schema only says 'this change's exact target'), and ties reason/note to the emailed-to-applicant behavior. The dry_run default is restated rather than clarified, so it is not a full 5.

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

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

States a specific verb and resource ('Decline an open application') with the required inputs and its scope ('open application'), clearly separating it from approve_application and mark_application_spam in the sibling list. An agent knows exactly what this does without opening the schema.

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

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

The 'open application' qualifier implies the precondition, and the dry-run-default workflow tells the agent how to actually execute. It does not, however, explicitly distinguish this from adjacent siblings like mark_application_spam or comment_on_application, so the routing guidance is clear but not exhaustive.

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

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description adds genuine new context: reports land in 'Console → Reports', are 'Audited', and the operation is 'Dry run by default'. It doesn't restate the schema's dry_run details, adding destination and auditability instead.

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

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

Front-loaded with the core action, then organized by reason. It is dense with colon/dash clauses and runs fairly long, but nearly every clause is load-bearing (media_id rules, note requirement, dry-run default), so it stays efficient rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return-value explanation is unneeded, and the description covers the remaining essentials: the reason taxonomy's least obvious cases, the note/media_id coupling, and the audited dry-run-default behavior. An agent can call this correctly without opening anything else.

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

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 cross-parameter semantics the schema lacks: which reason forces media_id, that `image` needs a note stating ownership and the change, and that `image_link` defaults to the first image with a link and preserves the link as-is.

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