Loading ToolBench
MCP server for checking German AGB clauses against § 309 BGB mandatory statutory prohibitions
Silent Law MCP demonstrates strong definition quality with well-structured tool descriptions and comprehensive parameter documentation. All 4 tools have clear verb-based names (check_*, explain_*, get_*) and detailed descriptions (194-480 chars, within baseline 34-392 range). Input schemas are explicit with JSON Schema structure, type declarations, and parameter descriptions. However, output schemas are documented only in prose within descriptions rather than as formal JSON Schema structures, and error handling guidance is minimal. Tool composition is excellent, each tool has a single, clear responsibility and tools chain naturally (check_clause → get_substitution, check_contract → explain_prohibition). Security is properly handled with read-only operations and no credential exposure. The extracted_data_json parameter represents a sophisticated domain pattern but could benefit from more explicit validation error messages.
Check a single AGB clause against relevant § 309 BGB prohibitions. The caller (LLM) is responsible for extracting structured data from the clause text using the extraction prompts. This function runs deterministic validators on the extracted data and returns a structured compliance result. Returns JSON with: status (VALID/VOID/NEEDS_REVIEW/INDICATIVE_VIOLATION), violations, substitution rules, and full audit trail.
Full contract analysis with automatic LLM-driven clause extraction and deterministic validation. Accepts raw contract text, auto-extracts and classifies all clauses, then validates each against § 309 BGB.
Return full detail on a specific § 309 prohibition, including statutory text, case law references, and examples.
What the law substitutes for a void clause. Given a void prohibition match and contract context, return the statutory substitution rule under § 306 Abs. 2 BGB.
Output schemas documented in prose only; no formal JSON Schema for response structures. Tools return JSON strings (e.g., status/violations/audit_trail in check_clause) but structure not declared in tool definition.
Error handling lacks structured recovery guidance. JSON decode errors in check_clause return raw error; no suggestions for fixing malformed extracted_data_json. Pattern: 'Invalid JSON', should say 'Extracted data must be valid JSON mapping prohibition IDs to clause data. Check formatting of: {"309_nr_1": {...}}'
Parameter regime accepts string values but no enum constraint declared in schema. Description lists 'B2C_AGB', 'B2B', 'individual' as options but schema type is plain 'string'. LLMs may hallucinate invalid regimes (e.g., 'B2C' vs 'B2C_AGB').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
clause_type parameter in check_clause lacks enum constraint. Description mentions 'e.g. warranty, liability, duration' but accepts any string. Schema should define allowed ClauseType values (WARRANTY, LIABILITY, DURATION, PRICE, etc.).
No tool-level error classification (retryable vs user-fixable vs fatal). When check_clause returns NEEDS_REVIEW, unclear whether agent should retry with different confidence threshold, ask user for clarification, or escalate.
No confirmation/dry-run pattern for irreversible operations. check_clause is read-only (acceptable), but check_contract with 'regime' parameter could misleadingly appear destructive. Labeling as read-only in schema metadata would clarify.