🚀 Excellent work@gabornyergesX! This is exactly what the community has been asking for.

I've tested this implementation in my fork and it's incredibly comprehensive:

• 14 new tools covering the complete GitHub Actions lifecycle
• Excellent test coverage with 50+ test cases
• Perfect integration with existing MCP server patterns
• Proper security annotations (read-only, write, destructive)
• Great documentation updates

This addresses issue#268 perfectly and goes above and beyond the original request. The code quality is exceptional - well done! 👏

Looking forward to seeing this merged so the whole community can benefit from these powerful CI/CD automation capabilities.

This looks very comprehensive. Thank you for putting this together. I hope I can review soon.

One preliminary question:

Is there strong motivation for allowing an agent to delete logs? I am hesitant to allow agents the ability to cover their tracks after executing something malicious.

The security implications of this PR something I will need to consider. I really do want to land it though.

💡 Enhancement Suggestion: Efficient Failed Job Logs

Great work on this comprehensive GitHub Actions implementation! After testing it, I noticed an opportunity to make it even more efficient for a common debugging use case.

🎯 Problem

Currently, to get logs for failed jobs, users must either:

1. Useget_workflow_run_logs - Downloads ALL logs (high token usage)
2. Manually combinelist_workflow_jobs +get_job_logs - Multiple steps

This doesn't match the efficiency ofgh run view --log-failed.

💡 Proposed Enhancement

Instead of adding a new tool, enhance the existingget_job_logs tool with optional parameters:

// Enhanced parameters for get_job_logsmcp.WithNumber("run_id",mcp.Description("Workflow run ID (required when using failed_only)")),mcp.WithBoolean("failed_only",mcp.Description("When true, gets logs for all failed jobs in run_id")),mcp.WithBoolean("return_content",mcp.Description("Returns actual log content instead of URLs")),

🔧 Usage Examples

# Original usage (unchanged)get_job_logs --job_id=12345# New: Get failed job logs efficientlyget_job_logs --run_id=67890 --failed_only=true --return_content=true

✅ Benefits

• Token efficient - Only processes failed jobs
• Content delivery - Returns actual logs, not URLs (likegh CLI)
• Backward compatible - No breaking changes
• Single tool - No tool proliferation

This would make the Actions toolset perfect for real-world debugging workflows!

I've created a detailed proposal in my fork:https://github.com/atxtechbro/github-mcp-server/blob/enhance/get-job-logs-failed-only/ENHANCEMENT_PROPOSAL.md

What do you think about this approach? Happy to help implement it if you're interested! 🚀

This looks very comprehensive. Thank you for putting this together. I hope I can review soon.

One preliminary question:

Is there strong motivation for allowing an agent to delete logs? I am hesitant to allow agents the ability to cover their tracks after executing something malicious.

The security implications of this PR something I will need to consider. I really do want to land it though.

I did not have strong motivation for that just added as an extra.
My original issue was not able to debug pipeline logs with the agent and wanted to automise.
I can remove from the PR if you decide security implications is too high.

I thinkdelete_workflow_run_logs tool has appropriate security measures:

1. ✅Properly marked as destructive withDestructiveHint: true
2. ✅Full audit trail via GitHub's native audit logging
3. ✅Requires proper permissions (actions:write scope)
4. ✅Legitimate use cases (storage management, compliance retention policies)

Let me know how to proceed.
Thanks.