A small, dependency-free prompt-injection screening and defense library providing heuristic detection, sanitization, and output validation for prompt injection attacks.
Scoring was not performed
No output schemas documented. Tools return complex objects (SecurityResult with is_safe, threats list, confidence score) but agent has no way to know what fields to expect or how to compose downstream calls.
Parameter descriptions are minimal. 'The text to analyze for prompt injection threats' is only 57 chars and lacks constraint information (min/max length, encoding expectations, or what constitutes 'threats'). LLM cannot validate input before calling.
Tool descriptions lack WHEN to use guidance. 'Detect prompt injection threats' does not explain: when should detect be called vs sanitize vs validate_output? What's the difference? Are they meant to be called in sequence? Dependencies are undocumented.
Error handling is absent from tool definitions. 'Raises SecurityError' is mentioned in sanitize and validate_output descriptions but no guidance on recovery, retry logic, or what the LLM should do next. SecurityError is not MCP-compliant error reporting.
sanitize tool has unclear semantics. Description says 'Sanitize input by removing or replacing potentially dangerous patterns', but what patterns? Removed text is lost; no confidence score or explanation of what was found. Returns string (inferred) not structured result.
validate_output parameter named 'output_text' but detect uses 'text'. Inconsistent naming forces LLM to reason about parameter mappings. Should be 'text' across all tools.
No idempotence guarantee. If detect is called twice with same text, does it return identical results? Source shows caching in PromptInjectionDetector but MCP tool definition does not declare idempotentHint. Agent cannot safely retry without knowing if side effects occur.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |