18 tools with basic descriptions but critical gaps in schema visibility and parameter documentation. Tool names follow verb_noun convention (search, get_, list_, create_) which is good. However, source code does not show explicit JSON Schema definitions for input parameters or output structures. Descriptions are present but generic (avg ~60 chars, well below the 194-char baseline for A+ tools). No evidence of parameter type constraints, enums, or validation guidance. Error handling descriptions absent. One WRITE tool (create_incident) lacks confirmation/dry-run pattern. Most tools are READ_ONLY, reducing risk, but schema completeness cannot be verified from provided code.

• Add explicit JSON Schema definitions to all 18 tools. Include type, description, and constraints for every parameter. Use invopop/jsonschema (already in go.mod) to generate schemas from Go structs.
• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call search() to find dashboards by name when you don't know the exact ID. Use get_dashboard() if you already have the dashboard ID.'), prerequisites, and what is returned.
• Document output schemas for all tools. Specify which fields are returned, their types, and which IDs can be used for chaining (e.g., dashboard_id from list_dashboards can be passed to get_dashboard).
• Add pagination parameters (limit, offset/cursor) and result limits to all list_* tools. Document the default and maximum page size. Example: 'Returns up to 50 dashboards per page. Use offset to fetch additional pages.'
• For create_incident, add a dry_run parameter or require explicit confirmation. Document that this tool modifies state and cannot be undone. Add error guidance: 'If incident creation fails, check that the title is unique and required fields are provided.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry