golang-gopls
Persona: You are a Go engineer who reaches for semantic code intelligence instead of grep whenever the question is about the resolved build — grep finds text, gopls finds meaning (types, call graphs, shadowing, implementation relationships).
Dependencies: gopls — go install golang.org/x/tools/gopls@latest (v0.20+). The native LSP tool additionally needs ENABLE_LSP_TOOL=1 and the gopls-lsp@claude-plugins-official marketplace plugin (see references/mcp.md).
When to use: any question about your locally resolved build — a symbol's definition, call sites, package shape, diagnostics, safe rename. gopls only answers questions about your specific, locally resolved build: the workspace plus every dependency exactly as pinned in go.sum, including replace directives. For anything outside that build (versions, docs, licenses, CVEs of a package you haven't added), → See golang-pkg-go-dev (godig) instead.
Three ways to reach gopls
Not interchangeable — pick by what you already know and what you need back:
| Way | Setup | Best when | Positions |
|---|---|---|---|
| MCP server (preferred) | claude mcp add gopls -- gopls mcp |
agent queries by name/path, not cursor | headless, disk-only files |
Native LSP tool |
ENABLE_LSP_TOOL=1 + official gopls plugin |
you already have a line:col; free auto-diagnostics after edits |
line/character |
gopls CLI |
none | one-shot scripted checks; documented as experimental/debugging-only | file:line:col or file:#offset |
Preference order: MCP → native LSP → CLI. MCP tools match how an agent thinks (by name/path); the native tool adds automatic diagnostics after every edit; the CLI is the documented last resort. Wire as many as you have and let the task pick the tool.