4.8 KiB
gopls MCP server & native LSP tool reference
Table of contents
- Starting the server
- Registering with Claude Code
- MCP tools
- The native
LSPtool - What the MCP server can and cannot do
Starting the server
A standalone gopls instance speaking MCP over stdin/stdout, launched fresh per session, no LSP client involved:
gopls mcp
Only sees files as they exist on disk — an edit made through a different tool but not yet saved is invisible to it. This is the right mode for an agent-only workflow with no attached editor.
Registering with Claude Code
claude mcp add gopls -- gopls mcp
MCP tools
Eight tools, all keyed by name/path/query rather than cursor position — this is the main ergonomic difference from the native LSP tool.
| Tool | Purpose | Example |
|---|---|---|
go_workspace |
Learn the workspace's overall structure — module, multi-module workspace, or GOPATH project. Call this first, once per session. | go_workspace({}) |
go_vulncheck |
On-demand reachability check: which known vulnerabilities does the current build actually reach. Run right after go_workspace if in a Go workspace, and again after any go.mod change. |
go_vulncheck({"pattern":"./..."}) |
go_search |
Fuzzy search for a type, function, or variable by name across the workspace — use when you don't know the exact location. | go_search({"query":"server"}) |
go_file_context |
Summarize a file's dependencies on other files in the same package. Run this immediately after reading any Go file for the first time. | go_file_context({"file":"/path/to/server.go"}) |
go_package_api |
Show a package's public API — most valuable for third-party dependencies or sibling packages in a monorepo you haven't read file-by-file. | go_package_api({"packagePaths":["example.com/internal/storage"]}) |
go_symbol_references |
Find every reference to a symbol — run before modifying any definition to gauge the blast radius. | go_symbol_references({"file":"/path/to/server.go","symbol":"Server.Run"}) |
go_diagnostics |
Build/analysis errors for the given files — mandatory after every edit. | go_diagnostics({"files":["/path/to/server.go"]}) |
go_rename_symbol |
Rename a symbol and every reference to it, workspace-wide, with the same safety checks as LSP rename (blocks changes that would break interface satisfaction). | — |
See SKILL.md for the Read/Edit workflow order these tools are designed to be chained in.
The native LSP tool
Claude Code's built-in editor-style integration — a different mechanism from the MCP server above, worth wiring in addition to it, not instead of it.
Enabling it:
- Set the environment variable
ENABLE_LSP_TOOL=1(off by default). - Install
gopls(go install golang.org/x/tools/gopls@latest). - Install the official
gopls-lsp@claude-plugins-officialmarketplace plugin to wiregoplsas the Go language server backing the tool.
Operations, all keyed by line/character rather than name/path:
goToDefinitionfindReferenceshoverdocumentSymbolworkspaceSymbolgoToImplementation- call hierarchy
goToTypeDefinition is intentionally absent from this list — the native tool does not expose it, so type-definition navigation has no agent-invocable path (see features.md).
Because these need a location up front, they're most efficient once you already have one — right after a grep or a file read — rather than as the first move in an investigation (that's what go_search on the MCP server is for).
Its unique value: compiler diagnostics are pushed into context automatically after every edit, with no explicit diagnostics call needed — the MCP server's go_diagnostics requires an explicit invocation each time.
What the MCP server can and cannot do
The gopls MCP server wraps LSP functionality with these boundaries:
- Can: read files from the filesystem and return their contents; execute
gocommands to load package metadata (which may reachproxy.golang.organd write to the local Go module/build cache); write to gopls's own cache/configuration files; upload telemetry if the user has opted in. - Cannot: make arbitrary writes to the source tree outside of the edits a tool call explicitly returns; make arbitrary network requests beyond what
goitself needs to resolve the build.
Either mode — MCP or native LSP — only ever reasons about code that is present and resolvable in the local build: the workspace plus every dependency exactly as pinned in go.sum, including replace directives. For anything outside that boundary, → See samber/cc-skills-golang@golang-pkg-go-dev skill (godig).