Loading ToolBench
MCP server for claims processing with Supabase integration
This MCP server exhibits significant definition quality gaps. While 6 tools are registered with basic schemas, most descriptions are terse (10-26 chars), many parameters lack descriptions, and error handling is minimal. The codebase shows schema validation using Zod but critical parameter descriptions are absent or ambiguous. Tool naming follows verb_noun convention acceptably, but parameter naming has inconsistencies (claimId vs policy_number). Output schemas are not documented. No evidence of LLM-optimized descriptions or recovery guidance.
Analyze a claim using Claude AI for advanced insights
Get the current status of a claim
List and filter claims
Submit a new insurance claim
Validate an existing claim
Validate claim documents using Claude AI for completeness and consistency
Parameter descriptions are missing or extremely terse. submitClaim and others lack descriptions for most parameters (e.g., 'documents' array documented only as 'Array of document references' with no explanation of format, reference type, or allowed document types). Rubric requires non-empty description for every parameter; descriptions under 20 chars cannot exceed 20 points.
Tool descriptions are too short and lack context. All 6 tools have descriptions under 30 chars. 'Submit a new insurance claim' does not explain WHEN to use submitClaim vs other tools, what state changes occur, what errors might happen, or what the return value contains. Rubric requires 10 - 1024 chars but recommends 50 - 200 for LLM optimality. Current descriptions are at the bare minimum threshold.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schemas are not documented. No tool definition includes what fields the response will contain, what format dates use (ISO 8601 vs epoch), or what IDs/references are returned for chaining to other tools. Rubric requires: 'Document the output schema. LLMs need to know what fields to expect.' This prevents the LLM from planning downstream calls correctly.
Parameter naming inconsistency. submitClaim uses snake_case (policy_number, claimant_name, claim_type, incident_date, claim_amount) but validateClaim and getClaimStatus use camelCase (claimId). Inconsistent naming forces LLMs to mentally map field names and increases errors when chaining tools.
No enum constraints on status/type parameters. listClaims accepts 'status' and 'claim_type' as free-form strings with no enum definition. The description does not list valid values. LLMs will hallucinate invalid statuses. Rubric requires: 'When a parameter accepts one of a known set of values, declare it as an enum.'
No error handling documentation or recovery guidance. The MCPServer.handleCall and handleMessage methods catch errors but return generic messages ('Function not found', 'Invalid parameters'). No guidance on what the LLM should do next (retry, ask user, abort). Rubric requires: 'Error responses must tell the LLM what to do next' and 'Categorize errors as retryable, user-fixable, or fatal.'
Parameter format and constraint documentation missing. analyzeClaimWithAI and validateDocumentsWithAI accept claimId and documentIds with no format specification. Are they UUIDs, integers, or strings? submitClaim's documents array is undescribed, are these file paths, URLs, base64-encoded content, or external references? Rubric requires: 'Describe the expected format, range, and allowed values directly in the parameter description.'
No pagination or result limit documentation. listClaims accepts 'page' and 'limit' parameters but the tool description does not state the default limit, maximum allowed limit, or what structure the response uses for pagination metadata (total_count, has_next, next_cursor, etc.). Rubric requires: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' and 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination.'
No permission/scope declarations. Tool definitions do not state what permissions they require (e.g., 'read:claims', 'write:claims', 'admin:claims'). Rubric requires: 'Each tool should declare what permissions it requires.' This prevents least-privilege agent configuration.
No confirmation or dry-run support for destructive operations. submitClaim is marked WRITE but has no dry-run, confirmation step, or rollback guidance. Rubric requires: 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.'