Previa exposes 6 load-testing tools with basic descriptions and minimal input schemas. All tools have descriptions (10-100 chars), but most lack parameter detail. Schemas are present but sparse: 3 tools have no input parameters (health, load_ok, metrics, reset_metrics), while load_slow and load_fail accept single integer parameters with descriptions. No output schemas documented. Tool names follow verb_noun convention (load_*, reset_*) and are clear. Error handling and recovery guidance are absent. Composition is reasonable, each tool has one responsibility, but parameter constraints (ranges, defaults) are underspecified. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Document output schemas for all tools. E.g., metrics should return {request_count: int, avg_latency_ms: float, p99_latency_ms: float, requests_per_second: float, failure_count: int, failure_rate_percent: float}. health should return {status: 'healthy'|'unhealthy', uptime_seconds: int, last_check_timestamp: string}.
• Expand parameter descriptions with explicit constraints. load_slow: 'Delay in milliseconds (optional, default 50, min 1, max 30000)'. load_fail: 'Failure rate percentage (optional, default 100, min 1, max 100)'.
• Add tool annotations via MCP protocol. Mark reset_metrics with destructiveHint=true. Mark health, load_ok, load_slow, load_fail, metrics with readOnlyHint=true.
• Extend tool descriptions to 80-150 chars. Include WHEN to use: 'Call health first to verify load target is running. Returns uptime and last check timestamp.' For metrics: 'Returns aggregated statistics since last reset: request counts, latency percentiles, and throughput. Use after running load tests to analyze performance.'
• Define error recovery paths. E.g., 'If load target is unreachable, health returns status=unhealthy with error_message. Verify target service is running on the configured host:port before retrying load_ok.'