Loading ToolBench
MCP server for analyzing Go module dependencies from go.mod files
Three tools with basic verb-noun naming (scan_, check_, visualize_) but weak descriptions (all ~60 chars, below 194-char baseline). All tools accept a single string parameter 'goMod' with minimal context. No output schemas documented. No error handling guidance. No parameter constraints or validation hints. Tools lack context about when to use each vs. the others. Descriptions do not explain prerequisites, return structure, or failure modes.
Check for outdated dependencies from go.mod content
Scan Go dependencies from go.mod content
Generate a simple visualization of dependencies from go.mod content
All tool descriptions are under 70 characters and lack actionable context. 'Scan Go dependencies from go.mod content' does not explain when to call this vs. check_outdated, what the output structure is, or what happens on parse failure.
No output schemas documented. Tools return markdown tables (scan_dependencies, check_outdated) or a Graph string (visualize_dependencies), but LLMs cannot infer structure. Responses should declare field names, types, and whether results are paginated.
Parameter 'goMod' lacks format guidance. No hint that it expects raw go.mod file content, not a file path. No validation rules (e.g., 'must contain a require block'). LLMs may pass file paths or invalid content.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
No error handling guidance. If go.mod parsing fails (malformed syntax, missing require block), tools return generic errors. LLMs receive no recovery hints (e.g., 'Try providing the full go.mod file' or 'Check for syntax errors').
Tool composition unclear. All three tools accept identical input (goMod string) and operate on the same data. No guidance on which to call first, whether results can be chained, or if they are mutually exclusive. LLMs may call all three redundantly.