GhostAPI provides 4 tools with explicit schemas and descriptions. However, quality is uneven. Tool names lack clear action verbs (inspect_state, toggle_chaos_mode are vague). Descriptions are present but brief (avg ~60 chars, below 194-char baseline). Parameter descriptions exist but lack depth, no guidance on when to use each tool, dependencies between them, or recovery paths. Schema completeness varies: set_api_behavior has detailed constraints (HTTP methods enum, status range 100-599, delay bounds); toggle_chaos_mode uses union types but lacks clarity on mutual exclusivity. Output schemas are undocumented, LLMs cannot predict what inspect_state or get_traffic_logs return. Error handling is absent, no guidance on what happens if state.json is missing, if chaos mode conflicts with active requests, or how to recover from invalid configurations.

• Rename tools to start with clear action verbs: 'inspect_state' → 'get_state', 'toggle_chaos_mode' → 'set_chaos_mode'. Follow verb_noun convention (get_, set_, list_, create_) so LLMs parse intent from names alone.
• Document output schemas for all tools. E.g., 'Returns {state: object, lastModified: ISO8601, version: string}' for get_state; 'Returns {logs: [{method, path, status, timestamp, body}], count: number, truncated: boolean}' for get_traffic_logs.
• Expand parameter descriptions to 50-100 chars with context. E.g., 'delayMs: Simulate network latency (0-10000ms). Use to test timeout handling; values >5000ms may cause client timeouts.' Include constraints and use cases.
• Add error handling examples. Document what happens if state.json is missing (return 'State file not found. Call set_api_behavior to initialize.' or similar). Provide recovery paths for each failure mode.
• Clarify tool interactions. Document whether chaos_mode and set_api_behavior can coexist, which takes precedence, and how to disable one without affecting the other. Add a 'dependencies' field to tool descriptions if applicable.