Loading ToolBench
Tamper-evident audit trail MCP server for EU AI Act and GDPR compliance
EU Audit MCP demonstrates solid compliance-focused design with strong regulatory awareness (EU AI Act, GDPR). All 10 tools have clear descriptions and complete input schemas. Naming follows verb-noun patterns consistently (log_*, query_*, get_*, verify_*, execute_*). Parameter descriptions are generally good (explain purpose, include constraints). However, several tools lack output schema documentation in code, error handling guidance is minimal, and some descriptions could be more specific about LLM-relevant context (when to call, failure modes). The server excels at its narrow compliance domain but shows gaps in production-grade agent tooling patterns like recovery guidance, actionable errors, and result pagination documentation.
Run a technical compliance check against EU AI Act and GDPR. Checks: EU AI Act Art. 12 — Record-keeping (event logging), EU AI Act Art. 19 — Automatically generated logs (retention, integrity), GDPR Art. 30 — Records of processing activities (purpose, PII categories).
Execute a GDPR Article 17 right-to-erasure request. Redacts event content and removes PII vault entries for the specified entity. The events themselves are kept (to preserve the hash chain for EU AI Act Art. 19 integrity) but their content is replaced with a redaction notice. The erasure itself is logged as a gdpr_erasure event.
Get a summary of PII types detected across all logged events. Returns only counts per entity type, never actual PII values.
Get the full ordered trace of a specific session.
Get summary statistics for the audit log.
Log a document or data access event for audit purposes.
Output schemas undocumented in code for most tools. While docstrings mention return fields, there is no formal JSON Schema definition visible. LLMs cannot parse unstructured descriptions of outputs reliably.
Destructive tool (execute_erasure) lacks confirmation/dry-run pattern. 'IRREVERSIBLE' risk is noted in the input schema but no actual confirmation step or dry_run parameter exists in the tool definition. This violates safety best practices for agent-operated destructive operations.
Error handling and recovery guidance are absent. Tools do not document what errors can occur (e.g., invalid session_id, out-of-range timestamps, PII vault corruption) or how agents should respond. Descriptions lack phrases like 'If session not found, try...' or 'Returns error X if...'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Record an audit event. PII in content is automatically detected and redacted before storage.
Log an LLM inference call for audit purposes.
Search the audit log with optional filters.
Verify the HMAC-SHA256 hash chain integrity of the audit log.
Pagination limits documented in query_log (max 10000) but no guidance on what happens when results exceed limit or how to fetch next page. Return schema does not mention next_cursor or total_count fields needed for proper pagination UX.
query_log and related search tools do not restrict result sizes in descriptions. While limit defaults to 50, no warning about returning 10,000 events and impact on token cost / LLM reasoning quality.
Compliance check tool returns undocumented structure. Description lists regulatory checks performed but does not explain what the output looks like (JSON? Boolean? Detailed violations?). LLMs cannot plan recovery if they don't know success/failure schema.