Loading ToolBench
MCP server providing secure file operations with prompt injection detection, API key validation, and human-in-the-loop approval gates
Strong foundation with comprehensive tool coverage, detailed descriptions (avg 250+ chars), and complete input schemas with proper typing. All 11 tools have descriptions and structured schemas. Tool annotations present (readOnlyHint, destructiveHint, idempotentHint). However, output schemas are not formally documented, responses are inferred from code rather than declared in tool definitions. Error handling guidance is minimal. Parameter descriptions are solid but some lack constraint details (e.g., timeout_seconds range is declared but not all numeric params have bounds). Naming is clear and verb-forward (secure_read_file, secure_write_file, etc.). No critical security issues detected, secrets are not exposed as parameters.
Mark a security alert as acknowledged.
Approve or deny a pending approval request.
Check the status of a pending approval request.
Retrieve security alerts with optional filtering by severity and acknowledgment status.
Query the audit log with optional filters for operation type, time range, and security events.
Request human approval for a sensitive operation.
Scan text content for prompt injection patterns and optionally quarantine if detected.
Output schemas not formally documented. Tool responses are inferred from code (e.g., success/metadata/content fields) but not declared in tool definitions. LLMs cannot reliably predict response structure for downstream planning.
Error handling lacks recovery guidance. Tools return errors (e.g., 'File read failed', 'Blocked') but do not suggest next steps. LLMs cannot self-correct without explicit guidance like 'Try set_access_policy() to allow this directory'.
Approval workflow is stateful and undocumented. secure_write_file returns approval_id, but the mechanism for tracking approval state across calls is not visible in the provided code. Stateful patterns conflict with MCP's stateless design.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
Securely read a file with injection scanning and access policy enforcement. This tool reads files while: - Checking against configurable access policies (allowed/blocked directories) - Scanning content for prompt injection patterns - Detecting sensitive data (PII, credentials, API keys) - Logging all access attempts for audit Args: - path (string): Absolute or relative path to the file - scan_for_injection (boolean): Whether to scan for injection patterns (default: true) - response_format ('markdown' | 'json'): Output format (default: 'markdown') Returns: Success: File content with metadata and injection scan results Blocked: Error with reason why access was denied Security Features: - Blocks access to sensitive directories (.ssh, .env, etc.) - Detects and flags prompt injection patterns - Quarantines critical-risk content - Creates security alerts for suspicious patterns Example use cases: - Reading configuration files safely - Processing uploaded documents with injection protection - Accessing files while maintaining audit trail
Securely write content to a file with approval gates and injection scanning. This tool writes files while: - Enforcing access policies - Scanning content for injection patterns - Requiring human approval for sensitive operations - Maintaining audit trail Args: - path (string): Path for the file to write - content (string): Content to write (max 10MB) - require_approval (boolean): Whether to require human approval (default: true) - response_format ('markdown' | 'json'): Output format Returns: If approval required: Returns approval_id to use with approve_operation If approved/not required: Writes file and returns metadata If blocked: Returns error with reason Workflow: 1. Call secure_write_file with require_approval=true 2. Get approval_id from response 3. Human reviews and calls approve_operation 4. If approved, call secure_write_file again (approval tracked internally)
Configure file access policies including allowed/blocked directories and patterns.
Validate that an API call destination matches the authenticated user's credentials. This is the key mitigation for the Files API exfiltration attack described in the article. It checks whether a destination API key matches the source (authenticated) key. Args: - destination_url (string): The API endpoint URL being called - destination_api_key (string, optional): API key for the destination - source_api_key (string, optional): Authenticated user's API key - response_format ('markdown' | 'json'): Output format Returns: - isValid: Whether the API call should proceed - mismatch: True if keys don't match (potential exfiltration) - reason: Explanation of the validation result Use this before any external API calls that handle sensitive data.
Minimal parameter constraint documentation. Numeric params (timeout_seconds, limit, offset, max_file_size_mb) have ranges in schema but descriptions lack explicit constraint text. LLMs may not parse JSON Schema bounds reliably.
Pagination support incomplete. query_audit_log and get_security_alerts accept limit/offset but do not document total count or next_cursor in response. LLMs cannot determine if more results exist without calling again.