Multi-service MCP server providing comprehensive API coverage across FormFlow (document processing and form management), Identifier (authentication and identity management), Ledger (insurance business operations), Claim Management, and Site Service tools
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This MCP server has 73 tools but exhibits critical gaps across all definition quality dimensions. Source code inspection reveals tool names and descriptions in component files (FormFlowTools.tsx, IdentifierTools.tsx, LedgerTools.tsx, and claim-management tools), but NO visible input parameter schemas, output schemas, or validation logic. Tools are listed in UI components with human-readable descriptions but are not formally registered with JSON Schema definitions. The descriptions provided are brief but present (average ~100-150 chars). However, without verifiable schemas, parameter descriptions, and error handling code, the server cannot meet production readiness standards. Parameter types, constraints, and required/optional flags are completely absent from visible code. No evidence of idempotency hints, permission gates, or audit logging. This server appears to be a Next.js UI component documentation layer, not a complete MCP implementation with proper tool registration.
CRITICAL: No input parameter schemas visible in source code. All 73 tools have schema score of 0. Tools are documented only in UI components (React TSX) without JSON Schema definitions, required/optional flags, type constraints, or parameter descriptions.
No output schema documentation. There is no evidence of documented return types, field structures, or pagination support across any tool. LLMs cannot plan multi-step flows or extract required IDs for downstream calls without knowing what fields are returned.
No parameter descriptions. Beyond the tool description itself, individual parameters lack context explaining what they control, expected format, valid values, or constraints. A parameter named 'status' in claim_management_update_claim is ambiguous without description.
All 73 tools
Recommendations
Create proper JSON Schema definitions for every tool. For each of the 73 tools, define an input schema with type, required fields, and descriptions. Example for formflow_list_submissions: { 'type': 'object', 'properties': { 'limit': { 'type': 'integer', 'minimum': 1, 'maximum': 100, 'description': 'Number of submissions to return (default 20)' }, 'offset': { 'type': 'integer', 'minimum': 0, 'description': 'Pagination offset' }, 'filter': { 'type': 'string', 'description': 'Filter submissions by status or template' } }, 'required': ['limit'], 'additionalProperties': false }
Document return types for all tools. Specify what fields each tool returns, their types, and how to chain them to downstream tools. E.g., formflow_create_submission should return { submission_id, template_id, created_at, status }, so claim_management_create_claim can use submission_id if needed.
Add parameter descriptions to every input. Replace bare parameter names with descriptions explaining purpose, valid values, and constraints. E.g., status in claim_management_update_claim: 'One of: open, in_progress, closed, archived. Changing to closed requires an approved decision.'
Implement enumeration constraints for categorical fields. For tools accepting status, policy_type, coverage_type, field_type, or decision_status, use JSON Schema enum constraints instead of free-text strings. This prevents LLM hallucination of invalid values.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to guide LLM safety reasoning. Mark all claim_management_list_* and ledger_list_* tools as readOnlyHint: true. Mark claim_management_delete_*, ledger_terminate_policy, claim_management_clear_all_reserves as destructiveHint: true. Mark get_* and list_* as idempotentHint: true.
No enumerated constraints on string inputs. Tools like ledger_create_policy, claim_management_update_claim, and formflow_update_submission likely accept enums (status, policy_type, coverage_type) but no enum schemas are visible. LLMs will hallucinate invalid values.
Destructive operations lack confirmation or dry-run support. Tools like claim_management_delete_document, claim_management_delete_comment, claim_management_terminate_policy, and claim_management_clear_all_reserves are marked DESTRUCTIVE but show no evidence of confirmation gates or undo mechanisms.
No error handling guidance. No evidence of error responses that tell LLMs what to do next (retryable, user-fixable, fatal). Tools lack recovery paths, alternative suggestions, or validation error details.
No pagination support visible. Tools like claim_management_list_claims, formflow_list_submissions, and ledger_list_policies list resources but lack page/offset, limit, or cursor parameters and do not document result count or next-page indicators.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools lack semantic hints that signal to LLMs whether they are safe, destructive, or idempotent. LLMs cannot make safe retry decisions without these hints.
No visible security patterns. No evidence of permission gates, audit logging, scope declarations, or secret injection. Authentication tools (identifier_login, identifier_client_credentials) do not document token expiry, scopes, or secure storage guidance.
Source code provided is a Next.js UI component (FormFlowTools.tsx) with React JSX, not actual tool implementation or MCP registration logic. The tools are described in UI rendering code, not in functional tool handlers with proper parameter validation, error handling, or schema definitions.
All 73 tools
Implement confirmation gates for destructive tools. For claim_management_delete_document, claim_management_delete_comment, ledger_terminate_policy, and claim_management_clear_* tools, require a confirm parameter or return a 'confirmation_required' response asking the user to re-invoke with confirm=true.
Add pagination parameters and documentation to all list tools. Include limit (1-100), offset (default 0), and sort_by parameters. Return a response with items[], total_count, and next_cursor. Document in tool description: 'Returns up to 50 results per page. Use limit and offset for pagination.'
Design error responses with recovery guidance. E.g., if claim_management_get_claim returns 404, respond: 'Claim not found. Try claim_management_list_claims to search by customer or policy. Or check the claim ID spelling.' This guides the LLM to the next step.
Add scope declarations and permission hints to each tool. E.g., identifier_login requires 'auth:write'; claim_management_create_claim requires 'claims:write'; all get_* and list_* tools require only 'claims:read'. Document in descriptions: 'Requires scope: claims:write'.
Separate the UI documentation (React component) from the actual tool registration. Move tool definitions to a dedicated TypeScript module (e.g., app/lib/tools.ts or app/tools/registry.ts) where each tool is registered with full schemas, descriptions, and handlers using @modelcontextprotocol/sdk tool registration API.
Document pagination limits in descriptions. For each list tool, state the default limit and maximum. E.g., 'Retrieve claims with advanced filtering, pagination, and sorting capabilities. Default limit: 20, max: 100. Returns total_count and next_offset for subsequent pages.'
Implement per-tool error handling. For tools like ledger_bind_policy and claim_management_authorize_reserve that depend on prior state, return structured errors: 'Policy is already bound. Try ledger_renew_policy instead.' or 'Reserve amount exceeds claim assessment. Adjust amount or contact underwriter.'
Add idempotency support to creation tools. For formflow_create_submission, claim_management_create_claim, and ledger_create_quote, accept an optional idempotency_key parameter and document: 'If retried with the same idempotency_key, returns the originally created record. Prevents duplicate submissions on network retry.'
Create tool chaining documentation. Map output fields from discovery tools (list_*, get_*) to inputs of downstream tools. E.g., formflow_list_submissions returns submission_id → formflow_get_submission accepts submission_id. Ensure all reference chains are complete so LLMs don't need discovery detours.