Skip to main content
Glama
Sign In

Incident Library

by com.benchlet
OverviewDiscussionsAdmin

Get one incident

get_incident
Read-onlyIdempotent

Returns one case in full by its id: the structured write-up (symptoms, trigger, root cause, components, contributing factors, summary, impact, timeline, detection, remediation, action items, lessons), its sources with archived copies, and similar_cases. Use after search_incidents, list_incidents or get_topic has given you a case id; not for finding cases (use search_incidents for symptoms, list_incidents or get_topic for a category). lang: ko returns the Korean text of each field where the reviewers wrote one, otherwise English. The id must look like IL-0007; an id of that shape that matches no approved case returns an error result saying so, and an id of another shape is rejected before the call. Every call for the same id returns the same case.

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": {
      "id": "<id>"
    },
    "name": "get_incident"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesCase id such as IL-0007
langNoko returns the Korean text of each field where the reviewers wrote oneen

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description still adds real behavior: an id-shaped-but-unknown case returns an error result, a malformed id is rejected before the call, and lang falls back to English where no Korean text exists. The closing sentence on stable results restates idempotentHint rather than adding new information, which keeps this just short of 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.

Conciseness5/5

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

The operation and return payload are front-loaded, then routing guidance, then parameter/error semantics. The long parenthetical field list is dense but each item is informative, and no sentence is 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 read tool with no output schema, the description covers the return contents, error cases, language fallback and sibling routing. Nothing an agent needs in order to call 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 goes beyond the schema by explaining the runtime consequence of the id pattern (an id of another shape is rejected pre-call, an unknown but valid id yields an error result). The lang behavior is largely a restatement of the enum description, which caps it below 5.

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?

Opens with a specific verb and resource ('Returns one case in full by its id') and enumerates what the payload contains, so an agent knows both the operation and its shape. It is clearly differentiated from search_incidents, list_incidents and get_topic by the explicit 'not for finding cases' clause.

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

Usage Guidelines5/5

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

States the prerequisite workflow ('Use after search_incidents, list_incidents or get_topic has given you a case id') and names the alternative for each excluded case (search_incidents for symptoms, list_incidents/get_topic for a category). Both the when and the when-not are spelled out with the sibling that covers it.

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

All Incident Library toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources