Loading ToolBench
Translates business intent into legally binding smart-contract drafts
This MCP server has a single tool with severely deficient definition quality. The tool name is non-standard (does not start with a clear action verb), the description is vague marketing copy rather than LLM-optimized documentation, parameters lack descriptions entirely, input schema is minimal with no type constraints, and there is no documented output schema. The implementation is a stub that returns unstructured text rather than properly shaped JSON. No error handling, no parameter validation, and no composition patterns evident. This server would not pass basic code review for production use.
From intent to legally binding smart-contract draft.
Tool name does not follow verb_noun pattern. 'generate_enforceable_contract' is awkward and domain-specific marketing language. Standard verb would be 'create_contract' or 'generate_contract'. LLMs parse intent from the name first, this name obscures the primary action.
Tool description is 75 characters of marketing copy ('From intent to legally binding smart-contract draft.') rather than LLM-optimized documentation. Missing: what does it actually return? When should the LLM call it vs other tools? What format is the output? What are prerequisites? Description fails the WHAT/WHEN/PREREQUISITES test from pattern:tool-description.
Input parameters have no descriptions. 'deal_terms' object has two nested fields ('parties' and 'value') with descriptions like 'The parties involved in the agreement' (43 chars) and 'The monetary value in USD' (25 chars), both below the baseline average of 72 chars and lacking actionable format guidance. No constraints on format (Is 'parties' a comma-separated list? Full legal entity names? Email addresses?). No examples of valid input. Baseline: 100% of A+ tools have descriptions for EVERY parameter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
No output schema documented. The tool returns a plain string (template = f'AGREEMENT: ...'). LLMs cannot infer downstream fields or plan chaining. A proper response should be a structured JSON object with fields like: { 'contract_id': '...', 'status': 'draft', 'parties': [...], 'value_usd': 1500000, 'markdown_content': '...' }. Baseline: 100% of A+ tools have documented return types.
No error handling or recovery guidance. If 'parties' is empty, or 'value' is not a valid USD amount, the tool silently returns garbage (e.g., 'AGREEMENT: . TERMS: USD.'). No validation, no meaningful error messages telling the LLM what to do next. Baseline from pattern:recovery-guide: errors must say what to try next.
Input schema is incomplete. 'deal_terms' declares properties but no required array, no additionalProperties constraint, no minLength/maxLength on string fields, no pattern validation for 'value' (is it '1500000', '$1.5M', '1.5M USD'?). Schema score cannot exceed 30 when parameters lack proper type definitions and constraints.
Tool does not declare what it returns or guarantees about contract validity. Marketing claim in description is 'legally binding smart-contract draft', but code produces a simple string template. LLMs will be misled about the output format and utility.
No idempotency guarantee or confirmation step before executing. If an LLM calls this twice with the same deal terms (a common retry pattern), it silently generates two contract drafts. For a tool with destructive or irreversible consequences (contract generation could trigger billing, legal review queues, etc.), a dry-run or confirmation pattern is essential per pattern:confirmation-request.
Tool name contains marketing language ('Ghostwriter', 'GenPark', 'enforceable'). 'generate_enforceable_contract' mixes a verb ('generate') with product branding and legal jargon. Standard naming would be 'create_contract' or 'draft_contract'. Baseline: 90% of A+ tools use simple action verbs.