Loading ToolBench
Zero-Trust Cybersecurity Command Center for SOC triage, penetration testing, malware analysis, and anomaly detection with task queuing and threat logging
This MCP server exhibits significant quality gaps across naming, descriptions, schemas, and error handling. While it has 3 tools with some basic structure, multiple critical issues prevent production use. Tool names are somewhat descriptive (deploy_task, task_status, login) but lack verb-noun clarity conventions. Descriptions exist but are short and lack critical details about when to use each tool, what prerequisites exist, or how they chain together. Input schemas are present but incomplete, parameters lack type specifications beyond basic strings and objects. Output schemas are entirely undocumented. Error handling is minimal with no recovery guidance. The server appears to be HTTP-based (FastAPI + Uvicorn), which is positive for protocol readiness, but the definitions themselves fall well below production standards.
Queue a cybersecurity task (soc_triage, pentest, malware_scan) on a specified target with rate limiting and zero-trust authorization
Authenticate and obtain a JWT bearer token for subsequent API requests
Retrieve the status and result of a queued cybersecurity task by task ID
Output schemas completely undocumented. LLMs cannot predict what fields or types will be returned, forcing parsing of unstructured responses and increasing hallucination risk.
Parameter 'params' in deploy_task is a bare object with no field documentation. Downstream LLM and tools cannot infer valid keys. Should be replaced with explicit parameters or a constrained enum of allowed keys.
Celery task statuses (PENDING, STARTED, SUCCESS, FAILURE, RETRY, REVOKED) are not enumerated in task_status description or schema. LLM must guess interpretation of status field.
No recovery guidance for error cases. HTTPException responses (401, 403, 404) return generic error messages without suggesting next steps. Should include 'Try login first' or 'User may not have task:write permission'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Credentials in source code. Backend hardcodes admin/securepass for auth validation. Code should read from environment variables or a secure database.
No idempotency guarantees documented. deploy_task queues a Celery job, if the LLM retries the same call due to ambiguous failure, will it create duplicate tasks?
Tool descriptions lack WHEN/WHY guidance. deploy_task says it 'queues a cybersecurity task' but doesn't explain when to use soc_triage vs pentest vs malware_scan, or what the expected runtime is.
deploy_task description mentions 'zero-trust authorization' but the tool definition does not expose permission/scope parameters. Scopes are checked server-side (tasks:write), but LLM cannot reason about missing permissions before calling the tool.