Skip to main content
Glama

Delete Wiki comment

wiki_comments_delete
Destructive

Delete a comment from a wiki page permanently and return the page's remaining comment count. Verify the target first, since deleting a parent comment orphans its threaded replies.

Instructions

Delete a comment from a wiki page — irreversible (no recovery token).

Returns the page's remaining comments_count. Verify the target with comments_list / comments_thread_list first: deleting a parent orphans its replies' threading.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_idYesNumeric id of the page the comment lives on.
comment_idYesNumeric id of the comment to delete.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.67.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses irreversibility ("no recovery token"), states the return value (remaining comments_count), and warns that deleting a parent orphans its replies' threading. The destructive/irreversible profile is confirmed and enriched rather than merely repeated.

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

Conciseness5/5

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

Three compact sentences, front-loaded with the destructive warning, then return value, then the verification prerequisite. Every sentence earns its place and none is redundant.

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

Completeness5/5

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

There is no output schema, and the description compensates by stating the return value explicitly. For a two-parameter destructive tool, the irreversible warning, prerequisite check, and threading side effect make it complete for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters are fully documented in the schema (page_id, comment_id as numeric ids). The description adds nothing about parameter format or constraints, so baseline 3 applies — the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource ("Delete a comment from a wiki page") with the exact scope of the operation, and it is trivially distinguishable from siblings like wiki_comments_create, wiki_comments_list, and wiki_comments_thread_list. No ambiguity about what is being deleted.

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

Usage Guidelines4/5

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

Explicitly instructs the agent to verify the target with comments_list / comments_thread_list before deleting, which is real routing guidance to sibling read tools. It stops short of stating when NOT to use it or naming an alternative deletion path, so it is clear context rather than full when/when-not guidance. (Minor: it abbreviates sibling names without the wiki_ prefix.)

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

Deploy Server

Other Tools