Server defines 13 tools with high-level category descriptions but lacks critical detail. Tool names are category-based (search, datasource, incident) rather than verb-noun action names (search_dashboards, list_datasources). No visible input schemas, parameter descriptions, or output schemas in provided source. Descriptions are generic category summaries (10-50 chars) rather than LLM-optimized action descriptions (50-200 chars baseline). Cannot verify parameter types, constraints, or error handling patterns. Source code shows tool registration in main.go but actual schema definitions are not included in the provided excerpt.

• Rename tools from category nouns to verb-noun action names: search → search_dashboards, datasource → list_datasources, incident → create_incident / search_incidents, etc. This enables LLMs to infer intent from the name alone.
• Expand each tool description to 50-200 chars explaining WHAT it does, WHEN to use it, and what it returns. Example: 'Search for Grafana dashboards by name or tag. Returns dashboard ID, title, and URL. Use this to find existing dashboards before creating panels.'
• Add explicit input schemas with parameter types, descriptions, and constraints. For each parameter, document format (e.g. 'ISO 8601 date'), range (e.g. 'limit: 1-100'), and allowed values (enums). Example: 'status: enum [open, in_progress, resolved, closed]'.
• Document output schemas showing what fields each tool returns. Include IDs and references needed for downstream tool calls (e.g. if search_dashboards returns dashboard_id, ensure update_dashboard accepts dashboard_id).
• Add error handling guidance: categorize errors as retryable, user-fixable, or fatal. Return actionable messages like 'Dashboard not found. Try search_dashboards() with a partial name.' instead of bare error codes.

Inferred effective spec: 2026-07-28+.

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