Skip to main content
Glama
eliottreich

TaskBounty Check

by eliottreich
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

taskbounty-check

A local check for GitHub Actions and CI maintenance hygiene (third-party action pinning, workflow token permissions, and update automation), built for apps shipped with Lovable, Bolt, Replit, Cursor, or v0.

Local by default. No uploads. No telemetry. It reads only your workflow files, on your machine. The default code path makes no outbound network requests, writes its report locally, and sends nothing anywhere. There is no analytics or phone-home of any kind. Only the opt-in --gh-org mode uses the network (through your own gh session).

Works with Cursor, Claude Code, and Codex (local MCP server, below).

Three ways to use it

1. GitHub Action — add a maintenance check to CI that writes a summary to the run (no PR comments, no source upload):

permissions:
  contents: read
steps:
  - uses: actions/checkout@v4
  - run: npx taskbounty-check@0.1.6 . --github-summary --no-network

Want a human to interpret or fix what the Action surfaces? Request a free launch-safety review. TaskBounty gets no access to your repo, source, or workflows unless you submit that form.

2. Agent / MCP — a local stdio server for Cursor, Claude Code, and Codex:

npx -y taskbounty-check@0.1.6 mcp

3. One-off CLI — scan the current repo locally and write a report:

npx -y taskbounty-check@0.1.6 .

Pin a version (@0.1.6) in committed config and CI for reproducibility. @latest is convenient for a quick one-off, but a pinned version is the reproducible choice.

The GitHub job summary

The Action writes a counts-only maintenance summary to the workflow run (categories and next steps, no filenames, line numbers, or repo source). Below is that exact summary, rendered from this repo's own CI output:

TaskBounty check: GitHub Actions maintenance summary

See it produced live by the self-check job in this repository's Actions runs.

Prefer a guided walkthrough? Follow the five-minute real-repository quickstart.

Learn more

Related MCP server: gha-doctor

Supported checks (and honest limitations)

Checks (GitHub Actions + CI maintenance hygiene):

  • Third-party actions pinned to a movable tag/branch instead of a commit SHA

  • Broad (write-all) workflow token permissions

  • Missing explicit permissions: block

  • Update automation (Dependabot/Renovate) presence

  • Context-dependent workflow patterns flagged for private review (e.g. pull_request_target, script injection)

Does NOT check (these need a manual review): exposed secrets, auth/authorization, payments, webhooks, runtime behavior. It is a maintenance/hygiene check, not a full security audit or a penetration test.

What it does

  • Reads only your GitHub Actions workflow files and update-automation config, scans them in-process with a deterministic ruleset (the same rules as the public checker), and writes a local HTML + JSON report. It does not execute workflows, install dependencies, or run any repository code.

Modes

Mode

Command

Network

Single repo

npx taskbounty-check .

none

Directory of repos

npx taskbounty-check ./all-repos

none

Explicit paths

npx taskbounty-check --manifest repos.json

none

GitHub org (your gh session)

npx taskbounty-check --gh-org <org>

yes, opt-in

--gh-org uses your existing gh CLI session to fetch each repo's workflow files to this machine (read-only). Your GitHub token is never read by this tool and never sent to TaskBounty.

What is read, written, transmitted

