This server has severe definition quality issues. 19 of 21 tools (90%) lack visible input schemas in the source code provided. Only 2 tools (search_case_by_number, create_intake_notes) have schemas documented. Most tools have missing or trivial descriptions. Parameter descriptions are absent across nearly all tools. The codebase shows tool factories (createMatterTools, createDocumentTools, etc.) that generate tools dynamically, but the actual schema definitions are not visible in the provided source excerpts, making it impossible to verify schema quality. This is a critical gap, without seeing the schema files, schema scores default to 0 for affected tools. The few visible tools (search_case_by_number with minimal description, create_intake_notes with a single-sentence description) show weak documentation patterns. Error handling and output schema documentation are not evident.
19 of 21 tools (90%) lack visible input schemas in the provided source code. Schema files are referenced but not included in the evaluation set. Cannot verify parameter definitions, types, constraints, or descriptions. Per hard scoring rule: 'If a tool has NO input schema at all: its schema score MUST be 0.'
19 of 21 tools (90%) have no visible description in the tool registry or source files provided. LLMs cannot determine when or why to select these tools. Without one, LLMs cannot determine when or why to select the tool.'
get_matter
Recommendations
Add comprehensive descriptions to all 19 undocumented tools. Each description should be 50-200 characters, state WHAT the tool does, WHEN to use it, and WHAT it returns. Example: 'get_matter: Retrieve full details of a legal matter by ID, including client info, dates, and status. Use after identifying a matter ID from list_matters. Returns matter object with all metadata.'
Document parameter descriptions for all tools. For create_intake_notes, describe 'case_uuid' (e.g., 'The unique identifier for the case; obtained from get_case_info or list_client_matters') and 'exclude_note_ids' (e.g., 'Array of note IDs to exclude from the intake summary; optional').
Add output schema documentation for all tools. Use comments or structured documentation to specify return types. Example: 'Returns: { matter_id: string, client_name: string, status: enum["active", "closed"], created_date: ISO8601 }'
Add pagination parameters to all list_* tools. Include: limit (1-100, default 20), offset or page, and return total_count or next_cursor. Example: 'list_matters(limit: 20, offset: 0) → { matters: [...], total_count: 150, has_more: boolean }'
Implement error recovery guidance. When a tool fails, return actionable next steps. Example: 'Matter not found: call search_case_by_number(case_number="...") first to find the matter ID, or list_client_matters() to see available matters.'
Provide the actual tool implementation files (src/apps/legalserver/tools/matters.js, documents.js, tasks.js, etc.) in the source code evaluation set so that tool schemas, parameter definitions, and error handling can be directly verified instead of inferred.
Parameter descriptions are entirely missing for all tools. For create_intake_notes, parameters 'case_uuid' and 'exclude_note_ids' have no descriptions explaining what they do or when to use them. For search_case_by_number, 'case_number' has no description. LLMs cannot infer parameter meaning from names alone.'
Output schemas are not documented in the provided source. No evidence of return type specifications or structured output definitions. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' Also: '100% of A+ tools have documented return types.'
Tools like list_matters, list_documents, list_tasks, list_events, list_contacts, list_users, list_organizations, and list_client_matters have no visible pagination parameters (limit, offset, page, next_cursor). Without pagination, large results blow the context window.'
No error handling guidance visible. No evidence of recovery messages, error categorization, or actionable error responses. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.'
Tool definitions are generated via factories (createMatterTools, createDocumentTools, etc.) in src/apps/legalserver/toolRegistry.js, but the actual implementation files are not provided. Per hard scoring rule: 'If you are inferring tool existence (not seeing explicit registration): cap that tool's overall at 50.' This affects 19 tools where only the factory call is visible but not the returned schema objects.
create_intake_notes description is too brief ('Use ONLY when the user specifically asks for "Intake Notes". Do not use for general summaries.' = 91 chars). Lacks context on WHAT the tool does operationally, WHEN to use it beyond negation, and WHAT it returns. Too short lacks context for selection.'
search_case_by_number has no description at all in the provided source. Only a parameter schema is visible. Per hard scoring rule: 'If a tool has NO description: its description score MUST be 0.'
search_case_by_number
Add parameter constraints and enums. For example, if 'status' is a parameter, declare it as enum['active', 'pending', 'closed'] rather than free-form string. If 'limit' is a parameter, specify range: minimum 1, maximum 100.
Clarify tool relationships and composition. Document which tools return IDs that feed into other tools (e.g., 'get_matter returns matter_id, which is accepted by search_documents(matter_id=...)').
Add support for natural identifiers (case numbers, names) alongside system IDs. For example, accept both case_uuid and case_number in get_case_info, not just UUIDs. Accept usernames, emails, and display names, resolve them to system IDs inside the tool.'
Ensure all tools are marked as read-only. The risk tags indicate 'READ_ONLY', which is correct. Ensure tool annotations in MCP payload include 'readOnlyHint: true' for protocol compliance.