Pagerlane MCP Connector

keep_update_incident

Idempotent

Change one Keep incident's status, severity, or fields with a dry-run preview by omitting confirm; set confirm to true to apply the update.

Instructions

Update an incident with one change. status posts to /incidents/{id}/status with status, comment, and tagged_users. severity posts to /incidents/{id}/severity with severity and comment. fields reads the incident, then PUTs user_generated_name, assignee, user_summary, and same_incident_in_the_past_id merged over the current values. Keep's PUT clears user_summary and same_incident_in_the_past_id when they are omitted. Severity is not sent on PUT. Omit confirm for a dry-run preview.

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>",
      "change": "<change>"
    },
    "name": "keep_update_incident"
  }
}

Input Schema

Name	Required	Description
`change`	Yes	One change. status posts to /status. severity posts to /severity. fields are merged onto the current incident and then PUT.
`confirm`	No	Set to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
`incident_id`	Yes	Keep incident UUID.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Discloses behavior the annotations cannot: that the fields branch reads the incident and merges values over it, that Keep's PUT clears user_summary and same_incident_in_the_past_id when omitted, that severity is not sent on PUT, and that omitting confirm yields a dry run. The clear-on-omit behavior sits in mild tension with destructiveHint=false, but the description is disclosing real side effects rather than contradicting the annotation.

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?

Tight and front-loaded: purpose first, then per-mode routing, then the side-effect caveats, then the dry-run rule. It is dense and unbroken prose, and "Severity is not sent on PUT" arrives without much setup, but nothing is padding.

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 mutating tool with full annotation coverage and no output schema, it covers the write paths, the silent-clearing hazard, and the dry-run mechanism. It omits error cases, permission requirements, and what the dry-run preview returns, leaving small gaps.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds genuine meaning: it maps each change.kind to the fields and endpoint it uses, and — critically — explains that omitting user_summary or same_incident_in_the_past_id clears them, which changes how an agent must populate those optional params.

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 an incident with one change") and then enumerates the three mutually exclusive change kinds with the endpoint each targets. An agent can distinguish this from keep_get_incident/keep_list_incidents purely from the description 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.

Usage Guidelines4/5

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

Clear guidance on how to use each mode and an explicit dry-run rule ("Omit confirm for a dry-run preview"). It stops short of naming alternatives or exclusions, e.g. it never says when to prefer this over keep_resolve_alert or keep_acknowledge_alert for the alert-level equivalents.

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

Deploy Server