Loading ToolBench
MCP server for GDPR privacy compliance and DSAR management — open-source alternative to Transcend. Manage data subject access requests, check GDPR compliance, and maintain Article 30 data inventories.
Server has 7 well-named tools with complete descriptions and documented parameters. All tools follow verb_noun naming (create_dsar, list_dsars, etc.). Descriptions are detailed (100-250 chars) and explain WHAT, WHEN, and GDPR context. Parameters have types and descriptions. However, critical gaps: (1) No enum constraints on string parameters like 'request_type', 'status', 'urgency', 'legal_basis', LLMs will hallucinate invalid values. (2) Output schemas are not documented, callers don't know what fields to expect. (3) No error handling guidance, tools return dicts but no recovery instructions. (4) tool_data_inventory conflates two actions ('list' vs 'add') in one tool, violating single-responsibility. (5) No pagination documented for list_dsars despite potentially large result sets. Baseline: avg tool description 194 chars (this server ~150 chars, acceptable); avg params 4 (this server 2-10, reasonable); 100% of A+ tools have documented return types (this server has 0%).
Analyze a data processing description for GDPR compliance issues. Checks against 15 real GDPR rules (Articles 5-35) and returns a compliance score (0-100), grade (A-F), specific issues with severity levels, and actionable recommendations.
Create a new Data Subject Access Request (DSAR). Registers a GDPR request with automatic 30-day deadline tracking. Types: access (Art. 15), deletion (Art. 17), rectification (Art. 16), portability (Art. 20), objection (Art. 21), restriction (Art. 18).
Register or list data processing activities (Article 30 GDPR). Action 'list': Show all registered processing activities. Action 'add': Register a new processing activity with required fields. Legal bases: consent, contract, legal_obligation, vital_interests, public_interest, legitimate_interest.
Get detailed status of a specific DSAR including deadline warnings. Returns the DSAR details, applicable GDPR article, urgency level, days remaining, and deadline warnings.
Get a comprehensive privacy compliance dashboard. Overview of: open DSARs, overdue requests, upcoming deadlines, compliance score, data inventory stats, and prioritized action items. Perfect for daily privacy officer briefings.
No enum constraints on string parameters. 'request_type' accepts free-form strings (should be: access|deletion|rectification|portability|objection|restriction). 'status' (received|verified|in_progress|completed|rejected), 'urgency' (overdue|critical|high|medium|low), 'legal_basis' (consent|contract|legal_obligation|vital_interests|public_interest|legitimate_interest) all lack enums. LLMs will hallucinate invalid values.
Output schemas not documented. Tools return dicts but callers don't know field names, types, or structure. E.g., tool_list_dsars returns what? Array of DSAR objects? Each with which fields? tool_check_gdpr_compliance returns compliance_score, grade, issues, but format unknown. LLMs cannot plan downstream calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
List all DSARs with optional filters, sorted by urgency. Overdue and critical requests appear first. Filter by status (received, verified, in_progress, completed, rejected), type (access, deletion, etc.), or urgency (overdue, critical, high, medium, low).
Update a DSAR's status or add a processing note. Status transitions: received → verified → in_progress → completed/rejected. Notes are timestamped and appended to the DSAR history.
tool_data_inventory violates single-responsibility: action='list' vs action='add' are two distinct operations. Should split into list_data_inventory and add_data_inventory. Combined tools confuse LLMs about when to call and what to expect.
No error handling guidance. Tools return dicts but no documentation of error cases, recovery steps, or actionable messages. E.g., if DSAR not found, does it return null, an error dict, or raise? If legal_basis is invalid, what happens? LLMs need explicit error classification (retryable, user-fixable, fatal).
No pagination documented for list_dsars. If many DSARs exist, result could be huge. Should accept limit and offset/cursor parameters and return total_count. Current tool offers no way to handle large datasets.