Run --explain-data to print this at any time.

  • Reads (allowlist — nothing else is opened): <repo>/.github/workflows/*.yml|*.yaml and update-automation config (dependabot.yml/renovate.json*). Never source files, .env, secrets, SSH keys, credential stores, or anything outside the selected repository roots. Symlinks that escape a root are skipped, never followed.

  • Writes (local only): <out>.json (full detail) and <out>.html.

  • Transmits: nothing by default. --share uploads nothing — it writes a sanitized, counts-only file (scan id, label, candidate counts by category, private-review count, scanner version, timestamps; repo names only with --include-repo-names) for you to submit manually. Network stays off under --share. Only --gh-org intentionally uses the network.

Flags

--share · --gh-org <org> · --manifest <file> · --org-label <label> · --include-repo-names · --dry-run · --explain-data · --delete-local-report · --no-network (default everywhere except --gh-org) · --out <basename> · --version · --help

Want help interpreting or fixing these results?

Request a free 20-minute launch-safety review: https://www.task-bounty.com/ai-app-security-check/review?utm_source=npm&utm_medium=npm_readme&utm_campaign=workflow_security

TaskBounty receives nothing unless you submit that form. The scan runs locally and the full report stays on your machine; the review form gives us no access to your repositories, source, workflows, or secrets.

GitHub Code Scanning (SARIF)

Emit SARIF 2.1.0 and surface findings in your repo's Security → Code scanning tab:

npx taskbounty-check@latest . --format sarif --output taskbounty.sarif

The SARIF carries deterministic rule ids (taskbounty/<rule>), severity levels, and file/line references — no source contents, secrets, or environment values, and no network access. Confirmed findings are emitted as kind: fail; lower-confidence items as kind: review.

Help interpreting SARIF results: https://www.task-bounty.com/ai-app-security-check/review?utm_source=github&utm_medium=sarif_docs&utm_campaign=workflow_security

Upload it with the official action (full example in examples/code-scanning.yml):

permissions:
  contents: read
  security-events: write
steps:
  - uses: actions/checkout@v4
  - run: npx taskbounty-check@0.1.6 . --format sarif --output taskbounty.sarif
  - uses: github/codeql-action/upload-sarif@v3
    with:
      sarif_file: taskbounty.sarif

Local agent (MCP)

Run a local stdio MCP server so Codex, Claude Code, or Cursor can scan and reason about findings in your editor. It runs locally, makes zero outbound network requests, uploads no source, and never modifies files — generate_fix_plan returns a plan as text for you to apply yourself.

npx taskbounty-check@latest mcp

Tools: scan_repo (local scan summary), explain_finding (plain-language explanation), generate_fix_plan (text fix plan).

Want a human to review the plan? https://www.task-bounty.com/ai-app-security-check/review?utm_source=mcp&utm_medium=mcp_docs&utm_campaign=workflow_security

Cursor — .cursor/mcp.json:

{ "mcpServers": { "taskbounty-check": { "command": "npx", "args": ["-y", "taskbounty-check@latest", "mcp"] } } }

Claude Code:

claude mcp add taskbounty-check -- npx -y taskbounty-check@latest mcp

Codex — in ~/.codex/config.toml:

[mcp_servers.taskbounty-check]
command = "npx"
args = ["-y", "taskbounty-check@latest", "mcp"]

Security

Zero runtime dependencies. Published to npm with provenance (verify on the package's npm page). The default run makes no outbound requests and uploads nothing; see the methodology for the full data-handling and scope boundaries.

Available Tools

3 tools
explain_findingA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
ruleYesRule id, e.g. unpinned-action, broad-permissions, no-permissions-block, script-injection.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states 'No network, no file access' and 'explain' implies a read-only operation, but does not explicitly confirm non-destructiveness or discuss authorization needs. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of three short statements that are front-loaded with the purpose. Every sentence adds meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, the description covers purpose, input format, and constraints. It lacks details about output format or error handling, but given the simplicity and expectation of plain language, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the parameter. The description adds that the parameter can accept a 'category' in addition to rule ids, providing extra context, but this is a minor addition.

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?

The description uses a specific verb 'explain' and resource 'finding', and provides examples of rule ids. It clearly states what the tool does, but does not explicitly distinguish it from sibling tools like generate_fix_plan or scan_repo.

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?

The description implies the tool is for understanding findings and mentions constraints ('No network, no file access'), but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.

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

generate_fix_planA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
ruleNoRule id to plan a fix for.
pathNoOptional local repo path for context (read-only).

TDQS

A3.8/5.0
Behavior4/5

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

Despite no annotations, the description explicitly states the tool does not modify files, which is a key behavioral trait. It also clarifies that the user applies changes manually, adding transparency beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that cover purpose, input, and behavior. No redundant information. Front-loaded with the key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no annotations or output schema, the description covers purpose, inputs, and non-destructive behavior. It could be more complete by describing the format of the fix plan output, but overall it provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds little beyond the schemas for 'rule' and 'path'. It reiterates what the schema already provides without adding new semantic details or constraints.

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

Purpose5/5

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

The description clearly states the tool returns a step-by-step fix plan as text for a given rule. It distinguishes itself from siblings 'explain_finding' and 'scan_repo' by focusing on generating a fix plan rather than explaining or scanning.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'explain_finding' or 'scan_repo'. The description only states the inputs without clarifying in which scenarios this tool is appropriate.

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

scan_repoA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoLocal path to a repo or a directory of repos. Defaults to the current directory.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses important behaviors: no network requests, no uploads, and reads only workflow files. This adds transparency beyond the schema, though it doesn't mention permissions or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences: purpose, behavioral constraints, and output format. It is front-loaded and each sentence adds essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (1 parameter, no output schema), the description covers purpose, behavior, and output adequately. However, it could mention error handling or path validation for completeness.

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% for the single parameter 'path'. The description adds value by mentioning the default (current directory), which is not in the schema. This helps the agent understand the parameter's behavior.

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

Purpose5/5

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

The description clearly states the tool scans a local repository for GitHub Actions and CI maintenance hygiene, using action verbs and specifying the resource. It distinguishes from siblings (explain_finding, generate_fix_plan) which are post-scan actions.

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

Usage Guidelines4/5

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

The description implies usage for local repository scanning (e.g., 'LOCAL repository', 'reads only workflow files on disk'), providing clear context. However, it does not explicitly state when not to use or list alternatives, though siblings are different enough to infer.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.6
    • First observedexplain_finding
    • First observedgenerate_fix_plan
    • First observedscan_repo
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: scanning produces findings, explaining interprets them, and generating a fix plan suggests steps. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (explain_finding, generate_fix_plan, scan_repo), making them predictable and easy to understand.

Tool Count5/5

With only 3 tools, the set is tightly scoped to a specific workflow (scan, explain, fix). This is appropriate for a focused server, avoiding unnecessary complexity.

Completeness4/5

The tools cover the main workflow from scanning to understanding to suggesting fixes. A minor gap is the lack of a tool to list all possible rules without scanning, but the workflow remains functional.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • github-actions-audit

    UnbearableDev
    F
    license
    Not graded
    quality
    D
    maintenance
    Audits GitHub Actions workflow files for supply-chain risks like script injection, leaked tokens, unpinned actions, and broad permissions.
    -

  • gha-doctor

    linnea-bakshi
    A
    license
    Not graded
    quality
    A
    maintenance
    CI health reports for GitHub Actions: flaky tests named from logs, wasted compute priced in dollars, zombie crons, PR feedback time, plus 21 lint rules with safe auto-fixes. Read-only MCP tools wrap the same Go binary.
    MIT

  • GitHub Flow MCP

    thiagorchaves
    A
    license
    C
    quality
    B
    maintenance
    A policy-aware MCP server for GitHub and GitHub Actions that enables safe AI-assisted infrastructure workflows—inspecting repositories, preparing branches and pull requests, and constrained remote mutations behind explicit preview-bound approval tokens.
    18
    MIT

  • viberevert

    madeinplutofabio
    A
    license
    A
    quality
    B
    maintenance
    Local MCP server for AI agents and vibe coding safety: deterministic risk checks (payments, auth, database, secrets, infrastructure), sessions, checkpoints, policy inspection, and fix prompts. Runs over stdio against a local git repository; no language model judges risk.
    8
    1
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eliottreich/taskbounty-check'

If you have feedback or need assistance with the MCP directory API, please join our Discord server