MCP GitHub CrunchTools

Get Failed Job Logs Tool

get_failed_job_logs_tool

Read-only

Extracts failure summaries from failed GitHub Actions jobs, showing log-tail cause lines and failed step names to diagnose CI failures quickly.

Instructions

Get the failure summary of each failed job in a GitHub Actions run.

Returns, for every job that failed or timed out, a failure_summary: the log-tail lines that name the cause (error annotations, test failures, tracebacks, non-zero exits), with ANSI escapes and timestamps removed, plus the names of the steps that failed. Set include_raw_log to also get the full cleaned tail as log — it can be large and, for a repository whose CI output quotes attack corpora, a scanning gateway may flag and withhold it, where the small, signal-only summary is far more likely to pass.

Logs are fetched for at most 5 failed jobs and all log text together is capped at 256 KiB; truncated and failed_jobs_omitted say when something was cut. jobs_truncated means the run has more than the 300 jobs examined, so the failed-job counts cover only those.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>",
      "run_id": "<run_id>"
    },
    "name": "get_failed_job_logs_tool"
  }
}

Input Schema

Name	Required	Description
`repo`	Yes	Repository name
`owner`	No	Repository owner (defaults to GITHUB_DEFAULT_ORG if unset)
`run_id`	Yes	Workflow run ID
`tail_lines`	No	Lines of the tail to scan for the summary, and to return as ``log`` when ``include_raw_log`` is set (default 200, max 1000)
`include_raw_log`	No	Also return the full cleaned tail as ``log`` (default False); the raw tail may be withheld by a scanning gateway, the summary is not

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.0.0Oct 31, 2026

addedInput schema / properties / include_raw_log

Added value: +{
+  "default": false,
+  "description": "Also return the full cleaned tail as ``log`` (default\nFalse); the raw tail may be withheld by a scanning gateway, the\nsummary is not",
+  "type": "boolean"
+}

changedInput schema / properties / tail_lines / description

Previous value: -"Lines to return from the end of each log (default 200,\nmax 1000)"New value: +"Lines of the tail to scan for the summary, and to return as\n``log`` when ``include_raw_log`` is set (default 200, max 1000)"

Changed1 schema field changedv1.3.2Oct 17, 2026
- addedInput schema / properties / run_id / minimum
```
Added value: +1
```
Addedv1.2.0Oct 14, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare readOnlyHint, and the description adds substantial behavior beyond that: ANSI/timestamp stripping, the 5-job / 256 KiB caps, the meaning of `truncated`, `failed_jobs_omitted`, and `jobs_truncated`, and the caveat that a scanning gateway may withhold raw logs. This is exactly the context annotations don't carry.

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 first sentence front-loads the purpose, and the following paragraphs unpack return shape and limits. Slightly long, but nearly every sentence carries information the agent needs; the gateway aside is the only part that borders on tangential.

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 read-only diagnostic tool with an output schema, annotations, and full schema coverage, the description covers the truncation semantics, parameter trade-offs, and safety caveat. Nothing an agent needs to call it correctly is missing.

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, but the description adds real meaning to `include_raw_log` (gateway flagging of quoted attack corpora) and the tail cap. It goes beyond restating field definitions and explains the trade-off that parameter controls.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Get the failure summary of each failed job in a GitHub Actions run') and pins down the returned artifact, a `failure_summary` of log-tail lines naming the cause. An agent can distinguish it from `get_workflow_run_tool` by scope, though the siblings are never named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It gives clear conditional guidance on `include_raw_log` (use it only if you need the full tail, and note the gateway risk), but it never states when to pick this tool over `get_workflow_run_tool` or `rerun_failed_jobs_tool`. Usage is implied by the failed-run diagnosis context rather than made explicit.

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