Loading ToolBench
Java Performance Analysis & Diagnostics - LLM-powered MCP Server for real-time monitoring, memory analysis, thread profiling, and system optimization
This server has moderate structural issues. Tool names follow verb_noun conventions (connect_arthas, get_jvm_info, trace_method), which is good. However, descriptions are present but vary widely in quality and length. Most critically, parameter descriptions exist but are sometimes generic or translated from Chinese without full clarity for English-speaking LLMs. Input schemas are visible and properly typed with JSON Schema, but lack depth in constraints (no enums for restricted values, no explicit min/max for numeric parameters). No output schemas are documented, LLMs cannot plan downstream calls or know what structure to expect from responses. Error handling is basic (generic 'error' status returns). The tools themselves are somewhat single-purpose (good for composition), but several lack idempotency guarantees and none declare permissions or security posture.
连接到 Arthas http api
断开 Arthas 连接
执行自定义性能分析命令 - 灵活执行各种Arthas性能诊断命令
获取当前连接状态
获取JVM性能信息和系统状态 - Java应用性能分析基础
内存性能分析 - 诊断内存泄漏、OOM、GC压力等性能问题
线程性能分析 - 诊断线程阻塞、死锁、CPU占用等性能问题
方法性能追踪 - 分析方法调用链和执行耗时，定位性能瓶颈
No output schemas documented for any tool. LLMs cannot plan downstream calls or know what fields to expect in responses. This violates the critical 'Document the output schema' rule and forces LLMs to guess at response structure.
Tools with empty input schemas (get_connection_status, disconnect_arthas, get_jvm_info, get_memory_info) lack explicit input documentation.
No input validation or enum constraints. execute_arthas_custom_command accepts a free-form string 'command' with no validated list of valid Arthas commands. Numeric parameters (thread_id, count in get_thread_info; count in trace_method) lack min/max bounds, LLMs could pass absurd values (count=999999) that break the API or timeout.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool descriptions vary in quality. 'get_connection_status' has a 24-character description ('获取当前连接状态'), which is at the floor of the acceptable range (10-1024 chars) and provides minimal LLM guidance on when/why to call it.
Error handling is generic. All tools return a flat {'status': 'error', 'message': '...'} structure. There is no error classification (retryable, user-fixable, fatal), no recovery guidance, and no invalid value + constraint feedback. Per pattern:recovery-guide, errors should tell the LLM what to do next.
No permission gates or scope declarations. Tools like execute_arthas_custom_command and trace_method have no documented permission requirements (e.g., 'requires read:jvm' or 'requires write:trace'). This violates pattern:scope-declaration.
No idempotency guarantees declared. Tools like trace_method and execute_arthas_custom_command do not document whether they are idempotent. Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects (e.g., multiple trace invocations).
Parameter count_parameter in trace_method has a description mentioning 'default 3 times, recommend 3 times' but the schema default is 3, this is redundant and suggests the description was not refined for clarity. Similarly, async_mode defaults to true but the description says 'recommend false', the default contradicts the recommendation.