MCP server security on GitHub — Action and PR gate

Why a PR-time gate, not an install-time check

An install-time scan is the right defense if you're a solo developer evaluating one server before claude plugin install. It's the wrong defense once a team is involved, for two reasons:

• Install-time is too late. By the time a server is in someone's .mcp.json or ~/.claude/plugins/, the credential-stealer or SSRF is already configured. The PR that added it is the natural choke point — and it's the one place a reviewer is paid to look.
• Install-time is too distributed. Solo devs across a team will install whatever they need, on a schedule no central process can govern. The PR that adds an MCP server to the team's shared agent config (or to a CI agent's workflow) is centralized; that's where policy enforcement scales.

The same logic that put dependency review and code scanning into PR checks puts MCP-server review there too. An install-time scan catches the case where someone adds foo-mcp to their personal config; a PR gate catches the case where they add it to the team's. Both layers are useful; the PR gate is the higher-leverage one if you're building team policy.

The Action — what it does

1. Detects MCP additions. Diffs the PR for new entries in common MCP config locations (.mcp.json, mcp.config.json, ~/.claude/plugins.json, custom paths via input). For author repos, uses the repo itself.
2. Resolves each addition to a canonical source. A GitHub URL, npm package name, or local path. The Action follows package-redirect chains the same way the website scanner does.
3. Runs the six-axis scan. Same engine as the public scanner, same v0.3 methodology, same calibration set. The Action runs the static layer locally and the LLM-assist layer via the SkillAudit API (a Pro-tier API key is required for the LLM-assist axis).
4. Posts the result as a check. The check status is "passing" if the resulting grade meets the minimum, "failing" otherwise. The check page links to the full report card at /audits/<owner>-<repo>/.
5. Fails the workflow if any addition is below the minimum. Configurable per-repo via the min-grade input. Default is B. Below the min = workflow fails = PR can't merge if branch protection is enabled.

Workflow YAML

Drop this into .github/workflows/skillaudit.yml in the repo where you want the gate enforced:

name: SkillAudit gate

on:
  pull_request:
    paths:
      - '.mcp.json'
      - 'mcp.config.json'
      - 'src/**/*.ts'
      - 'src/**/*.py'

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
      checks: write
    steps:
      - uses: actions/checkout@v4

      - name: Run SkillAudit gate
        uses: skillaudit/skillaudit-gate@v1
        with:
          # Minimum grade to allow. A | B | C | D | F.
          # Below this = workflow fails.
          min-grade: B

          # Where to look for MCP server additions.
          # Default: .mcp.json, mcp.config.json
          mcp-config-paths: |
            .mcp.json
            mcp.config.json

          # API key for the LLM-assist axis. Free tier runs static-only.
          api-key: ${{ secrets.SKILLAUDIT_API_KEY }}

          # Optional: scan this repo as itself (use for author repos).
          scan-self: false

The action posts a check on the PR. The check page shows the grade per added server, the per-axis breakdown, and a deep link to the public report card. If the grade meets the minimum, the workflow passes; otherwise it fails and the merge is blocked (assuming branch protection is on).

What's caught at PR-time, and how it composes with code scanning

GitHub-native code scanning (CodeQL, third-party SARIF uploads from Semgrep, Snyk Code, etc.) is the right tool for conventional SAST findings — XSS, SQLi, OWASP web patterns, dependency CVEs through SCA. None of that goes away. SkillAudit's gate adds an orthogonal axis: does this MCP server's tool-handler code expose a class of bug that conventional SAST doesn't model.

Concretely, here's the split for a representative MCP-adding PR:

• Code scanning catches: a CVE in axios the new server pulls in; an XSS pattern if the server renders HTML; a hard-coded secret string in the repo (gitleaks-style scan).
• SkillAudit gate catches: the SSRF in server.tool('fetch_url', ({url}) => fetch(url)) that the new server registers; the credential echo in the tool's debug log; the prompt-injection vector that's reachable when the tool's output is consumed by a downstream model; the maintenance signal (last commit, archive flag) on the upstream repo; the over-broad OAuth scope.
• Both: a string-interpolated execSync in the tool body. Code scanning would flag the dangerous sink; SkillAudit additionally pairs it with the registered-tool context that makes it reachable from LLM input.

The two layers compose. A typical Pro-plan team enables both: code scanning for the framework and the dependency tree, SkillAudit for the MCP surface. The GitHub code scanning alternative page covers the comparison in side-by-side detail.

Configuring the gate for different repo shapes

Author flow: getting your repo's grade up before listing

If you're publishing a Claude skill or MCP server to a public marketplace and want the badge before submission, the gate becomes a self-improvement loop. Set scan-self: true, min-grade: A, push a branch, and read the failing check's report. Most A-grade fixes are mechanical; the patterns are documented in Anatomy of an A-grade MCP server:

• Switch fetch(url) to fetch(url) behind an allowlist.
• Remove the console.log({env: process.env}) from the debug branch.
• Drop the unused repo OAuth scope; public_repo is enough for what your tools do.
• Add a runnable example to the README that calls the tool with a real argument.
• Tag a release; the maintenance axis weights last-commit recency.

Each fix re-runs the scan in the next PR. The grade rebuilds. Authors in our corpus moved from F to A in roughly five PRs of mechanical work; the median was three.

Related questions

Further reading

• MCP server security scanner — what to look for in one — the threat-model deep dive.
• How to run an MCP server security scan — the buyer-side workflow without CI.
• The minimum-grade install gate policy — what min-grade to set, and why.
• GitHub code scanning vs SkillAudit — the orthogonality argument in side-by-side detail.
• Anatomy of an A-grade MCP server — the five patterns you'll need to reach if you set min-grade: A.
• Engine v0.3 methodology — the static + LLM-assist layers and their calibration.