Loading ToolBench
An MCP server that reads linter diagnostics from a Neovim instance via its LSP integration
Single tool with moderate definition quality. The tool has a verbose description that mixes usage guidance with functional description, reducing clarity. Input schema is present and properly typed using Go struct with mcp-go framework. However, the description conflates tool documentation with agent instruction, lacks clear state-change declaration, and parameter descriptions are minimal. The tool is read-only (good), but the extended usage notes buried in the description should be moved to separate guidance or API docs. Overall definition is functional but below production baseline (baseline avg 194 chars for descriptions; this one is ~450+ chars of guidance).
Reads linter diagnostics from the current workspace via Neovim LSP Functionality: - Uses Neovim to query LSP diagnostics - Returns diagnostics Usage notes: - IMPORTANT: ALWAYS run this tool immediately after creating or editing ANY file, without exception, passing the files you created/edited. This is mandatory for all file operations. - This tool checks for workspace lint warnings/errors and allows you to address them proactively. - If lint warnings/errors appear from files you did not create/edit, ask the user if they want you to fix those files at the end of the tasks you were given. - If you fixed a lint error and recheck with the read-lints tool and get the same error, tell the user to reload the file in their nvim client. - When the user asks to run lint checks or run lint tool, do not use this tool. However if the user asks to fix the lint errors, or fix the lint errors in a file, then use this tool.
Description conflates tool documentation with LLM instruction guidance. The description includes 8 distinct 'Usage notes' (ALWAYS run after editing, check workspace lint, ask user, reload file, etc.) that should be in separate system prompts or agent guidelines, not embedded in the tool description itself. This wastes tokens and reduces clarity of WHAT the tool does vs HOW an agent should use it.
Parameter descriptions are missing or minimal. The 'workspace' parameter has a basic description ('Absolute workspace path') but no guidance on format, validation, or what happens if missing. The 'files' parameter description ('List of absolute file paths to refresh diagnostics for, if empty, fallsback to refreshing changed files via git diff') is functional but doesn't explain the fallback behavior clearly or what 'changed files' means (staged? unstaged? both?).
No output schema documented. The tool description does not specify what fields are returned in the diagnostics response (e.g., file, line, column, severity, message, code). LLMs cannot plan downstream actions or parse results without knowing the response structure. Requires reverse-engineering from code inspection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error handling guidance. The description does not explain what happens if NVIM_LISTEN_ADDRESS is not set, if Neovim is unreachable, if a file path is invalid, or if git diff fails. LLMs are left guessing on recovery actions.
No state-change declaration. The tool is read-only, but the description does not explicitly say 'This tool does NOT modify files or LSP state' or 'This tool is safe to retry'. Agents need explicit permission to retry without risk.