Skip to main content
Glama
Sign In

Incident Library

by com.benchlet
OverviewDiscussionsAdmin

List incidents by vocabulary value

list_incidents
Read-onlyIdempotent

Lists cases by category, newest first, one page at a time: count and cases (id, title, organisation, date, root cause, page url), plus next_cursor when more remain; call again with cursor for the following page. Use when the question names a category (a root cause, component, symptom, contributing factor, domain or organisation) rather than a symptom sentence; for a sentence use search_incidents, and for one category with its related categories counted use get_topic. Each filter is a slug (kebab-case) of its own kind: symptom is what was observed (pod-pending), factor is a condition that made it worse (no-alerting), root_cause is why it happened (capacity). Filters combine with AND. An unknown slug returns count 0 with no error; find the slug with vocab when you only have words. Reads only; the same filters return the same page.

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": "list_incidents"
  }
}

Input Schema

NameRequiredDescriptionDefault
orgNothe organisation's slug, e.g. github
langNoko returns the Korean text of each field where the reviewers wrote oneen
limitNoCases per page
cursorNonext_cursor from the previous page
domainNokubernetes or ai-infra
factorNocontributing factor, e.g. no-alerting
symptomNoe.g. pod-pending
componentNoe.g. coredns, vpc-cni
root_causeNoe.g. capacity, config-change

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, closed-world behavior, and the description adds important operational traits beyond them: newest-first ordering, cursor pagination, stable pages for the same filters, AND-combined filters, and the non-error behavior for unknown slugs. These details materially reduce invocation risk.

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 description is dense and front-loads both the listing behavior and return shape, then moves through routing, filter semantics, and edge cases. It is somewhat long and clause-heavy, but nearly every sentence carries actionable information for a nine-parameter paginated tool.

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?

There is no output schema, yet the description explains the response fields (count, cases with id/title/organisation/date/root cause/page url, next_cursor) and how to paginate. Combined with complete parameter descriptions and explicit routing and slug semantics, an agent has what it needs to call this correctly.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds semantic distinctions the schema does not: each filter is a kebab-case slug of its own kind, with concrete examples clarifying symptom vs. factor vs. root_cause. It also explains that filters combine with AND and points to vocab for slug discovery, going well beyond field-level documentation.

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 description opens with a specific verb and resource ('Lists cases by category, newest first, one page at a time') and immediately distinguishes this taxonomy-driven listing from sentence search and topic aggregation by naming the relevant siblings. An agent can identify the intended operation 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 Guidelines5/5

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

It gives explicit routing criteria: use this when the question names a category, use search_incidents for a symptom sentence, and use get_topic for one category with related categories counted. It also tells the agent to use vocab when only words are available, covering the main selection ambiguity.

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