Loading ToolBench

Reading the current corpus…

incident-ops MCP server · D · ToolBench

incident-ops

MCP server providing tools for AI-powered incident analysis, including finding similar incidents, analyzing error details, retrieving pattern history, getting service context, assigning incidents, and accessing resolution history.

2026-07-28+STDIO6 tools

57/100

Definition Quality73

Protocol Readiness50

Supportability36

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Server has 6 tools with complete JSON schemas and descriptions. Naming follows verb_noun convention (find_, get_, analyze_, assign_). Descriptions are present (avg 95 chars) but lack depth on WHEN to use each tool and dependencies between them. Parameters are typed and mostly described, but lack constraints (enums, ranges, format hints). Output schemas are not documented, LLMs cannot plan downstream calls. Error handling is minimal; no recovery guidance. Missing tool annotations (readOnlyHint/destructiveHint). One tool (assign_incident) is destructive but lacks confirmation pattern.

Tools (6)

analyze_error_detailsread onlysource verified72/100

Extract structured details from an error message and stack trace.

assign_incidentwritesource verified77/100

Assign an incident to a team for resolution.

find_similar_incidentsread onlysource verified73/100

Find historical incidents similar to the current one based on error fingerprint.

get_pattern_historyread onlysource verified72/100

Get the occurrence history of a pattern over time.

get_resolution_historyread onlysource verified72/100

Get how similar incidents were resolved in the past.

get_service_contextread onlysource verified72/100

Get recent incidents and context for a service.

Issues (5)

CRITICALtool ↗

Output schemas not documented. LLMs cannot infer what fields are returned, blocking downstream tool chaining and multi-step planning.

find_similar_incidentsget_pattern_historyget_service_contextanalyze_error_detailsget_resolution_history

HIGHconfirmation-request ↗

assign_incident is destructive (WRITE risk) but lacks confirmation pattern or dry-run mode. Agents can assign incidents without user approval.

assign_incident

HIGHtool-description ↗

Tool descriptions lack WHEN-to-use guidance and dependency hints. E.g., find_similar_incidents does not explain when to call it vs get_resolution_history.

find_similar_incidentsget_pattern_historyget_service_contextget_resolution_history

MEDIUMconstrained-input ↗

Numeric parameters (limit, days, hours) lack min/max constraints. LLMs could pass absurd values (limit=999999, days=36500) causing timeouts or API errors.

Recommendations

Document output schemas for all tools. Example for find_similar_incidents: 'Returns array of {incidentId, fingerprint, createdAt, resolvedAt, resolution}' so LLMs know what fields to extract.
Add min/max constraints to numeric params: limit (1-100), days (1-365), hours (1-720). Include in descriptions: 'Maximum number of incidents to return (1-100, default: 5)'.
Expand tool descriptions with WHEN-to-use guidance. E.g., find_similar_incidents: 'Use this to find past incidents with the same error signature. Call this BEFORE get_resolution_history to see how similar issues were fixed.'
Add tool annotations via MCP SDK: mark read-only tools with readOnlyHint=true, mark assign_incident with destructiveHint=true to signal clients it requires confirmation.
Implement confirmation pattern for assign_incident: return {status: 'pending_confirmation', incidentId, team, reason} and require a confirm_assignment tool call before executing the write.

Score history

Overall score trend

First recorded score · v2 rubric

57/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	57	2026-07-28+	v2