get_job_logs: run_id with failed_only=false should return all job logs; failed_only should be a consistent modifier

[danmoseley]

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:

{"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.