Faultline provides 12 tools with consistent naming (verb_noun pattern: add_rule, list_rules, remove_rule, etc.) and basic descriptions. However, parameter descriptions are minimal or absent for most tools. Input schemas are visible in test files but lack detail: match, fault, and behavior parameters in add_rule are typed as 'object' with only high-level descriptions, providing no guidance on required/optional subfields. Output schemas are not documented. Error handling is not evident from the code provided. The server follows a clear domain (fault injection rules, scenarios, events) but lacks the depth needed for production LLM integration.

• Expand add_rule's 'match', 'fault', and 'behavior' parameters: replace object type with explicit subfield schemas. E.g., match: {host: string, port?: integer}, fault: {type: enum[delay|error|abort], delay_ms?: integer, error_code?: integer}.
• Document output schemas for all list_* and get_* tools. E.g., list_rules returns [{id: string, name: string, enabled: boolean, match: object, fault: object}]. Include field types and whether arrays are paginated.
• Enhance parameter descriptions to 50-150 chars with format hints. E.g., 'The rule ID (UUID format, e.g., 550e8400-e29b-41d4-a716-446655440000)' instead of 'The rule ID to remove'.
• Add error handling guidance to tool descriptions. E.g., wait_for_event: 'Returns timeout error if no matching event within timeout_ms. Retry with increased timeout or check list_events to verify events are being recorded.'
• Implement confirmation pattern for destructive tools: add a 'confirm' boolean parameter to reset_session and remove_rule, or create separate dry_run variants that preview changes without executing.