workflowlint-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| --dir | No | Only files inside this directory can be read (default: the current directory). Server flag, e.g. `uvx workflowlint-mcp --dir /path/to/repo`. | . |
| --disable | No | Comma-separated rule ids to turn off, e.g. `--disable GHA1013,GHA1021`. Repeatable. | |
| GITHUB_TOKEN | No | Optional. If set in the server's environment it is sent only as the Authorization header to api.github.com for the opt-in online SHA lookup (`pin_actions_plan(online=true)`), avoiding the 60 requests/hour limit. Never printed. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Audit GitHub Actions workflows (.github/workflows/*.yml and local composite actions) for security and correctness problems. Read-only and offline by default. Pass a workflow file, a repo root, or the workflows directory (relative to the server's --dir, or absolute inside it). Typical flow: workflows_overview to see what exists, lint_workflows for rule IDs + line numbers + concrete fixes, fix_preview for a diff of the safe fixes, pin_actions_plan to pin actions to commit SHAs, permissions_review for least-privilege GITHUB_TOKEN permissions, explain_triggers for when a workflow runs (cron explained with next run times), job_graph for the needs graph. Silence a finding with a # workflowlint-ignore: GHA1003 comment on the line above it.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workflows_overviewA | Summarize GitHub Actions workflows: triggers, jobs with runners and |
| lint_workflowsA | Lint workflows and composite actions with 33 rules (GHA1001-GHA1033). Each finding has a rule id,
severity (error/warning/info), file:line (exact line inside multi-line |
| explain_triggersB | Explain in plain English when each workflow runs: push/PR filters, which pull request types, fork
behaviour, manual inputs, reusable-workflow interface, workflow_run chains, and |
| permissions_reviewA | Show the effective GITHUB_TOKEN permissions of every job (job-level replaces workflow-level; absent
means the repository default), infer what each job actually needs from the actions and gh/git commands
it uses, flag write access that looks unnecessary and permissions that are missing, and print a
least-privilege |
| job_graphB | Draw each workflow's job |
| pin_actions_planA | List every |
| fix_previewA | Show a unified diff of the safe automatic fixes for a workflow file (or every workflow under a
directory): add a top-level |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a recognizable specialization: summary, rule-based linting, trigger explanation, token permissions, job dependency graph, action pinning, and fix diffs. There is mild overlap where workflows_overview already reports permissions and pinned/unpinned actions that permissions_review and pin_actions_plan dig into, and lint_workflows also flags unpinned actions and permission issues. The descriptions make clear which is the deep-dive versus the summary, so misselection is unlikely but not impossible.
All names are snake_case and readable, but the verb/noun ordering is inconsistent: verb_noun in lint_workflows, explain_triggers, pin_actions_plan, fix_preview, versus noun_verb in workflows_overview and permissions_review, plus the bare noun job_graph. An agent can still infer behavior, but there is no single predictable pattern.
Seven tools is well within the ideal range and each one maps to a distinct analysis concern of a GitHub Actions auditing server. No tool feels redundant padding or conspicuously absent from the set.
The surface covers the full read-only audit lifecycle: inventory, linting, trigger semantics, permissions, dependency graph, pinning plan, and a fix diff with re-lint verification. The main gap is that fix_preview never applies changes and there is no write/apply tool, so remediation is a manual dead end by design; cross-file or multi-repo bulk analysis is also absent. These are workaroundable but limit end-to-end automation.