Static analysis that runs the actual Go toolchain and reports only what it can prove — no LLM guessing. It never rewrites your code unless you ask.
Signal, not noise
An LLM will confidently list "issues" — many of them guesses that evaporate the moment you open the file. gospect is the opposite kind of tool: it is certain about a bounded set of things, and silent about everything it can't prove.
Why gospect-mcp
The output is a report. It never touches your code — fixing is a separate, opt-in, self-verifying step.
Pure Go tooling — go/packages, go/analysis, SSA. No model in the server; your agent brings the judgment.
Semantically-backed findings, not grep guesses. Generated code is skipped automatically.
Point it at the repo root — every nested go.mod is discovered and scanned in one run.
Per-line //gospect:ignore, a repo-wide .gospectignore, and baseline mode for big repos.
Severity gates, PR comments, SARIF annotations, and optional govulncheck for CVE deps.
What it catches
The default set is built entirely on golang.org/x/tools — the same analyzers behind
go vet, plus a few more. Opt into the deeper staticcheck SA analyzers with one flag.
Install
curl -fsSL https://raw.githubusercontent.com/backendArchitect/gospect-mcp/main/install.sh | bash
brew install backendArchitect/tap/gospect-mcp
docker run --rm -v "$PWD":/work ghcr.io/backendarchitect/gospect-mcp scan ./...
go install github.com/backendArchitect/gospect-mcp@latest
gospect-mcp scan /path/to/your/module ./...
Prebuilt binaries (Linux / macOS / Windows · amd64 & arm64) live on the
Releases page.
Run gospect-mcp help for every command and flag.
Performance
go build — not the tool.Warm-cache, single machine. The first scan of a big repo compiles its dependencies once;
every scan after that is fast. Diff mode (-since) turns a full scan into a ~1–2s PR check.
| Scope | Packages | Time | Notes |
|---|---|---|---|
| Single small module | ~12 | ~1s | load 0.9s / scan 0.1s |
| Mid-size module | 272 | ~2.5s | load 2.1s / scan 0.5s |
| Full 9-module monorepo | 458 | ~26s | modules load in parallel |
When you want it
The scan never edits your code. Fixing is a separate, explicit command: it applies one change, re-scans, and keeps it only if it verifies — the finding is gone, no new findings appeared, and the module still builds. Anything else is rolled back.
gospect-mcp fix -safe . # deterministic analyzer fixes — no AI, still verified gospect-mcp fix -detector nilness . # drive your installed agent (claude, aider…), then verify gospect-mcp fix -n 5 . # fix several; each verified fix is its own commit gospect-mcp --allow-fix # opt-in: expose a guarded, verified fix tool over MCP
Every fix requires a clean git tree, so a rejected change reverts
cleanly and never leaves you half-edited. The MCP server stays report-only unless you start it with
--allow-fix — and even then the exposed fix tool is deterministic and self-verifying.
Multi-agent
gospect speaks MCP over stdio, so any client can use it. Every scan is stateless — no shared index, no daemon — so point as many agents at it as you like with nothing to coordinate.
claude mcp add gospect gospect-mcp
By default the server is report-only — an agent can’t change your code through gospect, only surface findings and, on request, a fix envelope. Verified fixing is a separate, opt-in step (above).
In CI
A drop-in GitHub Action gates the build, posts a findings comment on the PR, and uploads SARIF for inline annotations. Baseline mode lets you turn gospect on for a repo that already has hundreds of findings.
gospect-mcp check -fail-on high . # fail the build on any high-severity bug gospect-mcp check -since origin/main . # diff mode: gate only the PR's changes (~1–2s) gospect-mcp scan -format sarif . > gospect.sarif # SARIF → inline PR annotations gospect-mcp check -baseline base.json . # gate only on NEW findings
Used in production
gospect isn’t a demo — it runs on every pull request in teams shipping Go to production.
The first team to adopt gospect in CI — it gates every pull request on their Go backend. lacrossetechnology.com →
FAQ
No — it complements go vet and golangci-lint. gospect is report-first (it never edits your code by default), it speaks MCP so AI editors like Claude Code and Cursor can call it, and on request it can apply a verified fix that rolls back on any regression. By default it reports only genuine, compiler-proven bugs.
Yes. gospect is an MCP (Model Context Protocol) server over stdio, so any MCP client — Claude Code, Cursor, Windsurf, Cline, VS Code, Zed and more — can call it. Every scan is stateless, so you can point many agents at it at once.
Not by default — it's report-first. Fixing is a separate, explicit command that applies one change, re-scans, rebuilds, and rolls the change back if anything regresses. The MCP server stays read-only unless you start it with --allow-fix.
No. gospect is deterministic and runs the real Go toolchain (go/analysis, SSA). There's no LLM in the server and no API key — your AI agent, if any, brings the judgment.
gospect runs those analyzers (and more), but adds report-first output, an MCP server for AI agents, a verified auto-fix loop, and CI integration (a PR gate, a findings comment, and SARIF). The deeper staticcheck SA checks are opt-in with -staticcheck.
Yes, opt-in. gospect-mcp fix applies a deterministic analyzer fix, or drives an installed AI agent, then verifies the result and rolls back on any regression. It requires a clean git tree so a rejected change reverts cleanly.
One binary, no config, no services. Scan your module in seconds — and only hear about the bugs that are real.