swsd-mcp

swsd_update_comment

Destructive

Update an existing SWSD incident comment's body by providing incident_id, comment_id, and new text. The comment's visibility cannot be changed.

Instructions

Update the body of an existing SWSD incident comment. Pass incident_id, comment_id, and the new body. The is_private flag cannot be changed by this tool — to change visibility, delete and re-create. WRITE — does not retry on transient failure.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "incident_id": "<incident_id>",
      "comment_id": "<comment_id>",
      "body": "<body>"
    },
    "name": "swsd_update_comment"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	New comment text (replaces existing). Plain text or HTML.
`comment_id`	Yes	SWSD comment ID to update.
`incident_id`	Yes	SWSD incident reference. Accepts either the internal id (>=7 digits, e.g. 180457930) or the human-facing number (<=6 digits, e.g. 60310). The handler auto-detects via digit count.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.0.0Oct 4, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv2.1.0May 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=true, idempotent=false and openWorld=true, so the bar is lower; the description still adds real value by disclosing that is_private is immutable here (delete + re-create required) and that the handler does not retry on transient failure — a non-obvious operational trait. It omits permission/auth requirements and any note about partial failure, keeping it below a 5.

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

Conciseness4/5

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

Three tight sentences, front-loaded with the core action, then the caveat, then the write warning. The middle sentence enumerating the three parameters is mildly redundant with the schema but the rest earns its place. Nothing bloated.

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

Completeness4/5

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

For a 3-parameter destructive mutation with no output schema, the description covers the essential gotchas an agent needs to call it correctly: which fields, what cannot be changed, and the retry caveat. Given annotations already carry the safety profile and the schema is fully documented, only minor gaps (permissions, subsequent-read guidance) remain.

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 itself is unusually rich, documenting the id-vs-number auto-detection for incident_id, the replace semantics and the 50000-char cap for body. The description only restates the required parameter names, adding no syntax or format meaning beyond the schema. Baseline 3 applies.

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 ('Update the body of an existing SWSD incident comment') and immediately names the three inputs, which cleanly separates it from the sibling swsd_add_incident_comment (create) and the read-only swsd_list_incident_comments. An agent can distinguish it without opening any schema.

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

Usage Guidelines4/5

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

Gives clear context for the operation and an explicit when-not/alternative: visibility cannot be toggled here, so delete and re-create instead. It also flags the write-mode retry behavior. It stops short of explicitly routing to siblings for creating comments or stating prerequisites such as permission scope, so it is not a full 5.

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

Deploy Server