Resolves a GitHub Actions run (by runId, or the most recent failed run on a branch) and lists its jobs and artifacts. Only works for repos listed in allowedRepos in ~/.ci-triage-mcp/config.json -- add a repo there yourself first (see guardrails.ts).

Turns a noisy raw CI log (or a downloaded JUnit/Surefire XML artifact) into structured FailureSignal entries -- test name, class, message, stack trace, and a stable signature -- using real parsers (JUnit/Surefire XML, ESLint stylish, tsc, Prettier, Maven console), not an LLM guessing from raw text. Prefer passing artifactName when fetch_pipeline_run listed one matching /junit|surefire/i for this run; otherwise this reads the job's own console log.

Read-only lookup against a local history store (~/.ci-triage-mcp/history.json) of failure signatures this tool has previously extracted or recorded for this repo. Use this to say "this has happened N times before" instead of treating every failure as novel. Doesn't modify history -- see record_triage_note to persist your own explanation for future lookups.

Appends your explanation for a failure signature to the local history store, and bumps its occurrence count. Local file write only -- safe to call without asking the user first, unlike publish_triage which sends data to a shared dashboard. Do this after explaining a failure so future find_similar_past_failures calls have something useful to surface.

Convenience tool that chains fetch_pipeline_run -> (download every JUnit/Surefire-looking artifact for the run, and every failed job's log) -> extract_failure_signal's parsers -> find_similar_past_failures. Returns everything needed to write the explanation in one call. Use the granular tools instead when you want to target one specific job. The response includes a dashboardConfigured flag -- if true, ask the user whether they'd like this triage published before calling publish_triage; don't publish automatically.

Sends a triage's explanation and signals to a deployed ci-triage-dashboard instance, returning a shareable URL. Requires "dashboardUrl" in ~/.ci-triage-mcp/config.json and the CI_TRIAGE_DASHBOARD_TOKEN env var -- neither is set by default. ci-triage-dashboard (see dashboard/) exists and works but isn't deployed anywhere public yet (see README roadmap), so this will currently fail with a clear "not configured" error until dashboardUrl is set. Ask the user before calling this once it is configured -- publishing may make the triage readable by others.