Three tools with clear verb-noun naming (get_*, list_*) and reasonable descriptions (100-150 chars). All tools have input schemas with Zod validation and type definitions. However, parameter descriptions are sparse or missing context. get_metrics lacks guidance on when to use group_by vs filter; get_histogram doesn't explain the output format or when to call it vs get_metrics; list_options is under-documented. No output schemas documented. Error handling is minimal, remote call failures return raw JSON parse errors without recovery guidance. The server is a thin proxy to a remote HTTP endpoint, which limits its ability to provide rich error context or validation.

• Document output schemas for all three tools. Example: 'get_metrics returns {data: [{metric: string, value: number, percentile: number}], total: number, next_cursor?: string}'. This enables LLMs to extract and chain results.
• Expand parameter descriptions with enums or constraints. For 'metrics', provide the full list of valid metric names or link to list_options. For 'group_by', explain when to use it (e.g., 'Use to segment results by a dimension; omit for aggregate totals').
• Add error recovery guidance. Wrap remoteCall errors with context: 'Failed to fetch metrics from corewebvitals.io (check network). Retry with a simpler filter (e.g., device=all only).' This guides LLM retry logic.
• Enhance list_options description to 100+ chars explaining its role as a discovery tool. Example: 'Call this first to discover available metrics, filter keys, and group_by dimensions. Returns the schema of the data contract.'
• Document result limits and pagination. Add to get_metrics: 'Results are limited to 100 rows by default. Use limit parameter (1-1000) to adjust. Returns total count and next_cursor for pagination.'