explain_finding
Explain what a finding means and why it matters, in plain language. Pass the rule id (e.g. unpinned-action) or a category. No network, no file access.
LABSCO SUMMARY
Small, local, and honest about where it stops.
The whole ruleset targets a specific failure: workflow files that were written once, pinned to a tag, and never revisited — which is how supply-chain changes get in without anyone approving them. Findings come with a file and a line, and the fix plan is text you apply yourself, so nothing is rewritten behind you. It says plainly that it is not a security audit; treat a clean result as a clean maintenance check, not as an all-clear.
What it is
A local checker for CI hygiene. It reads workflow files and update-automation config in place, applies a fixed ruleset, and reports findings by category. It makes no network requests, changes no files, and runs nothing from the repository.
What you get
- A scan of a local repository returning findings by category, each with the file, the line and a suggested fix
- Third-party actions pinned to a movable tag or branch rather than a commit SHA, flagged as what they are — a dependency that can change under you
- Workflow token permissions that are write-all, and workflows with no explicit permissions block at all
- Whether update automation is present, since a repository with no Dependabot or Renovate config drifts silently
- Context-dependent patterns marked for human review rather than auto-judged, such as pull_request_target and script injection shapes
- Any rule explained in plain language on its own, by rule id or category, with no file access and no network
- A step-by-step fix plan as text for a rule, optionally with a repository path for context — it never edits anything, so applying the change stays your decision
Requirements
Nothing to authorize; it runs as npx -y taskbounty-check mcp and reads files on your machine. The default path makes no outbound requests, uploads nothing and has no telemetry. Pin the version in committed config and CI rather than tracking latest, if you want the same rules run to run. Know its scope: this is maintenance and hygiene on GitHub Actions and update automation, and it deliberately does not check exposed secrets, authentication, payments, webhooks or runtime behaviour. The same package runs as a CLI and a GitHub Action that writes a counts-only summary into the workflow run.
Setup effort
One command — npx -y taskbounty-check@latest mcp
USE CASES
01
Auditing a repository's workflows before you rely on them
Scan the checkout and read the findings by category, each with the file and line that produced it.
02
Getting third-party actions pinned properly
Find the actions still pointing at a movable tag, then get the fix plan for changing them to a commit SHA.
03
Tightening workflow token permissions
Surface the workflows running write-all or with no permissions block, and read what to declare instead.
04
Understanding a finding before acting on it
Ask what a rule means and why it matters in plain language — no files are read and nothing leaves the machine to answer it.
3 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
generate_fix_plan
Return a step-by-step fix plan as TEXT for a given rule (and optionally a local repo path for context). It NEVER modifies files; the user applies changes explicitly.
scan_repo
Scan a LOCAL repository for GitHub Actions + CI maintenance hygiene. Reads only workflow files on disk; makes no network requests and uploads nothing. Returns a text summary of findings by category with file/line and suggested fixes.
BEFORE YOU INSTALL
What to know first
Tools you get
3 tools when we connected. Only the mcp sub-command starts the server; npx -y taskbounty-check@0.1.6 . runs a CLI scan instead.
Requires
npx on PATH
Where it runs
Both documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 3 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y taskbounty-check@latest mcpMCP Clients
Cursor
CURSOR · JSON
{
"mcpServers": {
"taskbounty-check": {
"command": "npx",
"args": [
"-y",
"taskbounty-check@latest",
"mcp"
]
}
}
}Claude Code
CLAUDE CODE · TERMINAL
claude mcp add taskbounty-check -- npx -y taskbounty-check@latest mcp
