Incident Library

Search incidents by symptoms

search_incidents

Read-onlyIdempotent

Use first, whenever someone describes a failure they are seeing. Pass the symptoms as a sentence or a few words, in English or Korean; returns every reviewed public post-incident report the search finds for it, best match first: total is how many, results is one page of them in full (each with the case id, the page url and the source link), matched is every one as a row, and next_cursor fetches the next page. interpreted lists the values the sentence named, organisations included (the search moves cases carrying them up); facets count the results by root cause, component, symptom, contributing factor and organisation with the case ids, which answers 'what usually caused this' from the same call. The optional slug filters keep only cases carrying those values (AND); take slugs from facets, interpreted or vocab. Follow with get_incident for the full case.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_incidents"
  }
}

Input Schema

Name	Required	Description	Default
`org`	No	Keep only cases of this organisation, by slug, e.g. github (from facets.orgs, interpreted or vocab)
`lang`	No	ko returns the Korean text of each field where the reviewers wrote one	en
`limit`	No	Cases per page
`cursor`	No	next_cursor from the previous page
`domain`	No	Keep only cases in this domain, e.g. kubernetes or ai-infra
`factor`	No	Keep only cases with this contributing factor slug, e.g. no-alerting
`symptom`	No	Keep only cases with this symptom slug, e.g. pod-pending
`symptoms`	No	What is observed, as a sentence or a few words, e.g. 'pods cannot get an IP, nodes show no available addresses' or 'coredns oom'. Leave it out to list every case under the slug filters, newest first; then at least one filter is required
`component`	No	Keep only cases with this component slug, e.g. coredns
`root_cause`	No	Keep only cases with this root cause slug, e.g. capacity

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses ranking behavior ('best match first', cases carrying interpreted organisations are moved up), the AND semantics of filters, and the pagination model via next_cursor. It also discloses the corpus limitation (only reviewed public reports) so the agent knows what will not be found.

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?

The routing instruction is front-loaded and every clause carries information, but the middle of the paragraph is a long chained enumeration of response fields that is dense to parse in one pass. Slightly tighter grouping of the return-value explanation would improve it without losing content.

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 10-parameter tool with no output schema, the description fully compensates by naming each response field (total, results, matched, next_cursor, interpreted, facets) and what it contains. It also explains the derived analytical use of facets, which is not evident from the schema.

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; the description adds real value by explaining that slug filters are conjunctive and that valid slug values come from facets, interpreted or vocab. It does not restate per-parameter formats, which the schema already carries well.

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 ('search incidents') plus the input mode ('pass the symptoms as a sentence or a few words') and the corpus searched ('reviewed public post-incident report'). It also distinguishes itself from get_incident ('Follow with get_incident for the full case') and from list-style siblings by requiring symptoms.

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?

Opens with an explicit routing rule: 'Use first, whenever someone describes a failure they are seeing.' It names the follow-up tool and the condition for it, and explains that slug filters narrow results with AND semantics, with slugs sourced from facets, interpreted or vocab.

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

All Incident Library tools Inspect

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.