Loading ToolBench
MCP server that exposes NVIDIA GPU metrics and monitoring capabilities
Four read-only GPU monitoring tools with clear naming and basic schemas. Tool names follow verb_noun pattern (list_gpus, get_gpu_metrics, gpu_summary, get_gpu_processes). All tools have descriptions (34-89 chars, within baseline range). Input schemas present with type definitions for all parameters. However, parameter descriptions are minimal (10-40 chars), falling short of the 72-char baseline. Output schemas documented via Go struct tags but lack depth in field descriptions. No error handling guidance, tools return raw errors without recovery hints. Missing tool annotations (readOnlyHint) despite all being read-only operations.
Get detailed metrics for a specific GPU by index or UUID
List processes using GPU resources, optionally filtered by GPU index or UUID
Get aggregate GPU statistics across all devices on this node
List all NVIDIA GPUs on this machine with utilization and memory info
Parameter descriptions are minimal (10-40 chars vs 72-char baseline). 'GPU device index (0-based)' and 'filter by GPU device index (0-based)' lack context on valid ranges, error cases, or when to use index vs UUID.
No error handling guidance. getMetrics() returns 'provide either index or uuid' but does not guide LLM on recovery. No structured error classification (retryable vs user-fixable).
Missing tool annotations. All four tools are read-only but lack readOnlyHint annotation in mcp.Tool definition. Agents cannot infer safety from tool metadata.
Output schema documentation relies on Go struct tags (jsonschema) rather than explicit JSON Schema in tool registration. LLMs cannot inspect output structure from tool metadata alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Mutually exclusive parameters (index vs uuid in get_gpu_metrics and get_gpu_processes) not clearly documented as such. LLM may pass both, causing ambiguous behavior.