MCP server exposing CortexGuard incident history and planning tools to operators for real-time multimodal anomaly detection and fault-tolerant AI architecture
CortexGuard MCP server has 6 tools with basic schemas and descriptions, but significant gaps prevent higher scores. All tools have descriptions (10-200 chars range), and input schemas are present with type definitions. However, parameter descriptions are sparse or missing entirely (e.g., 'context' in create_remediation_plan lacks detail), output schemas are undocumented, and error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. The server follows verb_noun naming convention well (get_*, create_*, list_*, record_*), but lacks the depth expected for production-grade agent tooling. Composition is reasonable, tools are single-purpose, but chaining support is unclear (e.g., does list_incidents return incident_id for use in get_incident_details?).
Submit an anomaly event for planning and retrieve the generated remediation plan with confidence score and rationale.
Get detailed information about a specific incident including plan, retrieved similar incidents, and resolution status.
Get the most recent CortexGuard planning incident, use this first when an alert fires to see the decision, plan, rationale, and retrieved similar past incidents with similarity scores.
List recent incidents with optional filtering by device_id, anomaly_key, or severity.
Record the outcome of a remediation plan execution (resolved, escalated_further, hardware_replaced, or aborted).
Validate a plan against the capability registry.
Parameter descriptions are incomplete or missing. 'context' in create_remediation_plan has no detail; 'plan' in validate_plan lacks guidance on structure. LLMs cannot infer parameter meaning from names alone.
Output schemas are not documented. Tools return data but LLMs have no visibility into response structure (fields, types, nested objects). This breaks downstream tool chaining and forces agents to guess field names.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. create_remediation_plan and record_resolution are WRITE operations that should be marked destructiveHint=true to signal irreversibility to agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. No indication of what to do on failure (retry? ask user? escalate?). Errors should categorize as retryable vs. user-fixable and suggest next steps.
list_incidents lacks pagination parameters (limit defaults to unspecified; no offset/cursor). Large result sets will blow context windows. Baseline: paginated tools should accept limit (1 - 100) and offset/cursor.