Loading ToolBench
MCP server for F5 Cloud Status monitoring with fully automated CI/CD
Server has 6 well-structured tools with clear naming and consistent input schemas. All tools use verb_noun naming convention (f5-status-get-*, f5-status-search). Descriptions are present and adequate (average ~130 chars, within baseline 10-1024 range). Schemas are properly typed JSON objects with enumerated constraints on key parameters. However, several critical gaps reduce the score: (1) Output schemas are NOT documented, LLMs cannot see what fields to expect from these tools; (2) Parameter descriptions are minimal, status, impact, days params lack format/range guidance beyond min/max; (3) Error handling guidance is absent, no recovery hints for network/API failures; (4) No idempotency markers or destructive operation safeguards despite READ_ONLY risk designation; (5) Tool composition could be improved, search tool is overloaded (accepts 'all' enum for type parameter, conflating separate concerns).
Get detailed information about a specific F5 Cloud service component by ID or name
Get all F5 Cloud service components with their current operational status, organized by category (Distributed Cloud Services, XC App Stack, etc.)
Get current and recent incidents affecting F5 Cloud services, including status updates and affected components
Get scheduled, active, and upcoming maintenance windows for F5 Cloud services
Get the current overall status of F5 Cloud services including operational state and service health indicator
Search F5 Cloud status information by keyword or pattern, including components, incidents, and maintenance
Output schemas not documented. Tool descriptions say what the tools return in prose (e.g. 'Get all F5 Cloud service components') but do not provide structured JSON Schema for response fields. LLMs cannot determine what fields exist in the response or plan downstream tool calls.
Parameter descriptions lack actionable format/range guidance. 'days' parameter has min/max constraints (1-90) in schema but description only says 'Get incidents from the last N days (default: 7)', LLM must infer the valid range from schema. Similarly, 'status' and 'impact' have enums but descriptions do not explain what each enum value means (e.g., does 'critical' mean all services down, or just one component?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No error recovery guidance. Tools have no error handling documentation. If a tool call fails (network error, API rate limit, malformed input), the server provides no hints for the LLM on what to do next. Missing pattern: 'If unable to reach F5 status page, check network connection or try again in 60 seconds.'
Search tool combines multiple concerns. 'f5-status-search' accepts type=('components'|'incidents'|'maintenance'|'all'), making it overloaded. Type='all' makes the tool a catch-all rather than a focused operation. Better design: split into search_components, search_incidents, search_maintenance (each focused on one resource type), or document what 'all' actually searches and in what order.
get-component tool has no required parameters. 'id' and 'name' are both optional, but the Zod schema refines with 'Either id or name must be provided'. The JSON Schema inputSchema does not enforce this constraint, LLM sees no required fields and may call the tool with neither parameter, leading to ambiguous behavior.
No tool annotations (readOnlyHint, idempotentHint) despite all tools being READ_ONLY. Server declares tools risk='READ_ONLY' but does not use MCP tool annotations to communicate idempotency and side-effect-free nature to the client, forcing the client to infer from tool names and descriptions.