Loading ToolBench
Client SDK to check agreements and user policies against GDPR/CCPA criteria
This MCP server has a single tool with severe definition quality issues. The tool is not actually registered as an MCP tool, no MCP server implementation is visible in the source code. The code shows only a Python class `ComplianceAuditClient` with an `audit_policy` method, with no MCP protocol integration (no stdio transport, no tool registration via MCP SDK, no input/output schema wrapping). The tool definition is inferred from the README and example usage, not explicitly registered. The schema provided in the submission is partially specified but lacks rigor. The description is generic (39 characters) and does not follow prompt-engineering best practices. Input parameters lack validation constraints and enums. The output schema is undocumented, only a Python dict structure visible, not formally specified JSON Schema. Error handling is absent. This is a pre-MCP implementation that would require significant work to become a production MCP server.
Scans policy text for essential regulatory keyword blocks.
Tool is not registered as an MCP tool. No MCP server implementation (SDK usage, tool registration, transport binding) is visible in the source code. Only a standalone Python class exists.
Tool description is too short (39 chars, under 10-word minimum) and lacks context. Does not explain WHEN to use this tool vs. other compliance checkers, WHAT prerequisites exist, or explicit statement that it scans text (read-only operation).
Input parameter 'regulations' is an array of strings with no enum constraint. LLM will hallucinate invalid regulation names (e.g., 'HIPAA_2024_v3'). Should declare enum: ['GDPR', 'CCPA', ...] or accept only known regulation codes.
Output schema is undocumented. The method returns a dict with nested structure (compliance_status → is_compliant, missing_clauses, suggested_clauses), but no formal JSON Schema is provided. LLMs cannot plan downstream tool calls without knowing output structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 24 | 2026-07-28+ | v2 |
No error handling visible. What happens if policy_text is empty, or regulations array is empty? How does the tool fail gracefully? No error responses, recovery guidance, or categorization (retryable vs. fatal).
Parameter 'policy_text' lacks validation constraints. No length limits, no encoding specification, no guidance on format (plain text, HTML, markdown). LLM may pass binary data or multi-megabyte documents without bounds.
Hardcoded compliance rules (keyword matching for 'right to be forgotten', 'delete my data') are brittle and non-extensible. No way for agent to add custom clauses or regulations. Tool is domain-specific without configurable policy rules.
Tool description claims to scan for 'essential regulatory keyword blocks' but implementation only checks for a handful of hardcoded phrases. Misleading description suggests broader compliance checking than actually implemented.
No input schema for policy_text parameter. While the submission provides a description field, there is no minLength, maxLength, or pattern constraint. A bare 'string' type invites unbounded or malformed input.