Loading ToolBench
Unified Model Context Protocol interface to the entire Cortex construction company with intelligent routing to UniFi, Proxmox, Wazuh, and Kubernetes
Scoring was not performed
cortex_ask violates Single Responsibility and Multi-Tool Composition patterns. It combines read (query pods, check security), write (scale deployments, restart pods), and destructive operations (kill processes, remove users) into a single opaque tool with a free-form string parameter. This forces LLMs to reason about system access at invocation time rather than tool selection time, and prevents granular permission gating.
cortex_ask input parameter 'request' is a single untyped string with no schema constraints, enums, or format specification. The description mixes read and destructive operations without distinguishing them, violating the Command Tool and Confirmation Request patterns. LLMs cannot determine if a call is safe to retry or if it has side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 19 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
cortex_ask description grants the agent 'full administrative access' including permission to 'TAKE ACTION: Remediate security issues, kill processes, remove users' without any mention of permission checks, audit logging, confirmation requirements, or scope declarations. This violates the Security, Permission Gate, Audit Trail, and Scope Declaration patterns. No governance mechanism is visible.
cortex_create_task description is 309 characters and mixes intent (what it does), use cases (deployment, services, parallel operations), and implementation details (master agents, categorization). The description conflates tool selection guidance with operational context. Parameter descriptions for 'category' list valid enums (development, security, infrastructure, inventory, cicd, general) but provide no guidance on which category maps to which class of work.
cortex_create_task 'metadata' parameter is documented as 'Optional additional metadata' with no description of what keys are valid, how they are used, or what structures are expected. This invites LLM hallucination and silent failures if invalid metadata is passed.
No output schemas are documented for any tool. cortex_create_task returns a task ID but the schema, format (UUID? string? int?), and whether it can be immediately passed to cortex_get_task_status are not specified. cortex_get_task_status is documented to return 'status, progress, and results' but the structure is not defined, are these nested objects? What format is 'results'? LLMs cannot plan downstream calls without this information.
No error handling, recovery guidance, or error categorization is visible in the provided code. If cortex_get_task_status is called with an invalid task_id, the response is not documented, does it return a 404? Does it suggest valid task IDs? Does it advise the LLM to call cortex_create_task instead? No recovery path is specified.
cortex_create_task 'priority' parameter defaults to 'medium' but there is no documentation of what 'medium' means operationally, how it affects task processing latency, or whether tasks with different priorities are queued together or separately. Without operational semantics, LLMs cannot reason about priority tradeoffs.
cortex_get_task_status has no documentation about polling intervals, timeout behavior, or what states a task can be in (queued, running, completed, failed, cancelled). Without this, LLMs cannot reason about expected latency or design retry logic.
cortex_ask description mixes multiple backend systems (Sandfly, kubectl, UniFi, Proxmox) and operations without any indication of which are available, how to query them, or how errors are surfaced if a subsystem is unavailable. An LLM cannot reason about service boundaries or graceful degradation.
Tool names cortex_create_task, cortex_get_task_status, cortex_ask are prefixed with 'cortex_' which is redundant (the server is already Cortex) and adds 7 characters of noise. Prefer create_task, get_task_status, and a more specific action verb than 'ask' (e.g., execute_infrastructure_command, orchestrate_operation).