Loading ToolBench
An MCP server that provides self-updating context from a local document workspace to Claude, optimized for legal drafting workflows.
Legal Workspace MCP demonstrates strong definition quality with comprehensive tool descriptions, proper parameter validation, and structured output. All 5 tools have clear, action-oriented names (workspace_*) with detailed descriptions (140-250 chars each) that explain WHAT, WHEN, and WHY. Input schemas are well-formed with Pydantic models providing type definitions and validation constraints. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present for all tools. However, output schemas are partially documented (returned as JSON strings rather than formally declared return types), and error handling could be more prescriptive with recovery guidance. The search tool correctly uses pagination parameters (max_results 1-20) and BM25 relevance scoring is documented. Per-tool analysis shows consistent quality across the suite.
Retrieve the full text content of a specific document from the workspace. Use this tool after workspace_search to read the complete content of a document that appeared in search results, or when you know the exact file path of a document the user wants to reference.
List all documents currently indexed in the legal workspace. Use this tool to see what documents are available for searching and reference. Returns file paths relative to the workspace root.
Force a complete re-index of all documents in the workspace. Use this tool if you suspect the index is out of sync with the workspace, or after adding many documents at once. This performs a full scan and rebuild.
Search across all documents in the legal workspace for relevant content. Use this tool when you need to find specific legal language, clause examples, drafting guidance, or reference material from the user's document collection. Results include relevant text snippets with source file information.
Check the health and statistics of the document index. Use this tool to verify that the workspace is properly indexed, see how many documents are available, and check for any indexing errors.
Output schemas are returned as JSON strings rather than formally declared in tool registration. workspace_search documents output structure in docstring but returns `str` type; LLMs cannot parse expected fields without inspecting example output.
Error handling is minimal. workspace_search returns JSON error responses (e.g., 'Index not initialized') but does not guide LLM on recovery actions. Missing pattern: 'Try calling workspace_status to check index health' or 'Retry after waiting for initialization.'
workspace_list_documents and workspace_status have empty input schemas (no parameters). While correct, descriptions do not explain when to call them in discovery flow or how results guide subsequent tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
workspace_get_document requires exact file_path but workspace_search returns matching documents without guaranteeing field names match. If search returns 'file' but get_document expects 'file_path', chaining breaks. Response field naming (mxe:response-field-naming) not verified.
workspace_reindex is marked as WRITE (destructive) but has no confirmation or dry-run capability. Per pattern:confirmation-request, irreversible operations should support a confirm-before-execute step to prevent accidental index rebuilds during agent planning.