Loading ToolBench
Model Context Protocol server for systemd service, timer, and journald log monitoring on Linux systems
Strong foundation with clear, verb-based tool names and detailed descriptions. All 6 tools have explicit schemas with typed parameters and descriptions. However, some parameter descriptions lack constraints (enums, ranges), output schemas are not documented, and error handling guidance is absent. The macro-based tool registration (via rust_mcp_sdk macros::mcp_tool) is visible and properly structured. Tool names follow verb_noun convention (list_*, get_*). Descriptions are concise and actionable, ranging 80-220 chars. Parameter types are declared via JsonSchema derive macros. No critical security issues detected, all tools are read-only with credential redaction where needed (get_container_status, get_pod_status).
Inspect one local Podman container using a read-only bounded CLI call. Commands and health checks are credential-redacted; raw create commands and host mount sources are omitted.
Inspect one local Podman pod using a read-only bounded CLI call.
Inspect one systemd service with direct dependency failures and recent transitions.
List journald logs with filters and bounds. Optional filters must be omitted when unset: do not send priority=".*" for all priorities, and do not send unit="" for all units. priority accepts journald severity thresholds 0-7 and aliases: emerg, alert, crit, err, warning, notice, info, debug. Use grep for message substring or regex-lite matching. start_utc is required unless since_last_start=true; when since_last_start=true, omit start_utc and provide exactly one unit.
List systemd service units and current state. Optional filters should be omitted when unset. scope accepts system, user, or both and defaults to system. state accepts active, inactive, failed, activating, deactivating, or reloading. limit accepts 1-1000 and defaults to 200.
Output schemas not documented. While input schemas are explicit via JsonSchema derives, tool responses lack documented output structure. LLMs cannot predict what fields to expect (e.g., does list_services return 'state' or 'status'? Is timestamp included?). This forces trial-and-error iteration and breaks downstream tool chaining.
Parameter constraints inlined in descriptions rather than formalized as JSON Schema enums/patterns. 'scope accepts system, user, or both' and 'priority accepts 0-7 or emerg, alert, crit...' are readable to humans but not machine-parseable. LLMs cannot reliably extract valid options from prose. Should declare enums in schema.
Error handling and recovery guidance absent. No documented error scenarios, recovery suggestions, or actionable failure messages. If list_logs fails with an invalid time range, what should the LLM do next? Current code returns json_rpc_invalid_params but offers no guidance on what makes params valid.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 58 | 2024-11-05+ | v1 |
List systemd timer units and scheduling/trigger state. Optional filters should be omitted when unset. scope accepts system, user, or both and defaults to system. state is a non-empty active-state filter. sort accepts next, last, name, or state and defaults to name; order accepts asc or desc and defaults to asc. limit accepts 1-1000 and defaults to 200.
Conditional parameter logic not clearly documented. list_logs requires start_utc UNLESS since_last_start=true, in which case start_utc must be omitted and exactly one unit must be provided. This is stated in the description but is dense and easy to misparse. Mutually exclusive parameters should be called out separately or split into distinct tools.
Pagination not documented for list_* tools. list_services, list_timers, and list_logs accept a 'limit' parameter (defaults to 200, max 1000) but the response structure is not documented. Is there a cursor or next_page field? Can the agent ask for the next batch? Without documented pagination, large result sets may be truncated silently.
Tool annotations (readOnlyHint, idempotentHint, destructiveHint) absent. While all tools are read-only (appropriate for a monitoring server), the schema does not declare this. Per MCP spec 2026-07-28, read-only tools should include readOnlyHint=true to help clients optimize caching or avoid unnecessary confirmation prompts.