Skip to main content
Glama

update-wiki-page-comment

Destructive

Updates an existing comment on a wiki page by changing its markdown content; specify the wiki, page, and comment IDs to revise the correct comment.

Instructions

Update a comment on a wiki page.

Input Schema

NameRequiredDescriptionDefault
pageIdYesWiki page ID (required)
wikiIdYesWiki ID (required)
contentYesNew comment content in markdown (required)
commentIdYesComment ID (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

C2.3/5.0
Behavior2/5

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

Annotations declare destructiveHint=true and openWorldHint=true, so an agent already knows this mutates remote state. The description adds nothing about that: it does not say that 'content' replaces the existing comment wholesale, whether prior content is recoverable, or what permissions are needed. Given the destructive warning, the omission of overwrite semantics is a meaningful gap, though nothing in the text contradicts 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.

Conciseness3/5

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

A single short sentence with no filler, so nothing is wasted. However, its brevity comes from under-specification rather than editorial discipline; there is no front-loaded scoping or constraint to justify the length.

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

Completeness2/5

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

This is a destructive, open-world mutation with four required identifiers and no output schema, so the description carries most of the explanatory burden. It supplies none of the needed context: no clarification of overwrite behavior, no mention of failure modes for wrong wikiId/pageId/commentId, no indication of what is returned.

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 the schema already documents all four required parameters, including that content is markdown. The description contributes no additional parameter meaning, so the baseline of 3 for high-coverage schemas applies. It could have clarified replace-vs-append for 'content' but does not.

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

Purpose2/5

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

The description decodes the tool name into a sentence: 'Update a comment on a wiki page.' It states a verb and resource, but adds no differentiating detail against siblings like create-wiki-page-comment, delete-wiki-page-comment, or update-wiki-page-body. This is effectively a restatement of the name, which is the textbook tautology case.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus create-wiki-page-comment, delete-wiki-page-comment, or get-wiki-page-comment. The agent must infer from the name alone that this edits an existing comment rather than adding one. No prerequisites, no exclusions, no alternatives named.

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