WaveXisMCP exposes 10 tools with generally consistent naming (verb-prefixed) and parameter descriptions. However, output schemas are entirely absent from the provided source, none of the tools document what they return, violating a critical A+ pattern. Parameter descriptions are present but terse (averaging ~30 chars), falling below the 72-char baseline for A+ tools. Tool descriptions are more substantial (averaging ~80 chars), but lack guidance on when to use each tool vs. alternatives (e.g., when to choose wavexis_perf_trace vs wavexis_perf_profile). Schema quality is hampered by lack of explicit constraints (enums, min/max bounds) on most parameters. The wavexis_act tool is the highest-risk operation (WRITE classification) but lacks a confirmation/dry-run pattern. Error handling guidance is not evident in the provided code. Overall, the server is solidly above C-grade due to consistent naming and parameter presence, but falls short of B-grade (70+) because output schemas are undocumented and descriptions lack LLM optimization.

• Document the output schema for every tool. For example, wavexis_perf_metrics should specify: 'Returns an object with fields: { lcp_ms: number, fcp_ms: number, cls_score: number, ttfb_ms: number, dom_nodes: number, ... }'. Include field types, optional vs required, and units.
• Expand parameter descriptions to 50 - 100 chars and include constraint guidance. E.g., 'session_id (string): Session identifier returned by wavexis_create_session. Format: alphanumeric, required.'
• Add explicit constraints to numeric parameters: 'duration_ms (integer): Trace duration in milliseconds. Range: 100 - 300000 (100ms - 5min).'
• For wavexis_act, implement a dry-run mode or confirmation step: add an optional 'dry_run' parameter (default false). When true, return the detected action without executing it, allowing the agent to verify before committing.
• For each tool, add a 'WHEN TO USE' note in the description: E.g., wavexis_perf_trace: 'Captures detailed timeline of network and rendering events. Use when you need granular frame-by-frame data. For quick metrics, use wavexis_perf_metrics instead.'
• Define error responses with recovery guidance. E.g., 'If session not found, call wavexis_create_session first.'
• Add pagination/limiting guidance to list-like tools (e.g., wavexis_css_get_stylesheets). Document: 'Returns up to 100 stylesheets. If more exist, results include a next_cursor for pagination.'
• For wavexis_act, document idempotency: 'Repeated calls with the same instruction may not be idempotent if the page state changes between calls. Use with caution in retry loops.'