Scan MCP and agent configs on every pull request with a GitHub Action

The short answer

Add the Deedglass scan Action to .github/workflows/. On every pull request it runs deedglass scan on the head and the base, writes the grade to the job summary, uploads SARIF to code scanning, and a second workflow posts one comment when the pull request changes agent config. Set fail-under: C to fail the job when the grade drops below C. It’s free on public and private repositories with no key or account, and scan data is never sent to Deedglass.²

Why in the pull request

MCP configs drift. A developer adds a database server to try something, commits .mcp.json along with the feature, and now every clone of the repository gives the agent that server. Reviewers look at the feature code; a JSON file with a new mcpServers entry rarely gets a second look.

A check on the pull request turns that file into something with a visible consequence: “this pull request moves the grade from B to D, and here’s why”. The ten-minute config audit explains what moves a grade.

The two workflows

The Action is split in two on purpose. The scan runs with a read-only token on the pull request’s code; the comment runs afterwards, from the base repository, and never checks out pull request code.²

Code A settings file: the rules a tool reads before it acts.

# .github/workflows/deedglass-scan.yml
name: Deedglass scan
on: [pull_request]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: deedglass/scan-action@0047a3d4402ac9f7f5d7ee2060a0f4a5bdbb115b # v1
        with:
          fail-under: C

Code A settings file: the rules a tool reads before it acts.

# .github/workflows/deedglass-comment.yml
name: Deedglass comment
on:
  workflow_run:
    workflows: ["Deedglass scan"]
    types: [completed]
permissions: {}
jobs:
  comment:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      actions: read
    steps:
      - uses: deedglass/scan-action/comment@0047a3d4402ac9f7f5d7ee2060a0f4a5bdbb115b # v1

Both are pinned to the v1.1.0 commit, with the tag in a comment, which is how the README recommends using it. fetch-depth: 0 lets the scan check out the base commit to compare against.

The inputs are short: version (which deedglass release to run), fail-under, sarif (auto, always or never), dir and badge.²

What a run produces

Each run leaves four things, all inside GitHub:

The comment appears only when the pull request touches agent config, such as .mcp.json, .cursor/mcp.json, .vscode/mcp.json, package.json, pyproject.toml or requirements*.txt, and only when the grade, counts or findings differ from the base. Later runs edit the same comment rather than adding new ones.² The comment carries the line “Reported by this PR’s run. This comment is information only and never blocks a merge.”²

The job summary also ends with a static shields.io badge line for the grade, and badge: true writes .deedglass/score.json into the workspace for a later step of yours to commit. The Action never commits.²

Failing the build on a grade

You can see exactly what the scan job will do by running the same command locally. On the careless nine-server sample from our audit walkthrough, which grades D:⁴

Code What the screen or file shows, copied as is.

$ npx deedglass@0.13.0 scan --ci --format sarif --fail-under C
...
Wrote deedglass-scan.sarif (SARIF 2.1.0, 2 rules).
✕ Blast radius D is below C (--fail-under C). The report was written.

Exit code 1. The two rules in the SARIF file were the two findings: the archived Postgres server and the database URL in the client config, both at warning level.⁴

Pick a threshold you’ll actually hold. If the repository is at C today, start with fail-under: C so the check blocks regressions without blocking every open pull request, then tighten it once you’ve fixed what’s there.

The comment job never fails, so it can’t block a merge; only the scan job’s own check can, and only when you set fail-under (or the inputs are invalid, the runner is Windows, or the download fails its check).²

What leaves the runner

Supply-chain questions are fair for anything you add to CI. The answers, read from the v1.1.0 source:

• One download. The Action downloads the deedglass release archive from the deedglass GitHub releases and checks its sha256 against a line committed in the Action’s own checksums/ folder. A version with no committed line is refused before any download.²
• The default version is 0.11.0, the release the Action was tested with; version can pin another release that has a checksums file.² That means the Action’s scan can lag the latest CLI. Pin a version deliberately rather than assuming it tracks npm.
• No requests to Deedglass. Results go to GitHub only: the summary, code scanning, the artifact and the comment, which talks only to the GitHub API for your repository.²

Questions people ask

Is the Deedglass scan Action free on private repositories?

Yes. It’s free on public and private repositories with no key and no account.²

Does the Action send my code or scan results anywhere?

Scan data is never sent to Deedglass. Results go to GitHub only: the job summary, code scanning, a workflow artifact and the pull request comment.²

Which deedglass version does the Action run?

0.11.0 by default, sha256-checked against a line committed in the Action. The version input pins any release that has a committed checksums file; any other version is refused before a download.²

Limits to know

The Action runs the same scan as the CLI, so it has the same blind spots. In our runs the scan didn’t flag API tokens written into a config (only a database URL), counted write tools only for the servers it knows, and listed no tools for servers given as a URL.⁴ A clean grade on a pull request means the scan found nothing it knows about. It doesn’t mean the config is safe.

If you’d like a quick look before wiring CI, paste a config into /check: it runs the same scan code in the browser and uploads nothing.⁴⁴ And for the agents themselves, not just their configs, protect adds a before-a-command guard. What the grade measures is explained under blast radius, and the wider list of checks is in the MCP security checklist. Where each client keeps its config is in the config paths post.

To see the grade your repository would get, run npx deedglass scan at its root before adding the workflow. What the grade means explains the scan’s letter. To watch the checks without installing anything, open the playground.

Written with AI assistance and checked against our claims register.