github / github/github-mcp-server
get_job_logs: run_id with failed_only=false should return all job logs; failed_only should be a consistent modifier
- Linguagem predominante
- Go
- Estrelas
- 33k
- Forks
- 5k
- Merge médio
- 2d 1h
- PRs com merge (30d)
- 52
Descrição
This came out of an analysis of github MCP server errors encountered in my past sessions across 5000 sessions.
### What happened
An agent trying to retrieve all job logs for a workflow run passed:
```json
{"owner":"danmoseley","repo":"pr-dashboard","run_id":22854416647,"return_content":true,"tail_lines":500,"failed_only":false}
```
And got:
```
job_id is required when failed_only is false
```
This happened 6 times across 5 sessions. The agent's intent was clear and reasonable: get all logs for this run, not just failed ones. It even explicitly set `failed_only=false` to signal that — and got an error.
### Why the current design is confusing for agents
`failed_only` is used as a mode switch rather than a modifier:
- `run_id` without `failed_only=true` always errors, even though "get logs for this run" is a valid request
- `failed_only` has no effect when `job_id` is provided — it is silently ignored
### Proposed behavior
`failed_only` should be a consistent modifier on whichever ID is provided:
| Parameters | Result | Proposed |
|---|---|---|
| `job_id` + `failed_only=false` (or not passed) | logs for that job | **already allowed** |
| `job_id` + `failed_only=true` | logs for that job if it failed; `isError:true` with status if it succeeded | **error -> allowed** |
| `run_id` + `failed_only=false` (or not passed) | logs for all jobs in the run | **already allowed** |
| `run_id` + `failed_only=true` | logs for failed jobs only | **error -> allowed** |
| both `job_id` and `run_id` | `isError:true` — provide one or the other, not both | **error** |
| neither | `isError:true` — one of `job_id` or `run_id` must be provided | **error** |
The `job_id + failed_only=true` case requires checking the job's conclusion before fetching logs, but the tool already fetches job metadata to get the log URL so this is a small addition.
### Breaking change note
No changes to existing successful calls. This only makes certain calls that are failing begin to work.
Guia de contribuição
Avaliação
Esta issue ainda não foi avaliada.