Loading ToolBench
MCP server for incident timeline analysis and evidence gathering from git clones, logs, and external sources (Octopus deploys, DbExplorer diagnostics, GitLab pipelines, GitHub Actions runs)
Aftermath provides well-structured incident investigation tools with strong descriptions and clear parameter documentation. All four tools have detailed, LLM-optimized descriptions (150-250 chars) that explain WHAT the tool does, WHEN to use it, and critical caveats (e.g., 'Confidence' levels, 'Provenance' citation requirements). Input schemas are complete with typed parameters and descriptions. However, output schemas are not explicitly documented in the visible code, the ToolResult wrapper obscures the actual data structure returned. Error handling is present but minimal (WORKSPACE_NOT_CONFIGURED, INVALID_ARGUMENT, WORKSPACE_NOT_FOUND) without recovery guidance. Tool naming follows verb_noun convention (incident_*) but the four tools are tightly coupled to a single domain (incident analysis) with limited composability.
Gathers raw evidence around an incident from every offline source and returns one SourceResult per source: the git source (release tags, commits on HEAD, CHANGELOG.md entries) and the log source (log4net files, Error.txt crash dumps, HTTP status/latency recovered from log text) when a log root is supplied. A source never throws — Skipped or Failed statuses are returned as data, with the reason and what to do about it in Message. Capped at 500 events total; a truncated response says so explicitly in the affected source's Message rather than silently returning fewer.
Builds the service join table from a workspace of git clones: the Octopus project slug, deployable package name, OpenTelemetry service name, log-file prefix and every distinct log4net conversion pattern found for each repo. Call this first — it tells you which services exist and whether each one's production log path is even discoverable from the clone (logPrefixIsToken=true means it is not: production logs must be copied locally and pointed at with a log root before any log evidence is available for that service).
Ranks change events (releases, deploys, commits) by proximity to the incident. This is coincidence and proximity only — never a cause. Score = proximity x kindWeight x blastRadius; every Suspect carries the underlying event (with its own Provenance to cite) and Label, which is always the fixed string 'changed nearby'. Do not phrase a high-scoring suspect as having caused the incident: no service in this estate exposes its running version, so a release appearing here is not proof it was live.
Returns evidence, not analysis. Each event carries a Confidence: Observed (read from a durable artefact), Inferred (derived by the tool — read its Caveat before relying on it), Reported (asserted by a remote system). Do not state that any change caused the incident; the tool ranks proximity only, and no service in this estate exposes its running version, so a release appearing here is not proof it was live. Cite the Provenance string for every claim you make. If a source's status is Skipped or Failed, say so in your summary rather than reasoning as though its evidence were absent.
Output schemas not documented. ToolResult wrapper hides actual data structure (ServiceManifest[], SourceResult[], timeline events, Suspect rankings). LLMs cannot plan downstream operations or extract fields without reverse-engineering the response.
Error handling lacks recovery guidance. Errors like 'WORKSPACE_NOT_CONFIGURED' and 'INVALID_ARGUMENT' are categorized but do not tell the LLM what to do next (e.g., 'Set INCIDENTTIMELINE_WORKSPACE env var' or 'Provide ISO-8601 timestamp with timezone').
No pagination or result limits documented in schema. incident_collect caps at 500 events and signals truncation in Message, but this constraint is not exposed as a parameter or schema field, LLMs cannot reason about it upfront.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Parameter 'timezone' defaults to 'Europe/Dublin' without explicit documentation. LLMs may not realize this default applies if INCIDENTTIMELINE_TIMEZONE is unset, risking silent timezone mismatches.
Tool coupling: all four tools require 'at' (incident timestamp) and optional workspace/logRoot/timezone. No discovery tool to list available incidents or validate workspace structure upfront. Agents must guess valid timestamps.