Loading ToolBench
MCP server for getting Go documentation for packages, types, functions, and methods
Single tool 'godoc' has a well-structured schema with all 6 parameters typed and described. Description is comprehensive (450+ chars) and includes best practices and usage patterns. However, output schema is not documented, the tool returns text content but LLMs cannot infer the structure of that text (is it formatted? structured? what fields?). Parameter descriptions are detailed and actionable. No error handling guidance is present, if go doc fails, the LLM receives a raw error with no recovery path. Tool naming is clear and verb-based ('godoc' as a noun is slightly weak; 'get_godoc' would be stronger). Overall solid definition with room for output documentation and error recovery patterns.
Get Go documentation for a package, type, function, or method. This is the preferred and most efficient way to understand Go packages, providing official package documentation in a concise format. Use this before attempting to read source files directly. This tool is a great way to avoid hallucinations. If you generate code and are seeing errors about missing packages, try using this tool to verify that the package or symbol within the package exists. Best Practices: 1. ALWAYS try this tool first before reading package source code. 2. Start with basic package documentation before looking at source code or specific symbols. 3. Use the show_all_documentation option when you need comprehensive package documentation. 4. Only look up specific symbols after understanding the package overview. Common Usage Patterns: - Standard library: Use just the package name (e.g., "io", "net/http") - External packages: Use full import path (e.g., "github.com/user/repo") - Local packages: Use relative path (e.g., "./pkg") or absolute path The documentation is cached for 5 minutes to improve performance.
Output schema not documented. Tool returns mcp.NewTextContent(doc) but LLMs cannot infer the structure, format, or fields of the returned documentation text. Should document: 'Returns formatted Go documentation as plain text, including package overview, exported symbols, and optionally source code and unexported symbols.'
No error handling guidance. When go doc fails (e.g., package not found, invalid symbol), the tool returns a raw error. Should categorize errors and guide recovery: 'Package not found. Try searching with a partial name or verify the import path is correct.'
Tool name 'godoc' is a noun, not a verb. Verb-based naming (get_godoc, fetch_godoc) helps LLMs infer intent from the name alone. Current name requires reading the description to understand it retrieves documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
No result limits or pagination documented. If a package has hundreds of exported symbols and show_all_documentation=true, the response could be very large. Should cap results and document the limit in the description.
Parameter 'working_dir' is optional but its necessity depends on the 'path' parameter (relative paths require it). This dependency is documented in the description but not enforced. Should validate and return a clear error if a relative path is used without working_dir.