Skip to main content
Glama
lastping-dev

LastPing

by lastping-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Add incident note

add_incident_note

Record a diagnosis note on a LastPing incident to document what failed and what was done. Notes are append-only and appear on the incident page in order.

Instructions

Requires the write scope or higher. Adds a diagnosis note to an incident; it appears on the incident's page in order, stored with author 'agent' (no author argument exists). Notes are append-only: no edit or delete exists, so a correction is a new note and the history stays evidence. Several notes per incident are normal, up to a cap of 50, and a closed incident still accepts them. A note can record a failure that was not fixed as well as one that was. Without a note, the incident page shows only the alert.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesThe diagnosis in plain words: what failed, whether it matches earlier failures (failure_signature.occurrences from list_open_incidents) and what was done, e.g. 'failed because the upstream API returned 503; same as the last three nights; retried twice'. Non-empty, not whitespace-only, at most 8192 bytes; an oversized body is rejected, never truncated. The full failure output already lives on the run.
incident_idYesThe incident's numeric id, an entry's incident_id in list_open_incidents. An integer, not a UUID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.17
    • changedInput schema / properties / body / description
      Previous value: -"The diagnosis, in plain words and one or two sentences: what actually failed, whether it is the same failure as before (compare failure_signature.occurrences from list_open_incidents), and what you did about it. Must not be empty or whitespace-only, and must be at most 8192 bytes. An oversized body is REJECTED, never truncated — a truncated diagnosis reads as a complete one that trails off, and the reader cannot tell that the sentence naming the cause was the one cut — so shorten it and call again. A pasted stack trace is a note nobody reads: the full failure output already lives on the run that produced it."New value: +"The diagnosis in plain words: what failed, whether it matches earlier failures (failure_signature.occurrences from list_open_incidents) and what was done, e.g. 'failed because the upstream API returned 503; same as the last three nights; retried twice'. Non-empty, not whitespace-only, at most 8192 bytes; an oversized body is rejected, never truncated. The full failure output already lives on the run."
    • changedInput schema / properties / incident_id / description
      Previous value: -"The incident's numeric id, taken straight from an entry's incident_id in list_open_incidents. An integer, not a UUID."New value: +"The incident's numeric id, an entry's incident_id in list_open_incidents. An integer, not a UUID."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), it discloses the auth requirement (write scope or higher), the append-only nature with no edit/delete path, the 50-note cap, acceptance on closed incidents, and the author value. This is exactly the mutation-behavior context annotations cannot convey.

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?

Six sentences, each carrying distinct information, with the action and permission prerequisite front-loaded before the behavioral details. No restatement of the name or title and no filler.

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?

For a two-parameter mutation tool with no output schema, the description covers permissions, mutation semantics, capacity limits, edge cases (closed incidents), and the value proposition of the note. Nothing an agent needs in order to invoke it correctly is missing.

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 100%, so the baseline is 3, but the description adds one genuinely useful clarification the schema cannot: there is no author argument, so the agent should not attempt to supply one. The remaining parameter meaning (incident_id integer, body content/limits) is already fully documented in the schema.

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?

The first operative sentence states a specific verb and resource ('Adds a diagnosis note to an incident') and immediately pins down the unique semantics of the operation (append-only, stored with author 'agent'). No sibling tool overlaps with adding notes, so an agent can place this without ambiguity.

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?

It gives strong contextual guidance on when this applies: several notes per incident are normal, a closed incident still accepts notes, and a note may record an unfixed failure. It never names an explicit alternative or exclusion, but the write-scope prerequisite and the 'without a note the page shows only the alert' framing make the trigger condition clear.

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