Loading ToolBench
This MCP server defines 4 tools with visible schemas and descriptions, but has significant quality gaps across naming, description depth, and error handling. All tools are READ_ONLY, which is appropriate, but the descriptions lack actionable context for LLM selection. Parameter descriptions are minimal (1-2 sentences), and error handling is absent from tool definitions. The server exhibits moderate maturity, schemas are present and mostly complete, but descriptions fall short of production baselines (194-char average; these average ~80 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared in code despite all tools being read-only. The Chinese descriptions are clear in intent but do not follow LLM-optimized English patterns (e.g., no dependency hints, no WHEN to use guidance).
分析 Sonar 项目并获取所有待解决的问题。支持通过项目 URL 或项目 Key 来获取问题列表。
批量分析项目中的所有问题，按严重程度和类型分类，并生成修复优先级报告。
获取特定 Sonar 问题的详细信息，包括代码位置、问题描述和建议的修复方案。
根据 Sonar 问题类型，生成自动修复建议和代码补丁。
Tool descriptions lack LLM guidance on WHEN to use each tool and dependencies. 'Analyze Sonar project' vs 'Get issue details', not obvious which to call first or when each is appropriate.
No error guidance or recovery paths in tool definitions. If auth fails (401), suggestion_fix handler calls sonarClient.getIssueDetails, but no try-catch or error message guides the LLM what to do next.
Naming ambiguity: 'suggest_fix' is vague, does it generate multiple suggestions, apply a fix, or just analyze? 'generate_fix_suggestion' or 'recommend_fix_for_issue' would clarify intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Parameter 'token' marked optional but treated as critical in error_handler.ts (SonarAuthError), LLMs won't know auth will fail if token is omitted. Description should warn: 'Required if accessing private projects; omitting may cause 401 errors.'
No tool annotations declared. All 4 tools are read-only, but code does not set readOnlyHint=true in tool registration. This deprives the agent of metadata needed to optimize planning.
Parameter descriptions lack format/range guidance. 'url' parameter: no guidance on expected format (https://sonar.devops.com.cn/dashboard?id=KEY vs https://sonar.devops.com.cn). 'severity' enum has 5 values but no guidance on priority or filtering behavior.
Output schemas not documented in code. Handler functions return {content: [{type: 'text', text: JSON.stringify(...)}]} but do not document what fields the LLM should expect in the parsed response (e.g., from analyze_sonar_project: projectKey, totalIssues, issues[].key, issues[].severity, etc.). LLMs must infer from example.