CLI and MCP server for the pkg.go.dev API: search packages, read docs, list versions, symbols, importers and vulnerabilities
godig exposes 18 Go package discovery tools via STDIO. Tool names follow verb_noun convention (overview, search, imported-by, packages, versions, etc.), which is good. However, descriptions are uniformly terse (10-30 chars), well below the 50-200 char LLM-optimized baseline. Parameter descriptions exist but are minimal ('Package path', 'Limit number of results'). Input schemas are visible in tools.go and use proper JSON Schema with types (string, number), but lack constraints (enums, min/max, patterns). Output schemas are not documented, callers cannot predict response structure. Error handling is absent from tool definitions; the handler returns raw errors without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Overall: functional but minimal quality.
List dependencies of a module
List packages that import a given package
List major versions of a module
Get metadata for a module
Get README for a module
Get overview information for a package or module
Get documentation for a package
Get examples for a package or symbol
Descriptions uniformly under 30 characters (e.g., 'Get overview information for a package or module' is 50 chars but most are 10-25). LLM-optimized descriptions should be 50-200 chars with context on WHEN to use the tool and WHAT it returns.
Output schemas not documented. Callers cannot predict response structure (fields, types, pagination). Tools return JSON via mcp.NewToolResultText(string(b)) but no schema is declared.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
List imports of a package
Get metadata for a package
Get licenses for a package
List packages in a module
Search packages on pkg.go.dev
Get documentation for a symbol
Get examples for a symbol
List symbols in a package
List versions of a module
List vulnerabilities for a package
No input parameter constraints (enums, min/max, patterns). 'limit' parameters are unbounded numbers; 'format' in package-doc has no enum. LLMs will pass invalid values without guidance.
Error handling absent from tool definitions. Handler returns raw error strings (err.Error()) without recovery guidance. LLMs cannot determine if errors are retryable or what to do next.
No tool annotations despite all tools being read-only. readOnlyHint should be set on all 18 tools to signal safety to agents.