Loading ToolBench
A Java MCP server that provides runtime introspection and profiling tools for JVM applications, including debugging, instrumentation, and performance profiling capabilities.
Scoring was not performed
Output schemas not documented. No tool returns structured output specs visible in definitions. Agents cannot know what fields to expect from responses (e.g., what does project_list return? Does it include build system info? Project IDs?). Forces agents to infer or guess structure.
Parameter descriptions lack guidance on ranges, formats, and when to use optional overrides. Example: timeoutMs appears in 7 tools but no description explains the valid range (1-300000ms?), default behavior, or retry semantics. baseUrl is repeated across tools without explaining when to override defaults.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 21 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter dependencies undocumented. probe_recipe_create accepts classHint, methodHint, lineHint, and projectId but does not explain whether all are required together, mutually exclusive conditions, or fallback logic. target_infer has similar hints but no dependency matrix. Agents must guess correct combinations.
probe_get_status and probe_reset accept either 'key' (single string) OR 'keys' (array) but descriptions do not clarify this mutual exclusivity or preferred usage. Agents may pass both or neither, causing undefined behavior.
Error handling not described. No tool description explains what errors are possible, when they are retryable, or what the agent should do next (e.g., if probe_check fails, should the agent retry, adjust baseUrl, or ask the user?). This violates the recovery-guide pattern.
Credentials exposed as parameters. probe_recipe_create accepts authToken, authUsername, and authPassword as optional input parameters. These should never appear in tool parameters, they should be injected server-side via environment variables or secure vaults. Agent traces log all parameters, leaking secrets.
Pagination and result limits not enforced. project_list accepts maxProjects (1-200) and maxJavaFilesPerProject (10-2000), but no description explains the default values or what happens if limits are exceeded. A 200-project scan could explode token usage. No explicit guidance on when to page or how pagination works.