Loading ToolBench
Model Context Protocol Server for Uyuni Server - manage mixed Linux systems, groups, patches/updates, and scheduled actions via API tools
The MCP server defines 2 tools with clear action verbs (list_, get_) and reasonable descriptions. Both tools have input schemas with types and descriptions. However, there are notable gaps: parameter descriptions could be more detailed (e.g., what constitutes a 'system_identifier' in practice), output schemas are not explicitly documented in the code, and error handling guidance is minimal. The descriptions are moderately detailed (tool-level ~150-200 chars) but lack recovery hints and dependency information. Tool composition is appropriate (single responsibility), but the server lacks error categorization, actionable error messages, and confirmation mechanisms for read-only operations.
Get details for one system. Inputs: `system_identifier` (`system_name` or `system_id`). Name not found: resolve with `find_systems_by_name`, then pass `system_id`. Returns: `system_id`, `system_name`, `last_boot`, `uuid`, `cpu`, `network`, `installed_products`. Use system_id when possible.
List active systems in Uyuni/MLM. Inputs: optional `limit`, `offset`. `limit` is capped at 500. Returns: `items` with active systems (`system_name`, `system_id`) and `meta`. Note: use `system_id` for other system tools.
Output schemas not documented in code. Tools describe return fields in prose (e.g., 'Returns: `items` with active systems (`system_name`, `system_id`) and `meta`') but do not expose JSON Schema for response structure. LLMs cannot validate response structure or plan downstream tool calls reliably.
Error handling lacks recovery guidance and categorization. No evidence in code of custom error messages that tell the LLM what to do next (e.g., 'System not found. Try list_systems() to see available systems.'). Errors appear to be generic exception handling without actionable guidance.
Parameter descriptions could be more detailed. 'system_identifier' description says 'system_name or system_id' but does not state format constraints, length limits, or when to use each. 'limit' description lacks explicit upper-bound clarification in the description text itself (relies on 'capped at 500' note).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No dependency hints in descriptions. get_system_details note says 'If name not found, resolve with find_systems_by_name' but find_systems_by_name is not in the tool list. The actual recovery path (use list_systems and match on system_name) is implied but not explicit.
Response field naming consistency unclear. The description for list_systems mentions 'system_name' and 'system_id' as return fields, while get_system_details returns 'system_id', 'system_name', and additional fields. Without seeing the actual response schema, LLMs cannot reliably extract or chain results.
No explicit pagination guidance in list_systems description. While limit and offset are present, the description does not clarify whether there is a total_count or next_cursor field, or how to detect the end of results. This forces LLMs to guess pagination behavior.